SSL Still Mostly Misunderstood, Even By the Pros

An anonymous reader writes "People still don't understand SSL. This isn't much of a surprise... no one expects that grandma and grandpa know what SSL is and what it does. What is surprising and downright scary is that most IT professionals don't understand SSL, and many consider it to be the be-all, end-all of security in their organization. With all the tools out there to manipulate SSL connections, and the browser vendors unable to settle on a single method of showing if a site is secured by SSL or not, is it any wonder that no one gets it?"

Comments

I'm a Pro

[Anonymous Coward]

What is SSL anyway?

Re:I'm a Pro

[SimonTheSoundMan]

This is SSL http://www.solid-state-logic.com/

Most pro's have never used one.

Re:I'm a Pro

[arkane1234]

Wrong SSL.
We're talking about Secure Socket Layer, not Solid State Logic.

Re:I'm a Pro

[Pieroxy]

We will all mourn your sense of humour. What a pity...

Oh well, you can adopt another one. It will never be the same, but it'll be there when you need it!

Re:I'm a Pro

[jevring]

It's Secure Socket Lawyer!

Moderators, are you all friggin' retards?

[Eggplant62]

Who proofreads these article submissions, anyway? Does anyone?

Re:Moderators, are you all friggin' retards?

[Beyond_GoodandEvil]

Who proofreads these article submissions, anyway? Does anyone?
Used to be able to tag a story with typo to let the editors know what's going on. Glad to see I'm not the only one jarred by the second their in the summary.

Re:Moderators, are you all friggin' retards?

[Anonymous Coward]

Used to be able to tag a story with typo to let the editors know what's going on.

Right...no typo tag allowed ?!? Does that mean tagging was trolled to death?

Re:Moderators, are you all friggin' retards?

[Stachybotris]

no one expects that grandma and grandpa know how to what SSL is and what it does.

I just consider this sort of typo a cheap and lazy form of story encryption...

Re:Moderators, are you all friggin' retards?

[L4t3r4lu5]

Xvaq bs yvxr hfvat n ebgngvbany plcure

Re:Moderators, are you all friggin' retards?

[G'grandpa]

Who proofreads these article submissions, anyway? Does anyone?

Any high school graduates out [their, they're, there]?
"...all the tools out their to manipulate..."
Perhaps the moderators let this pass on purpose to emphasize the educational failings in our English speaking (sic) cultures.

- English speaking Grandpa (actually a Great Grand Father)

Re:Moderators, are you all friggin' retards?

[Anonymous Coward]

Hey! I *do* know how to what.

It is what to how which is somehow not what you will.

xtracto

Re:Moderators, are you all friggin' retards?

[OakDragon]

What can't they most the least?

Re:Moderators, are you all friggin' retards?

[rockbottoms]

I just consider this sort of typo a cheap and lazy form of story encryption...

I just except the typos for what they are

Re:Moderators, are you all friggin' retards?

[Anonymous Coward]

Replace all occurrences of "SSL" with "English" in the article. Then it makes sense.

Example: "People still don't understand English. This isn't much of a surprise..."

Re:Moderators, are you all friggin' retards?

[uberdilligaff]

Orggre znlor vs lbh hfrq vt-cnl ngva-ynl svefg?

Re:Moderators, are you all friggin' retards?

[Anonymous Coward]

Kek

Re:Moderators, are you all friggin' retards?

[TheRaven64]

Hmm, you're probably still just new enough to be making that mistake. Slashdot readers go through various development stages, like insects:

1. New users read the articles.
2. Then they stop reading the articles, and just read the summary.
3. After a while, they stop reading even the summary, and just read the headlines.
4. Finally, they stop even reading the comments that they are replying to, and just paste links to goatse or stories about CmdrTaco'ssex life.

Re:Moderators, are you all friggin' retards?

[sabaisabai]

Bueller Bueller...

Re:Moderators, are you all friggin' retards?

[Tetsujin]

...no one expects that grandma and grandpa know how to what English is and what it does...

Hmm, I think when I get home I'll watch a cheesy old movie. Maybe "Attack of the The Eye Creatures"...

Re:Moderators, are you all friggin' retards?

[Knitebane]

Wait, CmdrTaco has a sex life? I thought he got married.

Re:Moderators, are you all friggin' retards?

[TheRaven64]

If you read the relevant posts (which I don't recommend) it involves meeting strange men in public toilets...

Re:Moderators, are you all friggin' retards?

[bvankuik]

stories about CmdrTaco'ssex life.

An alternative to step 4 is to become a grammer Nazi.

You're doing it wrong

[QuantumG]

If you want to write a pretentious article about how people don't understand security of the interwebs, at least get the name right. That's right, SSL hasn't been considered "secure" for at least a decade.

Re:You're doing it wrong

[frozentier]

If you want to write a pretentious article, AT LEAST use correct spelling and grammar if nothing else.

Re:You're doing it wrong

[Anonymous Coward]

The article isn't even just pretentious, it's just pointless fluff. The entire thing could have been summarized as "many customers ignore security warnings in browsers and many web developers deploy SSL/TSL in vaguely unacceptable ways which we won't even begin to explain here".

Really, that article couldn't have been more pointless. WHAT are people doing that they shouldn't be? WHAT are people expecting SSL to do that it doesn't? If you're going to write an article about people's misconceptions of a technology, you could at least spend a single sentence explaining what some of those misconceptions are.

Pointless and uninformative article is pointless and uninformative.

Re:You're doing it wrong

[something_wicked_thi]

If you want to write a pretentious response to a pretentious article, try reading the source you're linking to. SSL v2 hasn't been secure for a while, but SSL v3 is fine.

Re:You're doing it wrong

[Anonymous Coward]

Whatever, everyone uses TLS and SSL interchangeably because they are for all intents and purposes the same. SSLv3 is secure but you do have the possibility of man-in-the-middle attacks. That is true of all public key based systems though (including SSH, etc).

Re:You're doing it wrong

[Antique Geekmeister]

No, I'm afraid it's not. It's still vulnerable to "Do you accept this made-up key" attacks where people have become far too accustomed to accepting unsigned keys, and to the purchase of centrally signed keys. Because the key signatures belong to a central signing authorities that rely on valid credit cards, not personal authentication, there is still only a pretense at genuine security.

There have been other tools proposed to address these issues, such as the PGP web-of-trust, and the Palladium project's hardware encryption, but they've broken down in practice on the problem of US encryption export regulations, poor closed source implementation that turns out to be easily virtualized, and many essentially social rather than technological issues. Even SSL was handicapped for years by the USA's insane 80-bit limit for SSL in exported software.

Re:You're doing it wrong

[andymadigan]

That's what certificate signing is supposed to protect against. Of course, if you have $100 million lying around or you're the government, you can probably get certificates signed for domains you don't own, and they'll look real. That's why we need a public database of certificates that browsers check against, rather than signing certs.

Re:You're doing it wrong

[muckracer]

> Even SSL was handicapped for years by the USA's insane 80-bit limit for SSL
> in exported software.

It was 40-bits. Agree with your point...just sayin'.

Re:You're doing it wrong

[rgviza]

>No, I'm afraid it's not. It's still vulnerable to "Do you accept this made-up key" attacks where people have become far too accustomed to accepting unsigned keys, and to the purchase of centrally signed keys

Um, that's a social engineering attack, not a fault of the protocol itself. The protocol is secure, users aren't. To be fair, the browser manufacturers could do a better job of writing the warnings so that anyone could understand them. Again, this is not a fault of the protocol, rather how people use it.

And adding a layer of PGP to it, would have the _exact_ same issue. Instead of "Do you accept this SSL key" It would be "Do you accept this PGP key". In addition, adding PGP would introduce a whole new slew of security bugs related to added complexity of PGP support in browsers, along with all the bugs guaranteed to be introduced with the additional new code.

No thanks =D.

Re:You're doing it wrong

[Magic5Ball]

FTFA:

> "Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords."

> "More than half of the respondents don't know what Extended Validation SSL (EVSSL) is and how it differs from SSL, while 36 percent say they do. Interestingly, most of them are aware that SSL traffic can be sniffed without their knowledge."

> "Another issue is that users become annoyed and eventually ignore SSL and browser security messages that appear when they hit a site with an invalid certificate, or a browser warns them of a potentially dangerous site, Reguly says. Nearly 50 of the survey's nontechnical respondents just clicked through security warnings without paying attention to them, he says."

Re:You're doing it wrong

[Magic5Ball]

I think the idea of a public revocation database has merit. How would I make sure that my connection to the database has not been tainted? How could this database as a business entity be designed in a way that's less vulnerable to social engineering attacks than the current system?

Re:You're doing it wrong

[KnownIssues]

It seems you've all proved the article's point. SSL still mostly misunderstood.

Re:You're doing it wrong

[yuna49]

> "Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords."

I found this one of the silliest parts of the story. First, to what type of sites does that 41% figure apply? Are they the same sites where people are entering credit card information? There are a number of sites where I enter passwords without SSL encryption, this site for one. Those are sites where I don't really care if my password is sniffed or not. Does that place me in the 59% of supposedly inattentive users? For sites where I care about protecting my authentication information like my bank or Amazon, I make sure the password transaction is encrypted.

Next, the article presents a laundry list of apparent security flaws in SSL. How common are these? Do we have demonstrated evidence that they've been used to subvert transactions with well-known sites like major banks and online retailers, or are these just theoretical flaws? Like the article on piracy in today's news, the statistics in this piece seem intended to drive sales of security software and services by fear-mongering.

Finally there's the suggestion that browsers never permit people to accept certificates that have expired or are self-signed. I'm sorry, but that's just not going to fly. I find the current plethora of hoops I have to jump through with Firefox annoying enough. If I want to sign a cert so my employees can read their mail with a web browser, what's wrong with that?

Re:You're doing it wrong

[vadim_t]

Finally there's the suggestion that browsers never permit people to accept certificates that have expired or are self-signed. I'm sorry, but that's just not going to fly. I find the current plethora of hoops I have to jump through with Firefox annoying enough. If I want to sign a cert so my employees can read their mail with a web browser, what's wrong with that?

That it's pointless and doesn't work?

If your employees every day click on "Ignore self-signed cert" button, then they'll click on it the time when they connect to some random open access point that's set up to generate self-signed certs for any SSL website.

It's worse than no encryption. With no encryption you know there isn't any security. With encryption you think there is, all while your internal company mail is passing through a system intentionally set up to log all traffic for malicious purposes.

You can fix it easily though. All you need is to setup your own CA. Use something like tinyca. Generate a CA cert, make certs for your employees, sign then with the CA, then get them to import the CA certs into their browsers. Then any further certs you sign with that CA will be automatically trusted. Every browser will stop complaining if you give it your CA cert.

Re:You're doing it wrong

[andymadigan]

Social engineering is an area I can't answer to. As for securing the connection, the public key that the server identifies itself with would be well-known. Signed keys would not be valid for the server. It would still be possible for the "keyholder" to be bought, I suppose. However, I'm sure a sufficiently trustworthy entity could be found for that purpose (on the other hand, I don't trust verisign at all).

However, I don't think it can stop at a "revocation database". The database should list ALL the valid keys for the domain. Not only does this allow the browser to whitelist just those keys, a key can't be issued to a domain without the domain owner knowing about it. After all, whitelisting is far more secure than blacklisting.

I think the best bet would be to have many databases managed by separate organizations. The databases would each have their own key, rotated hourly. Each databases would also list the valid public keys for the other databases. A browser can verify that a MITM attack is not occurring by checking with some number of the other databases to ensure the key the database it is using is correct. The critical point here is that paying off one or two database admins may be easy, but buying off ALL of them should be difficult. If more than one or two of the databases can't be contacted for verification, the user should be told that their connection may be compromised. The root certificate for each organization would be used to sign each of its rotating keys. The public keys would be well known and embedded in the browser. In order to take down the whole system you need to compromise all of the keys.

For social engineering attacks, there may be a solution, but it has little to do with a public key database.

The first time the user enters a banking site and logs in, the site tells the browser that it is a banking site. In the future, the browser will not allow the same information to be entered on a site with a different domain, or over an unsecure connection. In order for this to work, the bank needs to require the user to enter some unique piece of information, like a number that they were provided by the bank when they opened their account.

Re:You're doing it wrong

[Yvanhoe]

All I need for a web of trust to work, it that CowboyNeal begins signing SSL certificates.

Re:You're doing it wrong

[Antique Geekmeister]

It's a social engineering attack, yes. It's one that is built into the current implementation of SSL: the central key authority has been over-trusted, and signed keys are far too easy to obtain.

And I'm sorry that I was confusing. It's not PGP that I was referring to as useful, but rather PGP's 'web-of-trust', where people whom you know personally sign keys for others whom they know personally, and you can trace that web to see who knows the final target's key owner. From my observation of the behavior of Verisign, the most common signature authority, they should not be trusted to vouch for whether they're wearing pants, much less sign anyone's SSL keys. And downstream signature authorities like GoDaddy are even worse at selling off keys to fraudulent users. So SSL, as implemented in the procedural sense, only provides a money-purchased pretense at authentication, and is only genuinely useful for encryption.

This problem is not going away because it would completely shaft Verisign's business model, and they'd have no reason to _permit_ its removal.

Re:You're doing it wrong

[Sloppy]

Instead of "Do you accept this SSL key" It would be "Do you accept this PGP key".

Only if the software creators were dumb enough to use the word "accept" like that. There's nothing wrong with "accepting" an uncertified key. If you can't verify who you're talking to, it's still better to use the shady key than to just give up and use plaintext.

Instead of having the software ask them anything, when it gets a shady key, it should just say that's happening -- show it's an unauthenticated connection -- rather than opening a dialog. If you make key certification a separate, explicit step that the user has to actively pursue (which is what all pgp implementations do), then you don't have to worry about clueless users "accepting" a shady key and it being forever trusted after that.

What PGP gets right that the CA/X509/SSL-blob doesn't, is that it acknowledges that there are degrees of security and trustworthiness. That happens to fit the real world. When X509 fails to fit the real world, that's when people fuck up and get into trouble, by either trusting (permanently) a key they can't trust, trusting a CA they don't know anything about, etc. They have to do these things, because if they answer No to the stupid and unnecessary dialog, they don't get to get their work done.

Re:You're doing it wrong

[Sloppy]

However, I'm sure a sufficiently trustworthy entity could be found for that purpose (on the other hand, I don't trust verisign at all).

This problem was solved 20 years ago by Phil Zimmerman. If you don't know 'em, don't trust 'em (very much). Trust them "moderately" instead, so that several of them have to conspire if they're gonna fool you.

The critical point here is that paying off one or two database admins may be easy, but buying off ALL of them should be difficult.

You're thinking along the right lines, but forget database admins and concentrate on key signers instead, and then you've really got it.

The first time the user enters a banking site...

Well, banks are a different case. We only need trusted introducers for total strangers, like online stores. Banks are things that users meet in the real physical world (at least once, when they set up the account, and the bank checks their id, etc). You don't need any sort of signer for that at all. The bank can give them the key or fingerprint right then, and the user can certify it themselves. At that point, the requirements for a conspiracy to MitM someone, means one of the endpoints need to be compromised (i.e. someone has to break into the banks' (or user's) computers first). You've pretty much solved the crypto problem at that point, and taken it to the next level.

Re:You're doing it wrong

[sexconker]

Uh, simply add that self-signed cert once.
Someone in IT will do it.

If people want to access email from home, tell them to remote into their machine at work.

Setting up your own CA doesn't fix the problems you mentioned (random access point fud).

Re:You're doing it wrong

[Anonymous Coward]

The problem with the whole scheme is certificate authorities and money. The only necessary verification involved in getting a "valid" certificate is money. All problems with the system are derived from this.

Because valid certs are merely a pay-out to the auths, too many certificates are self-signed, which means people see too many certs and learn to click "proceed", which undermines the old system.

Re:You're doing it wrong

[vadim_t]

Uh, simply add that self-signed cert once.
Someone in IT will do it.

Then another time for the website, and another one for the IM server, another time for the VPN, and a couple times more when servers get replaced...

Setting up a CA is a long term solution that only needs to be done once. You can then generate a new cert that will be recognized as valid by somebody in another country.

Setting up your own CA doesn't fix the problems you mentioned (random access point fud).

Yes it does.

If you're lucky:
You go to https://example.com./ It uses a self-signed cert. You accept it, connect to the right server. All is good.

If you're not:
You go to https://example.com./ It uses a self-signed cert. The man in the middle examines your cert, makes another self-signed one with the same details, and presents that to you. You accept it. Connect to the man in the middle who then connect to your server. You read your mail, administrate your servers and so on, while somebody is quietly logging all that data.

With a CA, your cert would be signed by the company's cert. Your company can sign certs with its key, but some random guy running an AP for nefarious purposes can't. The best he can do is to make a self-signed cert with your company's details, but you're not stupid enough to ignore that, are you?

Re:You're doing it wrong

[sexconker]

You don't trust random people. Good.
You don't trust GoDaddy. Good.
You don't trust Verisign. Okay.
You don't trust anybody. Uh...

Yet you propose trusting a random network of "A friend of a friend of a friend of a friend of a friend knows the guy who made this site."? Idiot.

SSL isn't there to guarantee the identity of the person you're talking to, nor their trustworthiness. SSL is there to make sure only they can see your shit. SSL also tries to answer "Who are they?", but as you mentioned, this information is unreliable. But it's still more secure than just about all dealings you do face-to-face.

If you want real security you get your ass a dog and have him stare down and sniff out, in person (dog), anyone you're about to do business with.

Re:You're doing it wrong

[sexconker]

FOOL!
You've just done Magic5Ball's homework.

I think the idea of a public revocation database has merit. How would I make sure that my connection to the database has not been tainted? How could this database as a business entity be designed in a way that's less vulnerable to social engineering attacks than the current system?

Does the idea of a public revocation database have merit? How would you make sure that your connection to the database has not been tainted? How could this database as a business entity be designed in a way that's less vulnerable to social engineering attacks than the current system?

Re:You're doing it wrong

[QuantumRiff]

However, Signed DNS entries will go a long way towards fully verifying that a web site is who they say they are.. which is what 80% of SSL certs are used for anyways..

Re:You're doing it wrong

[DavidTC]

If you make key certification a separate, explicit step that the user has to actively pursue (which is what all pgp implementations do), then you don't have to worry about clueless users "accepting" a shady key and it being forever trusted after that.

I think you've managed to say it much better than all my bitching about this issue has.

SSL is like if the only way to protect an area on the internet was to build cardboard walls with people walking around outside them ready to defend against attackers. This allowed people inside to safely recite credit card numbers and whatnot.

But some people wanted, you know, some privacy without having to rent defenders. Yes, without defenders, people can batter their way in. Or insert cameras and spy on us. We know that.

But without walls, they can just walk in. Or stand there staring at us and write down everything we say. Yes, we're not saying credit card numbers, but that doesn't mean we should have no privacy for our game of Magic the Gathering or whatever.

For the longest time, some people just painted defenders on the cardboard walls, which wouldn't help if anyone attacked, but satisfied the requirement that some defenders existed.

And people got used to that, and would happily walk past one at any time...even if it was supposed to have been at their bank, who logically should have had real ones.

Everyone realized this was insecure, so cardboard paintings were outlawed, and all the walls with people painted on them were torn down.

And now we're...more secure?

Re:You're doing it wrong

[DavidTC]

Forget 'fingerprint'. Like I said somewhere else here, banks should give out CDs with a branded Mozilla Prism or something on them, designed to only connect to their site, and has an icon in your Start Menu to do just that.

If users don't access their bank via their web browser, they can't ever be MitMd.

And someone's about to say 'But what about Linux users?'. Firstly, Prism works on Linux just fine, but more importantly, there's nothing stopping the bank from having a login accessible from outside their 'banking application'...and just tell the people who need to know where it is, not most people.

If 95% of users access their bank only through a 'banking application' and not via the 'web site' (Even though, of course, those are the same thing.), that's 95% of users who aren't subject to MitM. (Well, except via infection, but you can't stop that.)

Let people run it off the CD and put it on USB drive to run it places they can't install software. Be sure to make an iPhone app also. Have a Java version. It's just a damn web browser that looks like a program.

And, even better, you could eventually incorporate such things as real-time confirmation of CC purchases. And easy-to-use single-use CC numbers.

Re:You're doing it wrong

[sjames]

Or, according to past incidents if you order a personal cert from a lax authority which cares only that your credit card goes through.

Re:You're doing it wrong

[sexconker]

With a CA you set up, someone has to trust it explicitly by adding it as an exception, just as you have to do with individual certificates in your fud example.

ALL certificates are like this - modern OSs simply include and maintain a list of certificate authorities to trust.

Re:You're doing it wrong

[vadim_t]

Right, the difference is that you do it once, then always know afterward which certs are good.

I get one CA cert at my company. That's all I ever need. If I'm on the other side of the planet when the mail server catches fire, burns to the ground, and is replaced by one with a new key, I'll still be able to log in securely, because they'll sign the new one with the CA cert.

Re:You're doing it wrong

[andymadigan]

Heh, I suppose you're right. Though of course I hope my answer makes it clear that a public revocation database doesn't have merit, which probably isn't the answer the teacher is looking for.

Re:You're doing it wrong

[Anonymous Coward]

Those are sites where I don't really care if my password is sniffed or not.

It was cited as being significant because of the apparent number of people who use the same password on every site. If you log in to your blog on an unencrypted connection using the same password as you use for online banking, you might have a problem.

Do we have demonstrated evidence that they've been used to subvert transactions with well-known sites like major banks and online retailers

Didn't somebody just issue a working Paypal exploit a few days ago?

Finally there's the suggestion that browsers never permit people to accept certificates that have expired or are self-signed.

That was just some random survey respondent's comment.... and it doesn't say anything about self-signed certs, it says expired and invalid. A self-signed cert is not invalid, and there's an appropriate way to deploy that sort of cert in your organization...

I don't think you paid very close attention to the article.

Re:You're doing it wrong

[sexconker]

"If your employees every day click on "Ignore self-signed cert" button, then they'll click on it the time when they connect to some random open access point that's set up to generate self-signed certs for any SSL website."

With a self-signed cert, you just add it to the exceptions once. Employees don't get trained in bad behavior.

With your own CA authority, you do the same thing.

The ONLY difference is that it's once per authority vs once per certificate. A small company will only need a couple certificates.
A large company will just buy a glob of certificates from verisign and be done with it.

Being your own CA doesn't protect you from any attacks, as users themselves should never be making the exceptions - per certificate or per authority.

Re:You're doing it wrong

[sexconker]

Yeah, I always hated those questions.

Is A true?
If A is not true, why not? What specific problems are there relating to B? How could C mitigate those problems?

Yes, A is true.

vs.

No, A is not true, blahblahblahblah repeat everything you said because that's what you want to hear blahblahblahblah even though you're wrong and A is actually true.

Re:You're doing it wrong

[vadim_t]

The ONLY difference is that it's once per authority vs once per certificate. A small company will only need a couple certificates.

Management gets much easier when you do it once per CA cert. Then you never have the issue of "crap, adding this new server means going to all of 50 employees and fixing it". Guaranteed somebody is on vacation or sick.

I'm a firm believer in doing a bit of extra work now, so that you don't have to do it later, when for instance the mail server catches fire. Because that's exactly when you don't want any extra work.

A large company will just buy a glob of certificates from verisign and be done with it.

Why would it? Doing it internally is cheaper. Making a cert takes about one minute.

New person in the company? They get assigned a desk, a computer, given the CA cert and shown what to do with it. They're maybe issued a personal client certificate.

Person leaves the company? Personal certificate gets revoked, VPN server won't accept it anymore.

Being your own CA doesn't protect you from any attacks, as users themselves should never be making the exceptions - per certificate or per authority.

Then why the complaints? Surely all the whining can't be coming from people who think the way it should be done is having a tech going from computer to computer adding a cert.

No, the complaints come from people who think browsers should just shut up about their https://john-doe.com/ having a self-signed cert.

Re:You're doing it wrong

[Magic5Ball]

Context: I've successfully purchased commercial certificates (can re-sign other certificates, etc) from the common vendors having provided less documentation than is required to set up a business banking account. Further, it was acceptable and required to fax copies of such documents "because faxes can't be Photoshopped like e-mail attachments". Further still, I've unintentionally faxed the wrong documents and have still received certificates. From this experience, I deduce that there is the current business SoP around such things is weak, even without being gamed.

In investigating relationships amongst parties to a number of recent confidence scams, we've encountered researchers and investigators who have arrived at the same conclusions about the providence and legitimacy of interesting certificates which are in the wild, where a public list of known bad certificates would have saved time, money, and other costs. If such a thing existed, I would still have questions about security of access since recent published work (not on /.) has highlighted important flaws about what we can assume about factors around, but not in, the secure connection.

You may continue to be glib, but I ask you to consider being part of the solution.

Re:You're doing it wrong

[Kalriath]

New person in the company? They get assigned a desk, a computer, given the CA cert and shown what to do with it. They're maybe issued a personal client certificate.

Person leaves the company? Personal certificate gets revoked, VPN server won't accept it anymore.

Out of the question! You have your group policy set to add your company CA cert to Trusted Root Certification Authorities on each client PC. No showing people what to do with it at all.

Re:You're doing it wrong

[andymadigan]

Why not simply have a public database of valid issued certificates? That way you can know when a bad certificate without needing to encounter it. You still need to check the database for certificates with either solution, but the revocation database seems like useful.

I'm not being glib, I'm being serious.

Re:You're doing it wrong

[sexconker]

Uh, group policy makes it a one time, all users, users-never-sees-it, deal.

Re:You're doing it wrong

[Magic5Ball]

I wouldn't mind having at least both kinds of database since they encode different information.

Building the list of valid issued certificates requires trusting the CAs, other issuers, and their clients to be truthful, accurate and timely with the information they supply about valid certificates. We can only take on faith that whomever is compiling the list does so well, based on information and credentials from meatspace. There are also exposure/competition reasons for not disclosing to the public the list of all your certificates, which would make the contours of this list and its subsets interesting with respect to unintended disclosure from the malevolents.

Building the list of invalid certificates distributes the burden of correctness on whomever wants to contribute to the list. It would provides an opportunity for the determination of validity of each entry to be made by the user of the list, based on the independent verifiable evidence supplied by whomever wants to indicate that a certificate has problems. This is the method of operation of several successful lists of invalid ISPs, invalid routes, invalid hosts, etc. in related spaces.

The list of issued certificates would be great if it provided a way to independently verify that the certificates were legitimately issued to valid entities, but privacy legislation generally prevents that from being viable in most jurisdictions. But in the absence of a secure connection or a capable bureaucracy, my preference would be for tainted information I could independently verify or refute, over tainted information which I could not independently verify in any way.

Re:You're doing it wrong

[andymadigan]

If browsers won't accept the certificate unless it's in the database, then the database *will* be correct. Certificates that aren't in the database ought to require some sort of user intervention to permit them, even if they are "private" certificates. Basically publication in the database would be part of getting the certificate issued, and would be a requirement for it to work properly, thus privacy legislation wouldn't apply.

If a CA is found to be issuing illegitimate certificates (they would have to publish them if they want them to work...) then they won't be a CA much longer. However, as it stands now, it sounds like any CA can issue an illegitimate certificate, blacklisting them all doesn't sound workable.

I'm surprised something like this wasn't done at least for those new "EV" certificates they were hyping.

I liked netscape's method

[Anonymous Coward]

"browser vendors unable to settle on a single method of showing if a site is secured by SSL or not"

They put a thin but obvious blue border around the entire browsing window. Why does Firefox not let you select among a few different methods? I know not.

Re:I liked netscape's method

[Anonymous Coward]

Why does Firefox not let you select among a few different methods? I know not.

THIS CONNECTION IS UNTRUSTED

You have asked Firefox to connect securely to this website, but since whoever signed their certificate hasn't paid us thousands of dollars to treat their certificates as 'safe', we can't confirm that your connection is secure. So even if it your blog's admin panel and you use a self-signed certificate, you have to jump through hoops to continue. All in the interest of protecting stupid people and making Verisign boatloads of easy money.

[Get me out of here!]

[I understand the risks and want to have to click another 10 times to view the website]

Re:I liked netscape's method

[EXrider]

Yeah, we'll we'd all like to see Verisign and the like not charge a fucking arm and a leg for a cert used to secure a webmail server, a mythweb server, etc.

I use StartSSL, they're a pretty decent provider of free class 1 certs, and their root certs are already in every major browser except IE, and they provide a nice lil' page that you can link to, to install the root certs into IE (after clicking through like 8 IE warning dialogs, no joke). They also use RSA for the signing algorithm, not that MD5 crap. You can also add their root certs to the domain certificate policy in Active Directory to get the root certs automatically distributed to all the IE users in your domain.

Re:I liked netscape's method

[assassinator42]

Thanks for the link.
Actually, Microsoft added them as a Windows root CA last month, so now it does work in IE. I already had it installed in Vista.
On a side note, does anyone know how to import and use the certificates generated by StartSSL for Remote Desktop on Vista? It will create a self-signed certificate by default, but I don't see a way to generate a certificate to be signed for a qualified domain name or import a certificate and private key generated by the site.

Re:I liked netscape's method

[EXrider]

I haven't messed with certs in RDP as I do all my RDP sessions over SSH tunnels and VPN. But I would guess that you'd import the certificate through the Certificates MMC snap-in similar to how you do signed e-mail in Outlook.

SSL is dead for 10 years

[Anonymous Coward]

SSL is no more for 10 years.

You have to copy TLS 1000 times on the blackboard :
http://en.wikipedia.org/wiki/Transport_Layer_Security
http://tools.ietf.org/html/rfc2246

Re:SSL is dead for 10 years

[hardaker]

The humor for me with your comment (not that I have mod points) is that RFC2246 is obsolete:

# rfcfind -n 2246
2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999.
(Format: TXT=170401 bytes) (Obsoleted by RFC4346) (Updated by
RFC3546) (Status: PROPOSED STANDARD)

And what's better, is that RFC4346 is ALSO obsolete

# rfcfind -n 4346
4346 The Transport Layer Security (TLS) Protocol Version 1.1. T.
Dierks, E. Rescorla. April 2006. (Format: TXT=187041 bytes)
(Obsoletes RFC2246) (Obsoleted by RFC5246) (Updated by RFC4366,
RFC4680, RFC4681) (Status: PROPOSED STANDARD)

So, you're yelling at them for using old terminology and documentation when in fact you're doing the same!

and WHY doesn't Slashdot use HTTPS?

[Anonymous Coward]

I want security in my browsing... why doesn't Slashdot offer THEIR content over a secure HTTPS connection? I don't want anyone to know that I read the "idle" section and which posts I read.

Re:and WHY doesn't Slashdot use HTTPS?

[Anonymous Coward]

Performance overhead of encrypted connections, we can't even get UTF8 due to performance concerns, what makes you think we're going to get HTTPS?

Re:and WHY doesn't Slashdot use HTTPS?

[buchner.johannes]

caching.

Re:and WHY doesn't Slashdot use HTTPS?

[pjt33]

How would HTTPS help? You'll still probably do an unencrypted DNS lookup for idle.slashdot.org.

Re:and WHY doesn't Slashdot use HTTPS?

[Anonymous Coward]

Not to mention the fact that the GETs will have to have their endpoint identifiers unencrypted, and so the IP addresses will be available, which means they'll know how MANY requests you've made to /.

Re:and WHY doesn't Slashdot use HTTPS?

[Just Some Guy]

why doesn't Slashdot offer THEIR content over a secure HTTPS connection?

Probably because it'd be freakishly expensive to pay for that much computing horsepower for something that just doesn't matter. Don't want people to know you read idle? Then don't read idle from places where you don't want to be monitored. Honestly, it's not like someone's snooping your online banking.

Re:and WHY doesn't Slashdot use HTTPS?

[Anonymous Coward]

I was trying to be funny. "woosh" would be an appropriate noise to make now.

Re:and WHY doesn't Slashdot use HTTPS?

[smoker2]

Computing horsepower ? It's ok for slashdot to inflict painful javascript and useless CSS on us but if THEY have to implement a fairly light security system it's too much ! fuck off.

Re:and WHY doesn't Slashdot use HTTPS?

[muckracer]

> it'd be freakishly expensive to pay for that much computing horsepower for
> something that just doesn't matter.

So what about the login/password?

Re:and WHY doesn't Slashdot use HTTPS?

[Nursie]

Why not do what I do?

SSH tunnel into home, with Firefox pointed at a dynamic port forward to use as a SOCKS server. Then go into about:config and activate the setting for DNS lookups through proxy.

Voila, now all work can see is you transferring encrypted data to and from home. They may think you're into industrial espionage, but they'll never be able to tell you were visiting /.

Re:and WHY doesn't Slashdot use HTTPS?

[Just Some Guy]

It's ok for slashdot to inflict painful javascript [...] on us but if THEY have to implement a fairly light security system it's too much !

In other news, it's easier to distribute work across a million clients than to build one server to do the same amount of work.

[...] and useless CSS [...]

Oh, you're one of those table-layouters. I apologize for wasting your time with references to modern technology.

Re:and WHY doesn't Slashdot use HTTPS?

[Just Some Guy]

So what about the login/password?

Now, that's a valid and appropriate use. It doesn't buy you much over digest authentication, though, and that's supported by almost everything but IE5.

Re:and WHY doesn't Slashdot use HTTPS?

[Anonymous Coward]

You're an idiot, it's not "fairly light" at all and decreasing performance on client machines only costs them the network bandwidth needed to send them the code that does it (Excluding intangible costs). Network bandwidth is cheaper than CPU cycles.

Re:and WHY doesn't Slashdot use HTTPS?

[kimvette]

There is a much larger processing requirement for transferring everything via https plus the bandwidth requirement is higher. Some days slashdot loads slow enough - do you really want to see a performance reduction? What you'll see is a return of ads to offset the increased server and bandwidth costs, and the ads will slow load time as well. (What, you still see ads here? Stop trolling, get your karma up then you can turn ads off)

I know, you're kidding, but a lot of people are going to take your comment seriously, hop on this and say "Yeah, why doesn't /. do everything over https?" - what they don't realize is that it introduces a fair bit of overhead that adds up very quickly when you have thousands of concurrent users.

Re:and WHY doesn't Slashdot use HTTPS?

[Anonymous Coward]

As you hinted, the encrypted traffic this causes may not fly under the radar in some work places.

In high security work places (military?) where internet access is still allowed they don't permit encrypted connections and they're blocked where possible. Everything is logged/monitored of course.

If you really want your non-work related internet activity unmonitored just don't use the company network. Your company can't monitor activity on your iPhone for example. It's much harder anyway. As wireless bandwidth gets cheaper this will probably become common place.

Re:and WHY doesn't Slashdot use HTTPS?

[Sloppy]

Probably because it'd be freakishly expensive to pay for that much computing horsepower

freakishly expensive computing horsepower? Sometimes I think I'm the only person who has noticed that computers are getting freakishly fast, and that what was once a multi-million-dollar supercomputer, now comes as a free toy in a box of Cap'n Crunch.

Re:and WHY doesn't Slashdot use HTTPS?

[Just Some Guy]

freakishly expensive computing horsepower? Sometimes I think I'm the only person who has noticed that computers are getting freakishly fast, and that what was once a multi-million-dollar supercomputer, now comes as a free toy in a box of Cap'n Crunch.

True. Now multiply by the requirements of a few tens of thousands of concurrent SSL connections and we're back to the good ol' days.

Re:and WHY doesn't Slashdot use HTTPS?

[Burz]

There is a much larger processing requirement for transferring everything via https plus the bandwidth requirement is higher.

Most browsers cache the symmetric session key so it can keep re-using the secure link instantly. Its plenty fast for subsequent requests.

The main drag with Https is the non-caching of page content. It would be nice if users could turn on caching on a site-by-site basis, thus opening up the possibility of making non-critical sites somewhat more private.

Re:and WHY doesn't Slashdot use HTTPS?

[sexconker]

There is no distribution.
My PC is not helping your browser render the shitty css and run the shitty javascript.

Work to render this page: W.
Work to render this page for N users: NW.

Nothing's wrong with table layouts if it works for what you need.
It's a billion times faster than CSS.

For slashdot (at least in the nested view I use) table layouts would work, but be ugly.

What certainly doesn't work is the CSS/javascript/whatever that lets people tag a story. Simply. Can. Not. Tag. Stories.

Re:and WHY doesn't Slashdot use HTTPS?

[DavidTC]

Users shouldn't turn it on, sites should. There should be an HTTP header that says 'Even if this came over an SSL link, it does not contain any private information, and you should feel free to cache it on disk.'. Web servers could add it to all static images by default.

Right now, it's all put in the session cache, but there's plenty of stuff, like images and CSS, that could stay around without any security concerns at all.

What would also be nice is, while you're doing that, would be to be able to put that cacheable SSL content in non-SSL pages. (That is not a security issue...the other way around is.) So that you could hand them, on your starting page, your background graphic over SSL, and get that cached and used on all pages, both SSL and non-SSL, even if they had not clicked 'Login' and entered the SSL area of your site yet.

Yes, you can use pre-loading and cache it in the background, but the point would be to use a single URL on the entire site so it's only downloaded and cached once, preferably on disk, instead of being cached once SSL and once non-SSL.

...now that I think of it, I'm not entirely sure what happens if you have SSL content on a non-SSL page. Pretty sure you get a warning, or Google Analytics wouldn't have that goofy code in their javascript. Does anyone know what the point of this warning is? The whole point the other way around is so you can't hijack the pages marked as secure by replacing non-secure elements...what the hell is the supposed issue if the page isn't marked secure?

Re:and WHY doesn't Slashdot use HTTPS?

[Torodung]

Browsing through proxy might fix your privacy issues, if you're at all serious. VPN through a proxy if you're nuts.

--
Toro

Re:and WHY doesn't Slashdot use HTTPS?

[arkane1234]

The DATA....

Re:and WHY doesn't Slashdot use HTTPS?

[buchner.johannes]

See? Parent was modded informative by people who misunderstand SSL/TLS.

There is a phase called authentication in SSL/TLS. It includes exchanging a certificate. If you enter https://foobar/ in your browser, you will either
a) get a error, because the cert is not known to your browsers root CA structure or
b) get a encrypted, mitm-attack-safe end-to-end connection
At that point it does not matter if your traffic is relayed because of a DNS hijack.

You will never be able to guarantee that traffic is transferred, and you'll never be able to guarantee that others are not listening. The former you will notice, the second does not matter (the statement "most of them are aware that SSL traffic can be sniffed without their knowledge" in TFA is also misleading).

Re:and WHY doesn't Slashdot use HTTPS?

[pjt33]

You haven't yet been modded overrated for not understanding DNS, but maybe someone with mod points will stop by...

Before you exchange certificates you need the IP address of the other end. If Anonymous Coward doesn't want anyone to know that he reads the "idle" section then he needs to get the IP address of idle.slashdot.org without doing an unencrypted DNS lookup for it. How common is encrypted DNS?

PS You forgot to mention
c) get a MITM-attacked connection which your browser thinks is fine because it appears to be signed with MD5 by Thawte.

Re:and WHY doesn't Slashdot use HTTPS?

[Kalriath]

They do. If you subscribe to Slashdot, you have to option to browse it over TLS. Non-subscribers are bounced back to the unencrypted version though.

Re:and WHY doesn't Slashdot use HTTPS?

[buchner.johannes]

No. It does not matter that the channel for exchanging the certificate is unencrypted. Thats why there is a CA tree. You have the upper structure of the CA tree in your browser.
If you receive a cert, signed by someone you know, it is ok. It is irrelevant whether you received it through a unencrypted connection.

It is the magic of security that insecure channels can be used for secure communication using prior knowledge (keys).

Granted, MD5 collisions are a attack vector, and also drive-by-downloads that modify your CA database. But that wasn't your point.
Start reading here:
http://en.wikipedia.org/wiki/Transport_Layer_Security#How_it_works

Re:and WHY doesn't Slashdot use HTTPS?

[pjt33]

I know MD5 collisions wasn't my point - that's why I made that a PS - but you still haven't got what my point is. Ignoring insecurities in the PKI and TLS implementations, TLS can prevent eavesdroppers from knowing what data you're sending and receiving, but it can't prevent them from knowing with what server you're communicating. The eavesdropper can still sniff the IP address in the IP packets, and the DNS request which is necessary before you even send your SYN packet, which itself precedes certificate exchange. TLS is cryptography, not steganography.

SSL is trying to do too much.

[argent]

Forcing people to implement both privacy and authentication in one package is half the problem with SSL. For most sites, it's more important to know that the site you're visiting is the same site you visited last time, than knowing that foo.example.com has a signed certificate approved by someone you never heard of. If these two functionalities were separated, so the browser just checked that a "non-certified" site's encryption key hadn't changed and let you through without comment if that was the case, then most sites using old or self-signed certificates would just use the encryption layer, and browsers COULD block access to sites with invalid certificates without causing people so much inconvenience they'd want to switch to a different browser that was less picky.

(yes, I know that this would probably be implemented using self-signed certificates, but it could be presented to the user as a "low security" site with an appropriate icon and at most a comment that "you haven't visited XXXX.example.com before, it is a low security site..." the first time you see it)

Re:SSL is trying to do too much.

[Lennie]

The problem with this is, certificates expire.

Re:SSL is trying to do too much.

[Drencrom]

Totally agree with this. If I dont want to spend money paying a certification authority I should be able to encrypt anyway without the browser warning the user in big red letters that I am a pirate. Firefox warnings are geting worse in each version and, for the user perspective, it seems that encrypting with a non official certificate is much worse than not encrypting at all. By the way I use cacert to generate my certificates; it should be inlcuded in the default Firefox certification authorities list. I suspect there is money involved in getting into that list though.

Re:SSL is trying to do too much.

[Anonymous Coward]

Without authentication someone can always eavesdrop using a man in the middle attack, this means that you can't have privacy without authentication .

This misconception that privacy and authentication are independent is one of the facts that several IT professionals gets wrong.

Re:SSL is trying to do too much.

[itsdapead]

Totally agree with this. If I dont want to spend money paying a certification authority I should be able to encrypt anyway without the browser warning the user in big red letters that I am a pirate.

Except, if you don't verify the identity of the recipient, encrypting data is as much use as putting a steel door on a tent. Maybe that's why encryption and authentication are joined at the hip?

The behaviour of Firefox is absolutely correct: it strongly discourages people who don't know any better from connecting to unverified sites, but does not prevent it.

If you want to run an encrypted site without shelling out for a certificate, then fine - but its up to you to reassure visitors that you're not evil.

The real problems are that (a) its such a hassle to drill down to the name of the certificate holder and (b) when you do find it its usually something like "No Obvious Connection to the Website Corp. (Holdings) PLC". (the extended ID in Firefox helps, where its used).

Re:SSL is trying to do too much.

[argent]

Self-signed certificates can be regenerated automatically, or simply set to have a renewal date after the world ends in 2038.

Re:SSL is trying to do too much.

[argent]

Technically, you're correct. Technically, "this is the same site you visited the last time" is a very weak form of "authentication". Thing is, this is all the "authentication" most services need.

Re:SSL is trying to do too much.

[jcochran]

It's not that simple.

Yes, without authentication, you can be subjected to a man in the middle attack.

However, that attack is an active one.

Without encryption, you can be subjected to a simple passive sniffing attack. Put a hub somewhere in the connection and sniff every packet that goes by. No need for an active attack. No need to establish two encrypted sessions (one to victim, one to victims intended destination). No need to interpret and alter packets going between the victim and destination.

Does encryption all by itself prevent all attacks? No it does not. Does it provide more protection than sending in the clear? Yes it does.

Re:SSL is trying to do too much.

[argent]

If you want to run an encrypted site without shelling out for a certificate, then fine - but its up to you to reassure visitors that you're not evil.

There's nothing stopping an evil company from getting a certificate. Consider Microsoft as an example. Or Verisign. Or Aristotle.

What you mean to say is "it's up to you to convince your visitors that you're who you say you are".

If all I'm saying is "I'm a video game web forum" then my visitors don't need anything more than "I'm using the same self-signed certificate I used the last time".

Re:SSL is trying to do too much.

[dkf]

If all I'm saying is "I'm a video game web forum" then my visitors don't need anything more than "I'm using the same self-signed certificate I used the last time".

Frankly, a video game web forum doesn't need encryption except for the matter of identifying users, and something like OpenID could be used for that.

Re:SSL is trying to do too much.

[smoker2]

The main problem with "secure" sites is that too many people don't realise that the site is not what is secured. It is only the connection to the site that is encrypted, the server itself could be sitting in a room full of chinese hackers for all you know. Too many sites mention their "secure server" when in actual fact the machine is sat in a rack with thousands of other machines surrounded by minimum wage techs.

My open university course makes this mistake right at the beginning. It specifically says that "the letter 's' [appended to http] means you are connected to a secure web server, using techniques to protect your details from electronic snoopers". This is not true. Your precious credit card details could be sat on that server in plain text and you would be none the wiser.

Also, I have bought verified certs where the method of verification was an automated phone call to the number I gave in the application. What use is that ? I could be anyone, anywhere. So IMHO using certs for verification is a waste of time and gives entirely the wrong impression. Self signed certs are fine because they don't pretend to verify my identity, they just provide the details of who created them and encrypt the connection. If a 3rd party were to try phishing by creating their own self signed cert, the cached version in my browser tells me it is not valid because it has a different key. In this respect it is no different than a verified cert.

All the verification businesses go out of their way to avoid mentioning self signed certs, because they don't make them any money. But for the purpose for which they were designed, self signed certs are fine.

Re:SSL is trying to do too much.

[Hatta]

What use is encryption if you can't guarantee that there's not a man in the middle? This is why self-signed certs are a bad idea. That is, unless you want your users calling you up to manually verify your key.

Re:SSL is trying to do too much.

[Anonymous Coward]

So you are saying you shouldn't change the public/private key for for 20 something years? How is that secure?

Re:SSL is trying to do too much.

[vadim_t]

Any company can get a cert.

What's important is that they're not supposed to be able to get one for a domain not of their own. So for instance, a Microsoft employee can't get a cert for paypal.com then sit somewhere between your network and the internet and perform a man in the middle attack.

Re:SSL is trying to do too much.

[ObsessiveMathsFreak]

Firefox warnings are geting worse in each version and, for the user perspective, it seems that encrypting with a non official certificate is much worse than not encrypting at all. .... I suspect there is money involved in getting into that list though.

The only sane reason I can come up with for the continuing insanity of the Firefox self signed cert warnings is direct kickbacks to the Mozilla foundation from Verisign and the like. I have little doubt that at the very least, "consultation" with Verisign and the like lead to that ridiculous yellow policeman and his preference for plaintext or paid certificates.

Self signed certs serve a purpose. They offer an encrypted connection, which is a solid and concrete improvement over a plain text transmission. Sure they are not signed by proper "authorities". Sure, there is the risk of a man in the middle attack. But you tell me which is more likely. Your encrypted login being intercepted by a man in the middle, or your unencrypted login being intercepted by a traffic sniffer?

The current hysterical warning Firefox throws up about self signed certs, which force users to run a gauntlet before they can use an encrypted channel are the sign of developers too concerned with internet commerce and cold war game theory to see the practical benefit of mass, cheap, encryption in this day and age. But given their tone and severe implementation, I find it difficult to believe that an open source development teams came to that decision on their own.

Firefox has single handedly set the secure web back five years. Instead of allowing the web and technology to evolve beyond its specifications, they stuck rigidly to RFC outlines made thirty years ago, and we are all suffering because of it.

Re:SSL is trying to do too much.

[smoker2]

The real problems are that (a) its such a hassle to drill down to the name of the certificate holder and (b) when you do find it its usually something like "No Obvious Connection to the Website Corp. (Holdings) PLC". (the extended ID in Firefox helps, where its used).

It is not a hassle to "drill down" to find the name of the cert holder. Firefox puts it right there on the front of the security popup. And most verified certs are verified to some unknown corporate division anyway - I don't see your point.

As for the "steel door on a tent" quip, the same is true for verified certs. They make no claim about the security of the SITE, only that the cert was issued to such and such and the connection to that site is encrypted. Given the recent \0 fiasco, you should realise that using a cert for verification is unrealistic at best and misleading at worst. Certs are for encryption.

Re:SSL is trying to do too much.

[Anonymous Coward]

If you want to run an encrypted site without shelling out for a certificate, then fine - but its up to you to reassure visitors that you're not evil.

It is anyway. You think the CAs check to make sure "that you're not evil?" Of course not. If you have a valid business mailing address and enough cash, you will get a cert. That's all it takes. More importantly, no cert will tell you that your bank's web site is wamu.com and that washingtonmutual.com is a phishing site. Because the latter could have a perfectly legitimate cert signed by a trsuted CA, no browser will warn you that anything is wrong (because, as far as the browser can tell, everything is great).

Re:SSL is trying to do too much.

[argent]

So you are saying you shouldn't change the public/private key for for 20 something years?

If all you're securing is a session to a web forum where there are no assets at risk, sure.

It's more security than not using TLS at all.

Re:SSL is trying to do too much.

[Anonymous Coward]

As the article talks about, I'm one of the ignorant ones in regard to SSL/TLS. After reading the comments here about self-signed certificates and the desire to separate out their authentication & encryption purposes, I came up with an idea and wondered what problems there were with it.

Since certificates are tied to domain names, why don't we have registrars be defacto certificate authorities? All browsers would have each registrar's root CA certificates in their CA store. When a person registers a domain name, the registrar also gives them either an issuer certificate for that domain or a wild card certificate for that domain. The person could then either use the issuer certifcate to make more (www.example.com, store.example.com, etc.) or just use that wild card certificate (*.example.com).

These certificates would be good for private but only semi-authenticated connections with the domain's servers. If the domain owner wants to prove to the world his/her identity, then we could still have something akin to the Extended Validation (EV) TLS certificates. The domain owner could provide identity documentation (and pay more) to the registrar or a trusted-third party for one of these EV TLS certificates. Those EV TLS certs would show up differently in a user's browser. ("The identity of 'store.example.com' has been validated. Your connection with it is private.")

The only problem I see is that current certificate authorities wouldn't want their business model destroyed.

Re:SSL is trying to do too much.

[argent]

Where have I suggested that Paypal should use self-signed certs?

The point is that there's thousands of sites... no, hundreds of thousands... that are wide open for sniffing that would be using TLS if it was possible to set it up as easily as you can set up SSH. This possibly didn't used to be an issue but is getting more so as more and more businesses provide things like free wifi.

For these sites the same level of authentication as SSH, "this is the same server as you visited last time", is adequate to deter MITM attacks.

Re:SSL is trying to do too much.

[argent]

What use is encryption if you can't guarantee that there's not a man in the middle?

Unless your very first connection to the website and EVERY subsequent connection was intercepted by the SAME attacker, for every person in a position to detect the fraud, for the entire duration of the scam, simply verifying that the certificate is the same as the last time provides sufficient authentication to deter all but the most dedicated attacker.

So... sites where significant assets are involved would not use self-signed certificates, because the kind of resources required to set up and maintain this kind of deception are not impossible. But for most services on the Internet this kind of fraud would cost orders of magnitude more resources than could conceivably be recovered from the victim.

Re:SSL is trying to do too much.

[vadim_t]

Here's a question:

When you're ssh-ing into your computer, how many precautions do you take?

Do you never, ever ssh from a device you don't personally trust completely?
Do you remember or have written down your SSH server's fingerprint so that you can tell it's the right one?
If you for instance go on vacation, ssh from your laptop to your server and get the wrong fingerprint, do you abort and wait until you get home to sort it out?

If you said no to any of these, you're not really very secure.

I do all these things, but most people who use SSH don't. I've seen administration scripts written with "expect" to automatically accept an unrecognized key.

Re:SSL is trying to do too much.

[Timothy Brownawell]

If all I'm saying is "I'm a video game web forum" then my visitors don't need anything more than "I'm using the same self-signed certificate I used the last time".

Frankly, a video game web forum doesn't need encryption except for the matter of identifying users, and something like OpenID could be used for that.

I thought the goal was to have everything encrypted, regardless of whether it's illegal and needs to be hidden, if for no other reason than to mildly annoy the NSA.

Re:SSL is trying to do too much.

[Timothy Brownawell]

What use is encryption if you can't guarantee that there's not a man in the middle? This is why self-signed certs are a bad idea. That is, unless you want your users calling you up to manually verify your key.

Or using something like Perspectives to get much the same effect.

Re:SSL is trying to do too much.

[Drencrom]

Following your analogy, why is a tent with a steel door much worse than a tent with no door? I don't need firefox to put a big security padlock on sites with untrusted certificates, just encrypt, shut up, and behave like a normal http site.

Re:SSL is trying to do too much.

[DavidTC]

This is the biggest problem I have with SSL, that no one ever bothered to set up a system for encryption without authentication.

Which would, for one thing, make it much harder to sniff paswords. (Yes, yes, there's HTTP Digest...if you use HTTP auth, which no normal web site does.)

Re:SSL is trying to do too much.

[DavidTC]

Except, if you don't verify the identity of the recipient, encrypting data is as much use as putting a steel door on a tent.

You know, you hit that analogy perfectly, but apparently did not bother think about it.

A steel door on a tent is much better than no door on a tent.

Let me guess: You think locking a car or house is a waste of time, because any fool can break in via windows? You think it would be better if we couldn't lock our car or house, because locking it gives us a false sense of security?

Perhaps, you should maybe consider that those of us who want a little more security know exactly what we're asking for and what the weakness of it is, but think sometimes a small level of security is a better choice than none?

That maybe we think protecting web forum password from sniffers, and from man-in-the-middle attacks because it saved the cert when you went there the first time, might be a vaguely logical thing to do, and yet those thousands of forums are not going to purchase SSL certs?

Oh, and while we're at it, companies would no longer have to fuck around with self-signed certs for intranet sites.

Re:SSL is trying to do too much.

[itsdapead]

It is not a hassle to "drill down" to find the name of the cert holder. Firefox puts it right there on the front of the security popup

Yes, but that is a fairly recent innovation in Firefox and other browsers. Previously, it was several clicks down from the "golden padlock".

And most verified certs are verified to some unknown corporate division anyway - I don't see your point.

The point is that the name on the cert should reassure me that I'm dealing with who I think I am. Often, it doesn't help. If I go to an "Acme Bank" site and find the certificate is registerd to "ABIS.com" it doesn't really help. The new Extended ID system fixes this.

As for the "steel door on a tent" quip, the same is true for verified certs.

At least that's a steel door on a moderately sturdy wooden shack, which is an improvement.

Certs are for encryption.

No - public keys are for encryption. Certs also have to solve the problem of identity verification, and that's always going to be the weak link. Public keys are great - you can give me your PK without worrying about me keeping it secure - but unless you hand it to me personally, I have no way of knowing that it really comes from you. That's where certificates and trusted third parties come in.

Re:SSL is trying to do too much.

[Timothy Brownawell]

Since certificates are tied to domain names, why don't we have registrars be defacto certificate authorities?

This will happen somewhat automatically when DNSSEC is finally implemented (in a couple years, I think). Then all you'll need is a standardized DNS record type to give your cert fingerprint, there might even be a standard ready and waiting.

Re:SSL is trying to do too much.

[DavidTC]

....erm, does OpenID support HTTPS? How does that work? You'd need to specify https, and then the OpenID site would need to spring for an expensive wildcard cert.

Which they won't for their free OpenID service.

OpenID does not solve the problem people are talking about solving.

In fact, OpenID doesn't really solve any existing problems at all. It would be a cool concept if, you know, web browsers didn't store login cookies and names and passwords. But as they do, it is hard to see what OpenID is bringing to the table. It's a cool idea, and I wish them luck, and there are ways I can see it becoming incredibly useful, but saying 'OpenID providers can get SSL certs' is not actually a solution to this.

Moreover, it only protects logins. If forums actually had SSL, they'd probably start using it for most private areas, as CPU time is now so cheap. Private messaging, user config, whatever.

Re:SSL is trying to do too much.

[DavidTC]

All browsers would have each registrar's root CA certificates in their CA store. When a person registers a domain name, the registrar also gives them either an issuer certificate for that domain or a wild card certificate for that domain. The person could then either use the issuer certifcate to make more (www.example.com, store.example.com, etc.) or just use that wild card certificate (*.example.com).

Congratulations, you have just invented DNSSEC.

Next task: Get root registrars to actually publish and issue root certificates to the registrars.

After that, get browsers to support them.

Re:SSL is trying to do too much.

[argent]

When you're ssh-ing into your computer, how many precautions do you take?

Heh, I was at a Usenix conference back in the '90s when someone discovered that there was a backdoored Kerberos install on the computers in the terminal room. I know how this game is played.

I ssh from my own laptop. I am nervous about sshing from my own colo server. I have had a couple of unexpected key change messages and each time I contacted the person responsible for the server to verify that, yes, they had reinstalled the OS or accidentally trashed the key files.

I've seen administration scripts written with "expect" to automatically accept an unrecognized key.

I've seen websites with messages that say "if you get an invalid certificate message from this site, it's normal" too.

Re:SSL is trying to do too much.

[vadim_t]

Well, in that case, why do you have a problem with doing certs properly?

Get tinyca or something similar. Make a CA cert, and import it in all your browsers and applications. Then use it to sign keys for various services. With the CA cert there, any key it signs will be automatically valid.

Re:SSL is trying to do too much.

[Anonymous Coward]

Self-signed certificates can be regenerated automatically, or simply set to have a renewal date after the world ends in 2038.

Everyone knows the world will end in 2012.

Re:SSL is trying to do too much.

[argent]

Well, in that case, why do you have a problem with doing certs properly?

Because SSL certs are solving a different problem than SSH host keys, and for services that are simply looking for the solution that SSH host keys provide SSL certs are massive overkill.

Re:SSL is trying to do too much.

[argent]

Everyone knows the world will end in 2012.

Oh come on, nobody's using that old stone circle computer technology any more. Half of the Machu Picchu site is missing, they've lost the Nazca Plain key server, Avesbury is completely trashed (half the stones there are uncalibrated replacements), and Stonehenge was originally just a backup ring in case the Avon flooded: I bet you couldn't get a millithaum per second out of it even on the equinox AND with a FULL team of chanters on hand.

Re:SSL is trying to do too much.

[vadim_t]

SSL was indeed made to solve a different problem. And while sometimes ocassionally inconvenient IMO it's much better than the alternative.

Setting up services that work on a basis of "It's the same server as yesterday" only works well in two cases: When it's a company system, and when it's your own home server.

In the case of a company this works only until a certain point. It'll instantly become a problem if at your company people travel, and a server gets a new key for some reason while somebody is abroad.

In the case of doing it a home, you're knowledgeable enough already, so making a CA cert shouldn't be such a big deal. And current tools like tinyca make it very easy, no need to mess with openssl commands.

For most of the normal people such systems are not only not effective, but harmful. Knowing that a bank's cert is the same it was yesterday is of absolutely no use to anybody who doesn't work in the bank's data center.

Re:SSL is trying to do too much.

[argent]

Setting up services that work on a basis of "It's the same server as yesterday" only works well in two cases: When it's a company system, and when it's your own home server.

Or when the value to an attacker of an MITM attack is less than the cost of performing one, considering that the value of performing a MITM attack drops close to zero almost as soon as it's detected. For most of the websites that are currently not using any encryption because TLS is a pain in the backside, the probability of detection from any attack carried out on a large enough scale to be of any value to the attacker is very high... even if that value is only measured in "lulz".

Implementing an SSH-style mechanism would... within a matter of months at the most... allow EVERY new installation of Apache or any other web server to automatically and painlessly self-certify, by default. Sniffers would become increasingly useless as time went on.

Knowing that a bank's cert is the same it was yesterday is of absolutely no use to anybody who doesn't work in the bank's data center.

Where did I suggest that a bank use a self-signed certificate?

Re:SSL is trying to do too much.

[vadim_t]

Or when the value to an attacker of an MITM attack is less than the cost of performing one, considering that the value of performing a MITM attack drops close to zero almost as soon as it's detected. For most of the websites that are currently not using any encryption because TLS is a pain in the backside, the probability of detection from any attack carried out on a large enough
scale to be of any value to the attacker is very high... even if that value is only measured in "lulz".

This sounds to make like the assumption many people make: I don't need secure. Who would be interested in my cat photos? Security is for banks.

But, a MITM can be set up automatically. Take a laptop, set up an open access point at a well populated place, and log all SSL traffic. Eventually you'll catch somebody accepting your self-signed cert for their bank's website. If somebody figures out, it doesn't matter as they don't know who or where you are. You could set up such a system in your car's trunk, and go look at monuments and drink coffee in a bar without looking suspicious in the slightest.

Implementing an SSH-style mechanism would... within a matter of months at the most... allow EVERY new installation of Apache or any other web server to automatically and painlessly self-certify, by default. Sniffers would become increasingly useless as time went on.

I think it would fail horribly.

SSH's security relies on that first you get your key from an internal, secure network. Then if when using an external, unsecure network you see something's up when the key changes. The security hinges on knowing the difference between when there's likely to be a compromise and when there isn't. I'm sure 99% people don't understand that. For an user, networks are magic. They won't understand the difference between connecting through a LAN at home, unencrypted wifi to their home AP, LAN at a friend's house and random open AP they found somewhere.

Actually IMO browsers should refuse self-signed certs outright, with no way to work around it.

Where did I suggest that a bank use a self-signed certificate?

You didn't, but implementing such a system implies that self-signed certs are OK. For you, it's "they're OK in certain, well defined cases". Most people will understand "they're always OK, even from the bank" and will happily accept a self-signed cert from their bank.

Re:SSL is trying to do too much.

[nine-times]

I don't know, I think it makes sense if you can essentially get both for the cost of one. I think the problem is that you have to pay some arbitrary company relatively large amounts of money to authenticate your identity, and then they often do a bad job at it anyway.

This has been one of the reasons that I've kept an eye on the signing of DNS records. If you could sign your DNS records and verify that they're authentic, then it seems to me that you could also drop in an SSL cert for each DNS record and get CAs out of the loop (unless you really want some kind of EV-like service).

Re:SSL is trying to do too much.

[argent]

But, a MITM can be set up automatically. Take a laptop, set up an open access point at a well populated place, and log all SSL traffic. Eventually you'll catch somebody accepting your self-signed cert for their bank's website.

Where did I suggest that the browser accept a self-signed cert to replace a CA-signed cert?

Most people will understand "they're always OK, even from the bank" and will happily accept a self-signed cert from their bank.

Unless their bank is actually using self-signed certs, they won't be given the opportunity.

Re:SSL is trying to do too much.

[vadim_t]

Where did I suggest that the browser accept a self-signed cert to replace a CA-signed cert?

What if the first one they got was self-signed? What if they got a new laptop, or reformatted their computer so the browser doesn't know what the site had before?

You can only be reasonably sure you're getting the right cert when already having a secure connection to the target server. That only works when you're on a LAN at home, or on a LAN at work.

None of that applies to online shopping.

Unless their bank is actually using self-signed certs, they won't be given the opportunity.

They will be if somebody performs a MITM. There's no way for the browser to know "Banks are supposed to use a Verisign issued cert, home servers are OK with a self-signed one". Unless the user configures it somehow, and most users don't have a clue.

Banks also change certs, because they expire, or because the bank wants to change the CA (because it went bankrupt, doesn't offer extended validation, screwed something up, whatever).

Re:SSL is trying to do too much.

[DavidTC]

they've lost the Nazca Plain key server

Dude, that's not the problem. The key server's working fine, it's just the previous admin didn't document anything, so no one knows how to issue any more without doing the entire thing manually. (And drawing giant figures in by hand? No fun.)

Avesbury is completely trashed (half the stones there are uncalibrated replacements)

And the rest are uncalibrated originals. ;) Seriously, total crap.

Stonehenge was originally just a backup ring in case the Avon flooded: I bet you couldn't get a millithaum per second out of it even on the equinox AND with a FULL team of chanters on hand.

Stonehenge won't even boot anymore, because it's a stupid in-place restore over the damn original bluestones. It needs a full pull-down, leveling, and rebuild.

Re:SSL is trying to do too much.

[argent]

What if the first one they got was self-signed?

Then one time in a thousand the guy will get a single password before someone twigs that something funny's going on and calls the cops.

Even in the worst case the risk-benefit ratio is thousands of times better for phishing, even if you don't bother getting a valid certificate for bank0famerica.com.

Re:SSL is trying to do too much.

[argent]

I think it makes sense if you can essentially get both for the cost of one.

Except you can't.

You could get privacy and weak authentication (is this the same key as last time?) for effectively free. Adding strong authentication makes the cost significantly higher even if you get the actual cert for free, unless your time isn't worth anything.

Re:SSL is trying to do too much.

[vadim_t]

Then one time in a thousand the guy will get a single password before someone twigs that something funny's going on and calls the cops.

Good luck with that. These days the cops don't care unless it's something very, very substantial. It'll certainly take something bigger than "I think somebody might have got my bank's password". Most of the time the cop will have no clue what the hell you're talking about. And if they do it'll just get filed and stay archived, unless they catch the guy for some other reason and figure out some of the money was your. In any case, even if they believe you, the police aren't going to give your money back.

Even in the worst case the risk-benefit ratio is thousands of times better for phishing, even if you don't bother getting a valid certificate for bank0famerica.com.

That is a better point. Though IMO hanging out in the right area (like one full of big companies) might net something juicier than a random Joe's bank account.

Re:SSL is trying to do too much.

[sjames]

Except, if you don't verify the identity of the recipient, encrypting data is as much use as putting a steel door on a tent. Maybe that's why encryption and authentication are joined at the hip?

Then SSL should just go away. For practical purposes the lock icon means someone you don't know anything about has been paid to vouch for this other person. For example, "TURKTRUST Elektronik Sertifika Hizmet Saglayicisi". I'm not even sure how to pronounce that or type it with the accent marks I can guess at the first two words but have no idea what the last two mean. I have no idea what if anything else they do, how carefully they authenticate before they sign, how carefully they control their key, or anything else about them, but because they signed a certificate my browser would show the friendly lock icon. In truth, their signature means no more than if a stranger wearing a Nixon mask points to another stranger wearing a Nixon mask and says "that's Bob Smith". This isn't meant to be an indictment of them specifically, they're just the first CA that came up in the list. There are many others that mean just as much to me.

Re:SSL is trying to do too much.

[nine-times]

Please explain?

Re:SSL is trying to do too much.

[argent]

Joe Smith sets up an Apache server to run a Wiki for the hot new MMO Zombie Love Triangle. His server comes with all the software in packages, and his Wiki just comes up.

* In the real world, he doesn't bother setting up HTTPS, because it's a bit of a hassle. It's not much of a hassle, but it's a bit of a hassle. His users use HTTP. Someone sets up a sniffer at Zombie Love Con and much drama results when it's revealed that two of the hottest Zombies are actually alts of each other.

* In the world where SSL works like SSH, it comes with HTTPS with a self-signed certificate up and working, and the Zombie Lover sniffing packets gets nothing but line noise. Drama averted!

Objection: what about MITM attacks?

Answer: When the Zombie Apocalypse comes, you're still better off having to realize that the guy knocking on your door saying "Graah" is probably after your brains than just leaving the door open.

Re:SSL is trying to do too much.

[nine-times]

Sure, but my point about DNS is, imagine if you could get your SSL up and running with a self-signed cert, you dump that cert into your DNS record for that domain name, and you're your own certificate authority. That's not a huge expense of your time and could be done free. What's the downside?

Re:SSL is trying to do too much.

[argent]

Stonehenge won't even boot anymore, because it's a stupid in-place restore over the damn original bluestones.

And they're still doing ceremonies there? o_O

That explains all the out-of-spec crop circles we've been seeing lately. And why my Inukshuk is out of tune.

Re:SSL is trying to do too much.

[jp10558]

What do you mean by "fairly recent"? I recall it being just one click on the padlock in Opera 5.12 ~ 2001, and being able to find it somewhat easily in Netscape 4 ~ 1999.

I still think that the main problem is that the certificate generally tells you that you're connecting to a specific site, and with EV perhaps who runs the site, but nothing about the security or trustworthiness of the site or company.

Long Term Con man (web version of Madoff?) could certainly get certified all the way to EV and still plan to sell off your CC# in, say, a year.

There are small local banks, like the one my family does business with (I don't, and not just because of this), that have their web banking run by some other company, with the cert to this other company, and nothing in the cert nor the URL is related to the bank name at all. I've contacted the bank about this, to be told "oh, yes, that's how it is, we outsourced the website". And you couldn't get a decent virtualhost or something at www.bankname.com with the SSL cert issued to BankName? Really.

"Normal" people just tell me I'm overly paranoid...

Re:SSL is trying to do too much.

[Fulcrum of Evil]

So for instance, a Microsoft employee can't get a cert for paypal.com then sit somewhere between your network and the internet and perform a man in the middle attack.,/quote>

I'll bet they can figure out how to get a cert for \0paypal.com.

Re:SSL is trying to do too much.

[argent]

Sorry, I missed that. That's a nice improvement. Assuming you can get your name service provider to take on the records. Given how quickly DNSSec is progressing and the experience I had when I was just trying to get mine to put in a few rDNS delegation records... I ended up just making my servers 123.45.example.com and 124.45.example.com and doing everything through CNAMes, it was that painful, and I wasn't J Random Newbie at the time. :(

Re:SSL is trying to do too much.

[itsdapead]

A steel door on a tent is much better than no door on a tent.

No it isn't.

A zip fastener and a cheap padlock is enough to make it clear that your tent isn't public. Anything more is a waste of effort - and may just draw attention to your tent.

Let me guess: You think locking a car or house is a waste of time, because any fool can break in via windows?

Nope - but I do think that fitting an expensive high-security door without paying equal attention to the windows is pretty dumb.

Perhaps, you should maybe consider that those of us who want a little more security know exactly what we're asking for

So what is stopping you? People who "know what they are asking for" will understand what the warnings in Firefox are all about and click through them in 10 seconds the first time they visit the site. If someone is put off by the warnings then they clearly don't "know what they are asking for".

That maybe we think protecting web forum password from sniffers, and from man-in-the-middle attacks

Yeah, because the black hats are just queuing up to go to the massive effort of sniffing passwords or staging man-in-the-middle attacks on obscure web forums, whereas the much cheaper technique of phishing (which is neither sniffing nor man-in-the-middle, and won't be stopped by simply using SSL) is exceedingly rare.

Oh, wait...

Re:SSL is trying to do too much.

[itsdapead]

Then SSL should just go away. For practical purposes the lock icon means someone you don't know anything about has been paid to vouch for this other person.

Yup - that's about it. You trust the browser authors to only add reputable CAs to the trusted list, and to remove any that go bad.

Any better ideas?

Remember, encryption may let someone claiming to be "Alice" talk securely to someone claiming to be "Bob" but, unfortunately, it does nothing to initially establish that "Alice" and "Bob" are who they claim to be - that part is always going to rely on a trusted third party.

Re:SSL is trying to do too much.

[sjames]

I would put a bit more trust in DNSSEC with signatures provided by the DNS server. While BofA (for example) might not notice that some podunk CA has issued a cert to a phisher in the Ukrane, they likely will notice if their domain gets hijacked. If someone cache poisons a local DNS server, the keys won't verify and I know something is wrong.

The big problem here is that ANY of the various 3rd parties might wrongly issue a cert in addition to the legitimate one and the owner of the domain has no way of knowing that.

Server keys similar to ssh are helpful as well. Was this cert the same one that the server presented last time? If so, no need to bother . about it, we already validated it, but it wouldn't hurt to check the SOA DNS to make sure it wasn't revoked. If not, then follow the entire chain from . on down to validate the new key.

Expiry should be mitigated by signing a new key with the old one before it expires. If that doesn't happen, again, just follow the chain starting at .

Re:SSL is trying to do too much.

[Sloppy]

What use is encryption if you can't guarantee that there's not a man in the middle?

To totally kick the ass of all passive snoops, and force people who still really want to spy on you, to actually take the risk of active MitM.

This is why self-signed certs are a bad idea. That is, unless you want your users calling you up to manually verify your key.

That's the best part of self-signed certs: The attackers does not know whether or not people have done that.

You switch from plaintext to self-signed certs, and Eve says "shit, I can't spy on the cheap anymore," pays a couple thousand dollars, in both hardware and bribes, to get a fast computer in series on the wire somewhere, where it can do MitM. Eve snickers, "ha ha, self-signed cert. I can totally MitM these ignoramuses!" and then she does it. Little does she know, someone -- it just has to be one of your thousand users -- actually called and checked, and that user sees that the key Eve is giving people, ain't yours. You and that guy talk about it out-of-band on the phone, you investigate, and Eve ends up on the front page news. Nailed the bitch!

You see, self-signed doesn't mean unauthenticated. It means probably unauthenticated. You can get away with in on a small scale, but your grand panoptical plan of a surveillance society, isn't going to get far. For the surveillance society, you need people to stick to plaintext.

Re:SSL is trying to do too much.

[DavidTC]

It runs, it just doesn't boot by itself. You have to push stone 23 half an inch to the left, and hold it during startup, until the system clears and you can see the moon. (Half an inch doesn't sound like much, but yes, it is.) Sometimes you have to push 22 the other direction, too, depending on how cold it is.

And then you have to jiggle the Heelstone a few times if something gets stuck. Usually, like I said, it's stuck on the stupid obsolete bluestones, half of which are frickin missing so the entire subsystem doesn't even work. Yes, that saved some money when originally built, but sometimes you just have to throw away your first attempt.

Also you can only boot it when the moon is waxing. If it's waning, all results are misaligned by about 2 degrees due to the idiotic northern Aubrey holes being slanted. (That's what the problem is assumed to be.) I don't know whose idea those were, either.

They just leave it running most of the time.

Re:SSL is trying to do too much.

[DavidTC]

A zip fastener and a cheap padlock is enough to make it clear that your tent isn't public. Anything more is a waste of effort - and may just draw attention to your tent.

So. Why. The. Fuck. Can't. We. Do. That?

Are you having some sort of mental issue or something? We want a damn door on the tent. We don't care if it's metaphorically steel or fabric.

Right now, there isn't even, metaphorically, a tent. Everything's just out in the fucking open air, where anyone can walk up and take it.

It is not a valid complaint that part of the security system is much stronger than another part, when all parts are stronger than damn plaintext.

So what is stopping you? People who "know what they are asking for" will understand what the warnings in Firefox are all about and click through them in 10 seconds the first time they visit the site. If someone is put off by the warnings then they clearly don't "know what they are asking for".

They were asking for a web page. We, the creators of the page, wanted to give it to them with a small amount of cheap security.

Yeah, because the black hats are just queuing up to go to the massive effort of sniffing passwords or staging man-in-the-middle attacks on obscure web forums, whereas the much cheaper technique of phishing (which is neither sniffing nor man-in-the-middle, and won't be stopped by simply using SSL) is exceedingly rare.

I have no idea why you're bitching about how pointless SSL is. No one was talking about that.

But, yes, people do sniff passwords and attack people that way. Google 'wifi scam airport'. (And notice this is actually a MitM attack. You can, of course, sniff any wifi connection anyway.)

Oh, look, someone on their laptop just logged into that forum they visit every day. Oh, look, someone just stole their login id and is going to use it to post spam.

Oh, look, they just sent their hotmail password, too. I wonder if any of those are their bank's password.

Good thing we didn't let them use that insecure SSL cert to log into those sites. You know, to visit a site they visit all the time, and thus it could have compared to an existing cert.

That would just be a horrible idea, to transparently encrypt all traffic that's moderately sensitive. The people who think that's a good idea are probably the same people who store expensive items inside their house, when everyone knows people can break through windows.

People should be required to either store their stuff in impregnable vaults, or leaving it lying around on their lawn. Letting people keep stuff behind a standard door just gives them a false sense of security and we should loudly repeatedly war people whenever they attempt to set something of theirs down inside any sort of structure instead of outside.

Re:SSL is trying to do too much.

[argent]

They just leave it running most of the time.

These britons are crazy.

Re:SSL is trying to do too much.

[itsdapead]

Are you having some sort of mental issue or something?

No - you seem to be in denial of one basic fact: there is nothing stopping you doing exactly what you want to do! Go ahead, use a self-signed certificate - just don't complain when the user's browser quite rightly warns them of the limitations of using encryption without identity checking.

And yes, certificates are a million miles from perfect. Unfortunately, while you can devise arbitrarily secure encryption schemes, they all start with the axiom that "Alice" really is Alice and "Bob" really is Bob: verifying identity is always going to rely on some sort of chain of trust. Meanwhile, if its a pain in the neck for small forums to buy certificates, its also a pain in the neck for phishers.

Letting people keep stuff behind a standard door just gives them a false sense of security and we should loudly repeatedly war people whenever they attempt to set something of theirs down inside any sort of structure instead of outside.

Actually, yes. A bit like hotels warn you not to keep valuables in your room, despite the fact there is a lock on the door. With the added factor that most users suffer catastrophic common sense failure as soon as they come within 10' of a computer screen.

(Oh, and most browsers warn you before you send data in the clear as well - until you disable that warning).

Re:SSL is trying to do too much.

[itsdapead]

What do you mean by "fairly recent"? I recall it being just one click on the padlock in Opera 5.12 ~ 2001, and being able to find it somewhat easily in Netscape 4 ~ 1999.

It was usually a couple of clicks to get to the name of the certificate holder. That's 2 clicks too many to get to something which people should really check every time they visit a site. It was Firefox 3 that put the info right there on the address bar.

...and with EV perhaps who runs the site, but nothing about the security or trustworthiness of the site or company.

...but I don't think that problem has a technological solution - it always comes down to some sort of trusted third party. The best technology can do is to make it inconvenient for fraudsters to masquerade as a reputable site. Anything which adds complications, expense or leaves a paper trail (e.g. having to provide a letterhead and a postal address to a CA) is a deterrent against "fly-by-night" scams - even if it isn't a cure. Of course, all the scammers really have to do is send out an email asying "please reply with your username and password".

Long Term Con man (web version of Madoff?) could certainly get certified all the way to EV and still plan to sell off your CC# in, say, a year.

That is a flaw with the credit card system, not the web: if the banks got their fingers out then it would be SOP to generate one-time or restricted credit CC numbers for all web transactions. That way, even sending your CC number in the clear would be safer than handing your card over in a shop.

Re:SSL is trying to do too much.

[Anonymous Coward]

No - you seem to be in denial of one basic fact: there is nothing stopping you doing exactly what you want to do! Go ahead, use a self-signed certificate - just don't complain when the user's browser quite rightly warns them of the limitations of using encryption without identity checking.

And that's the problem *you* seem to be in denial about. We get this huge warning: "Warning. You are attempting to put you old underpants inside a tent. A tent is not secure. Better leave them out in the middle of the field", when all we want is to prevent them from getting wet.

Re:SSL is trying to do too much.

[DavidTC]

I think you said that better than I ever could.

All the people opposed to having two levels of SSL security, one where you pay for a cert, and another where you just make one and use it, seem incapable of realizing that we'd don't want to use unsigned certs to protect CC transactions and whatnot.

And we're not talking about some sort of transparent failure. If someone uses some sort of existing cert and it expires or is for a different domain, it should, by God, throw up said huge warnings.

But there should be some way to generate an SSL cert that is marked as 'Just encryption, not authentication', and doesn't present itself as a locked icon symbol or whatever, and doesn't throw up absurd warnings. It just silently encrypts the fucking connection. So you can't sniff people's damn google searches or their web mail password or whatever.

In fact, as I'm hoping for a new standard anyway, let's just require it to use SNI on a different port, removing all confusion if the connection is secure. Call it httpe or something.

Re:SSL is trying to do too much.

[speedc0re]

Just so there is no confusion: In 2012 the North and South poles of the Earth will be swapped. In 2038 all the computers will think its 01/01/1970 again. Probably the world won't end until sometime after that unless there is a nuclear war or huge asteroid.

You didn't get it right either... try "HTTPS"

[WD]

The correct term is "HTTPS". HTTPS, which can use various versions of SSL or TLS, is still mostly understood. Even by the pros.

Re:You didn't get it right either... try "HTTPS"

[Anonymous Coward]

That's like saying the correct term is "car" when you're talking about a wheel.

You actually mean "Public Key Cryptography" and how to apply it.

Re:You didn't get it right either... try "HTTPS"

[Anonymous Coward]

I fall in the line of not having a clue what TLS is, or what it means.

Although i rarely wander out of the same usual sites these days.
I blindingly trust the usual huge sites (google, paypal, etc), but anything small and I'm like "oh hell no, let's just find out some stuff about you, you just gained a stalker!"

Re:You didn't get it right either... try "HTTPS"

[Anonymous Coward]

That's like saying the correct term is "wheel" when you're talking about a cylinder.

You actually mean "Math" and how to apply it.

Re:You didn't get it right either... try "HTTPS"

[Chrisq]

I fall in the line of not having a clue what TLS is, or what it means.

Although i rarely wander out of the same usual sites these days.

Don't worry about it Grandpa (following story's ageist agenda)

Re:You didn't get it right either... try "HTTPS"

[tokul]

POPS, IMAPS, SMTP over SSL, FTP over SSL.

Re:You didn't get it right either... try "HTTPS"

[sexconker]

That's like saying the correct term is "cylinder" when you're actually talking about a thing.

You actually mean the Universe (capital U), and how it applies itself.

(XKCD comic is wrong - math is a (counting) model of the physical (quantum) Universe.)

Re:You didn't get it right either... try "HTTPS"

[Anonymous Coward]

(XKCD comic is wrong - math is a (counting) model of the physical (quantum) Universe.)

Nope. Math is much more general than physics. Probably the best way to illustrate that is that in math, you can say if something is true or false, as you can absolutely and definitely proof it. In physics, you can NEVER say something is true, as it's only a model. (Cue the Monty Python quotes.) You can certainly say that something is false because it's easily falsified, e.g. Newtonian physics applied to the universe at large.

As usual, no one wants to be the leader.

[Futurepower(R)]

This article would be funny if it weren't so sad. What's the reason computer professionals don't understand SSL? Bad documentation. And neither the Slashdot summary or the article to which Slashdot links is willing to link to documentation.

The Wikipedia explanation of SSL helps. This explanation helps, also.

The Do It Yourself SSL Guide is useful.

Re:As usual, no one wants to be the leader.

[upuv]

I blame JAVA.

Java dev to any other IT dude: "I don't need to know about that the jvm abstracts that away for me. So buzz off and let me do real IT work. "

Just kidding :) Well actually I'm not. In general Java devs know ZIP about anything out side of a JAR file.

Re:As usual, no one wants to be the leader.

[Chrisq]

In general Java devs know ZIP about anything out side of a JAR file.

They may not even know that JAR files are ZIP format.

Re:As usual, no one wants to be the leader.

[kimvette]

Years ago when I first set up SSL it was a pain in the neck. Installing third-party certs was a painful process with little, outdated docs on how to do it with Apache, but what was worse was I also had to set up self-signed certificates and that was an even more painful process because the documentation was so sparse there might not have been any. webmin didn't help much either, so I had to do a lot of searching and some reading of code in the supporting projects to figure it all out. Once I knew what needed to be in place it was fairly straightforward but getting their was a major pain in the neck. It's not so much a matter of a complicated process, but what directives do I need to add to .conf files?

I wrote a howto for myself so the process could be repeated. I should have completed the howto for public consumption but being self employed there is never any time for that kind of thing.

At this point the docs should be much better - at least I hope they are.

Windows was a little easier but not much. Sure, it's point-and-click, but when you have to click around in 38 different dialog boxes (Yes yes I know, 38 is an exaggeration), you'll be wish you could just do it all from the command line. The process on Windows is easily as complicated as on Linux, in fact slightly more so once you understand the steps. Fortunately Microsoft released a tool for making creation/installation of SSL certs a much easier process. Check out these sites:

http://www.visualwin.com/SelfSSL/
http://www.somacon.com/p42.php
http://www.microsoft.com/downloads/details.aspx?FamilyID=80a1b6e6-829e-49b7-8c02-333d9c148e69&DisplayLang=en

In later versions of Windows they have made it a heck of a lot easier. In 2008 it's a breeze - you don't even need to download any resource kit tools to make it easy.

Re:As usual, no one wants to be the leader.

[JSlope]

I think SSL has a too complicated installation procedure on most platforms.

Re:As usual, no one wants to be the leader.

[RobDude]

I've seen the same sort of thinking amongst .NET developers.

The problem in these high level languages with huge libraries of really cool stuff available is that just learning what the libraries can do is a huge undertaking. Mastering the 'how' and really understanding it is an order of magnitude harder.

And, often times, you see it advocated to be ignorant of the 'how'. Good Object Orientated thinking is all about 'separation of concerns' - so I shouldn't be concerned about how WPF will take my form with a button and get the GPU to render it. Or how they'll get Remote Desktop to offload that processing to the client machine.....I just know, and care, that if I make a Window, the underlying everything will take care of itself.

On the plus side - you really do get an amazing amount of code done. Things you'd never be able to do (given real-world time constraints) on your own. The down side, is that you really don't know wtf is going on.

But, I think people have been saying this since people started using C and not ASM.

Re:As usual, no one wants to be the leader.

[Slashdot Parent]

In general Java devs know ZIP about anything out side of a JAR file.

Or a WAR file or an EAR file or a...

Re:As usual, no one wants to be the leader.

[onemorechip]

And neither the Slashdot summary or the article to which Slashdot links is willing to link to documentation.

Please stop anthropomorphizing the article and summary. They hate that!

Re:As usual, no one wants to be the leader.

[CarpetShark]

Please stop anthropomorphizing the article and summary.

They're a couple now? That's so cute. They're really made for each other.

Re:As usual, no one wants to be the leader.

[BikeHelmet]

They're not strictly zip. For one thing, everything has to be put in in a specific order, and whatever compression used is notoriously slow for seeking/fetching classes.

But since zip can have a dozen different compression schemes, I suppose you are correct.

Re:As usual, no one wants to be the leader.

[BikeHelmet]

Technically most C devs are the same way. If you comment that they should learn assembly, the majority will tell you that they don't want to learn it. "C is efficient enough." The quality of code emerging from a C dev that knows asm is quite different from one that doesn't, and has no idea what the hardware is actually doing.

I've written it off to the flood of single-language developers. Oh sure, they may know the syntax of more than one language - but they treat every language the same as whatever language they learned first.

Re:As usual, no one wants to be the leader.

[Cyclops]

They are zip files. I've used several times plain ZIP to change jar files. No problem at all. Since you said that, are you a Java developer? Seems so...

Of course IT proffessionals don't get it

[Malc]

Have you ever tried teaching yourself the basics behind SSL, such as PKI and X.509 certificates? In an industry full of jargon and technalese, the security people are some of the worst for explaining things. The documentation out there is poor and cryptic. Ever wonder why encrypted or signed email never took off? Look no further than GnuPG or the Enigmail plug-in for Mozilla. Try finding out what DER encoding is, or ASC.1, or what PKCS#7 means. None of it's straight-forward, even for technical people.

Re:Of course IT proffessionals don't get it

[upuv]

ASN.1

You almost had it :)

Re:Of course IT proffessionals don't get it

[Necroman]

I'd like to second that motion. The same thing goes for encryption used for wireless routers. When a non-tech friend is setting up a new wireless router and is setting up the encryption part, they just see a list of 3 and 4 letter words they don't understand. And the only reason I know which is the best to pick is reading around the web to know which are easy to crack.

Re:Of course IT proffessionals don't get it

[KnownIssues]

But what could be more clear than Alice and Bob?

Re:Of course IT proffessionals don't get it

[Anonymous Coward]

That's the NSA community operation doing their best to participate in open cryptosystem development. By adding as many cryptic features as possible they make sure that take-up of encryption technology remains minimal.

Re:Of course IT proffessionals don't get it

[Z8]

You may be right about SSL, but I think you're incorrect about encrypted Email. PGP was a very easy-to-use program for its time, complete with plenty of documentation that (as a previous poster mentioned) posed the problems and solutions in clear, Alice-and-Bob terms.

Furthermore, the PGP/MIME standard was very clear, and had a clear RFC. I implemented this RFC myself for two different email systems over 10 years ago. Nevertheless, PGP/MIME didn't catch on, and I myself rarely use it now.

Why? Part of it was FUD with S/MIME, but mostly it's just critical mass I think—anything that takes more than a few minutes total won't be done by most people unless it averts an immanent catastrophe (and sometimes not even then).

Re:Of course IT proffessionals don't get it

[DavidTC]

No kidding. How hard would it be for the router to actually vaguely explain what OSes can be expected to understand each type of encryption, and which you should use unless you have Specific Older Device or have discovered that some device you have doesn't work. What, do they have 32k of firmware room and no space for explanations?

Of course, most router control panels appear designed by idiots anyway.

Re:Of course IT proffessionals don't get it

[nametaken]

The documentation out there is poor and cryptic.

I see what you did there.

Re:Of course IT proffessionals don't get it

[Anonymous Coward]

What? Job security through obscurity? I'm shocked! Shocked!

Re:Of course IT proffessionals don't get it

[WuphonsReach]

That's because while encryption is simple, key management is horribly complex.

(And a lot of those standards were developed back when crypto was considered a munition, which causes a lot of pain and roadblocks to easy interoperability.)

Re:Of course IT proffessionals don't get it

[sjames]

Not to mention the process of using the SSL utilities (by rote) to produce certs. It might as well read as do:

blookgle -blargle -blab -flibbertijibbit -flooble -flop -glarg cert.hjas

Then you just flooble the flibbit and boogie the blarg and your done! What's a blarg? AH! you're a clueless newbie arent you. <speech tone=condescending"> a blarg is a blibble with a figgit that was flujubinated with a kleg.</speech>

What ever happened to gen-key -name "me" me.cert; sign-key me.cert -with me.cert (or something comprehensible like that)?

That would be why people who regularly deal with ssh keys can't manage to deal with SSL keys.

Re:Of course IT proffessionals don't get it

[slashqwerty]

ASN.1

And speaking of ASN.1, does anybody understand it?

OpenSSL: [STILL INCOMPLETE]

[Futurepower(R)]

The OpenSSL web site lists "[STILL INCOMPLETE]" for each of its manuals.

Re:OpenSSL: [STILL INCOMPLETE]

[MrMr]

Why do you want a manual?
Just modify the source until it does what you expected.

Re:OpenSSL: [STILL INCOMPLETE]

[colourmyeyes]

[Parent modded "Funny" for lack of a "Sad" mod]

Re:OpenSSL: [STILL INCOMPLETE]

[Ke3g]

Or just read the documentation?

it's the browser implementation

[circletimessquare]

as the guy said in the article, it should kick you from a session at expired certs, not allow click through options

if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

that should really be the only option available to anyone. its psychological: take this seriously, sorry for the inconvenience. otherwise, lazy admins will let their expired/ malformed certs hang out there for a lot longer (which i've seen even on a credit card site: capital one), because users just easily circumvent the roadblock. they'll definitely notice if no users can get through, and the angry emails pile in their inbox

i only allow https admin connections to my router, which of course means my browser screams about being unable to verify any certs... since i'm on a subnet. and i bet there are many other valid situations where expired/ unverified certs still represent a valid connection

however, add up all the valid situations where you want to continue an uncertified https connection, and you are left with nothing but a hill of beans in comparison to the mch more massive problem of psychologically just not taking https seriously enough

now you just have to convince the 3/4/5 major browser flavors to implement this new status quo

maybe the certificate authority should simply kick insecure browsers regardless (is that passed to the certificate authority during verification of cert?). that would get browser coders and vendors to notice. of course, what the browser report themselves can be hacked/ finessed, but if that's done maliciously, you're box is already owned, and its already game over regardless through a lot more powerful avenues

Re:it's the browser implementation

[Culture20]

Because people are going to ask:
Q: And what about self-signed where you can verify the cert's sig? Some applications only require half-arsed.
A: There obviously needs to be a workaround; either manual typing or pre-load it or your corporate CA's cert into company intranet browsers. Do something that _forces_ comparison of the sigs, not click click click (click click click click click click for FF3).

Re:it's the browser implementation

[tepples]

it should kick you from a session at expired certs, not allow click through options

Given the following choices for a site that doesn't take credit cards:

• A. Use a self-signed certificate for the password form
• B. Do not use encryption on the password form
• C. Take the site off the Web entirely

Which would you choose?

Re:it's the browser implementation

[Mr. Slippery]

if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

You can do that just as soon as CACert's free certificates are recognized by the major browsers by default.

Re:it's the browser implementation

[Bigbutt]

Java 1.6 Upgrade 15 through 18 does this. If you try to access a site with an invalid or expired cert, it just exits. Unfortunately it doesn't say why, it just exits so there are lots of lookups for WTF Java is doing, is my machine broken, or what? And you can't disable 15 and go back to 14 or earlier as it still bails. You have to uninstall 15 to gain access.

Of course the real problem is that we never updated the certs on our Dell Remote Access Consoles since it worked anyway. Since all the systems are inside the firewall and not accessible to the 'net, no one assigned any priority to taking care of replacing the Dell cert with a company one.

I'll have to see what the process is for getting a cert for the boxes, even if it's self signed.

[John]

Re:it's the browser implementation

[Lord Lode]

I think there are two separate things:
-having my password be encrypted on the LAN cables
-having a site being signed by a third party

For some reason, the first thing can't be done independently from the second. If I understood correctly, at least. Anyway, is there a possibility for websites to give you a secure line to them, without depending on a third party? I don't care about signing, but I care about sniffing on LAN cables.

Re:it's the browser implementation

[rgviza]

>as the guy said in the article, it should kick you from a session at expired certs, not allow click through options
>if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

As long as that's a default setting you can override... Otherwise I have to have a valid paid cert on every one of my dev servers? F*** THAT.

Re:it's the browser implementation

[kimvette]

Uh, no. Why should small businesses be forced to pay a certificate authority for certificates for appliances (spam filters, etc.), terminal services web pages, external access to webmail and intranet pages over SSL when a self-signed cert (even an expired one) will do? This is a user education issue, not a "let's get rid of it for everyone." It is for corporate use that you can optionally install self-signed certs into any of the mainstream browsers. There is a legitimate need for such things, and forcing everyone to pay for signed certs is a colossal waste of money.

Where it comes to e-commerce though, I agree with you, because however slight the protection may be, there is a very slight assurance that yes, https://www.foo.com/ is actually run by foocorp, not $phisher. Now, the verification process for most certificate resellers is between minimal and nonexistent, but most phishers won't even bother with SSL to begin with.

But let me hazard a guess here: You work for a certificate authority or reseller, right?

Re:it's the browser implementation

[Slashdot Parent]

as the guy said in the article, it should kick you from a session at expired certs, not allow click through options

if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

Would you actually use a browser that misbehaved in this fashion?

I certainly would not.

Re:it's the browser implementation

[Culture20]

Anyway, is there a possibility for websites to give you a secure line to them, without depending on a third party?

If you take your computer to their server farm and plug directly into their webserver. Or maybe if they pay Mozilla, Microsoft, et al to put their self-signed certs in the browsers. The networks in between will always be an untrusted third party.

Re:it's the browser implementation

[Culture20]

Given the following choices for a site that doesn't take credit cards:

• A. Use a self-signed certificate for the password form
• B. Do not use encryption on the password form
• C. Take the site off the Web entirely

Which would you choose?

I vote "C". "A" gives a false sense of security unless you can contact the site owner off channel and verify the cert manually. "B" is beyond worthless. Password transactions should be encrypted and only sent to verifiable recipients.

Re:it's the browser implementation

[PybusJ]

D. Create your own CA cert

Why not create you own signing certificate, and use this to sign your key for https://my-hobby-site.example.org/. You can then install the signing cert in your browser and be happy and secure.

But what about when you want to log in from an internet cafe half-way across the world? Why, just publish your CA cert at http://my-toy-site.example.net/cacert.crt and link from your home page; you'll be prompted to install it in your browsers trusted key-ring. (Of course someone could have MITM'd your certificate install, but then that's the risk you've chosen to take by going for a self-signed cert)

Now you can have a secure connection without paying a so-called "Trusted Third Party" for the privilege, and without requiring the browser to support the easy use of self-signed certs (which we know causes damage to many people's ability to use https web-sites safely).

Personally, I hope that, in the medium term, widespread key distribution based on DNS-SEC will side step this whole issue.

Re:it's the browser implementation

[tepples]

I vote "C".

Would you vote C for shut down the site even if it were your own site? For people who do not want to take down their sites, how would you recommend that they justify to their superiors the doubling in web hosting prices that come with SSL?

Re:it's the browser implementation

[Kalriath]

Why? StartSSL's free certificates are recognised by the major browsers by default. Hell, you can even get $40 code signing certificates from them.

Re:it's the browser implementation

[Mr. Slippery]

StartSSL's free certificates are recognised by the major browsers by default.

Not by IE, at least IE 7. And they are only issued to individuals, not to organizations or companies. And they are only valid for 30 days. Useless.

Re:it's the browser implementation

[Engeekneer]

as the guy said in the article, it should kick you from a session at expired certs, not allow click through options

if the cert is expired/ unverifiable, the browser should simply kick the session, end of story

that should really be the only option available to anyone. its psychological: take this seriously, sorry for the inconvenience. otherwise, lazy admins will let their expired/ malformed certs hang out there for a lot longer (which i've seen even on a credit card site: capital one), because users just easily circumvent the roadblock. they'll definitely notice if no users can get through, and the angry emails pile in their inbox

I partly agree with you. The question is, would it help much? I could easily register verytrustedbusiness.com for stealing credit cards, and get a valid certificate for it. Now when a user surfs there he/she sees "ooh! A trusted web site!", which is only partly true. The certificate only confirms (well, should) that the owner of the domain is the one running the server. It doesn't mean the site should be trusted. Of course it would make it easier to track the culprits (me in this case), but that's a small comfort for the already cheated ones.

Re:it's the browser implementation

[Culture20]

Would you vote C for shut down the site even if it were your own site?

If it was my own site (and I was the only one accessing it), I could verify the cert manually, and I'd go my merry way. If it was my own site, and other people were expected to authenticate to it, or were supposed to trust the cert to trust that the information on the site came from me, I'd sure as hell vote for C. I'd rather not contribute to the misconception that self-signed certs are completely safe and should just be accepted, and since only my friends would be calling me to verify the cert (and even they would get annoying about it), then I'd rather have no https. With no https, there's no chance I'd have a login field.

For people who do not want to take down their sites, how would you recommend that they justify to their superiors the doubling in web hosting prices that come with SSL?

If IE and firefox started "shutting down" the sites by following the OP's example, then they'd justify it by saying "Double cost or no site. Have site or no business/org/forum. Ergo, Double cost or no business/org/forum."

Re:it's the browser implementation

[tepples]

Double cost or no business/org/forum.

Then why do web hosting companies even offer plans with PHP and no HTTPS?

Re:it's the browser implementation

[Culture20]

Then why do web hosting companies even offer plans with PHP and no HTTPS?

Because not everyone uses PHP for content that needs to be authenticated.

Re:it's the browser implementation

[tepples]

If you do not need to authenticate users, then why do you need your site to be dynamic in the first place? If users aren't able to log in and change things, the site could run as just static HTML, possibly with server-side includes.

Re:it's the browser implementation

[cbiltcliffe]

No you don't.

Just set up your own CA, and generate your own certs for your servers. (Documentation abounds on the net about how to do this with Apache.)

Then, import your CA cert into your browser's CA list.

All of a sudden, all your servers are showing up as properly signed and encrypted, with a valid cert.

Seriously, people....this shit isn't that difficult.

Re:it's the browser implementation

[init100]

maybe the certificate authority should simply kick insecure browsers regardless (is that passed to the certificate authority during verification of cert?)

Which clearly shows that you have no idea what you are talking about. The certificate authority isn't contacted when a browser tries to verify a certificate. Instead, it does this by looking through its local store of CA certificates, picking the public key of the CA that signed the certificate in question. The public key is then used to "decrypt" the signature embedded in the certificate being verified, which yields a cryptographic hash. This hash is compared with the hash generated by applying the same cryptographic hash function on the certificate in question. If they are the same, the certificate is considered validated.

In case of a certificate chain involving intermediate authorities, it's the site owner's task to supply all intermediate CA certificates between the server certificate and a well-known root CA. The browser verifies each certificate against the signing certificate one level up the chain, until the entire chain is validated.

But nowhere in this process is any CA contacted. And why should they decide what browser is secure or not? I wouldn't like them to decide that only Internet Explorer 6 is an acceptable browser to use.

Re:it's the browser implementation

[Culture20]

I could be running the next whatsmyipaddress.com or something similar (don't laugh, but I know a "sysadmin" for whom such a site is a valued diagnostic tool; when I talked him through typing ipconfig on the command line, he typed "ip config"), or a random character generator, or I might want a 1994 era hit-counter on the bottom of my page. I can think of a lot of things that are dynamic that don't require authenticated users.

Re:it's the browser implementation

[tepples]

I can think of a lot of things that are dynamic that don't require authenticated users.

But how are applications that need CGI or PHP but no authentication common enough to devote a segment of the web hosting market to them?

Re:it's the browser implementation

[Kalriath]

Obviously you've neither looked at IE nor StartSSL in a year. StartSSL issues free certificates to individuals, recognised by all major browsers, for an entire year (at least, I'm pretty sure that's what "1 year validity" means). For companies, they charge $40 for a class 2 certificate (what Verisign charges $800 and Thawte charges $400 for) which is even valid for object signing (what Verisign charges an extra $400 for).

Re:it's the browser implementation

[Anonymous Coward]

Wrong. Except in terms of server load, encrypted-but-unauthenticated communication is still better than unencrypted communication. Encryption and authentication should be decoupled within browsers. If a web site wishes to encrypt without identifying itself, there's no reason their users should be given security warnings that carry the impression that the site is up to no good. The trick would be that the browser doesn't light up any "secure site" indicators until BOTH encryption AND authentication are in place.

wat

[Lord Ender]

most of them are aware that SSL traffic can be sniffed without their knowledge.

You're doing it wrong.

Whoever wrote this article does not know what he's talking about.

Re:wat

[jafiwam]

Well, it IS technically true it can be sniffed. It's just packets after all.

What the packets contain, on the other hand, won't be available to the person who now has them without a lengthy and large amount of computing power applied to it, plus a great deal of luck.

Re:wat

[Anonymous Coward]

http://www.thoughtcrime.org/software/sslstrip/

MITM attack on browser downloads

[aembleton]

With the exception of pre-installed machines, we all have to download our web browsers. What would stop someone carrying out a man in the middle attack on a web browser or distribution download that provided a different Firefox that contains different CA keys. These CA keys could be designed to work the same with https websites, but would allow a man in the middle to also read off the information being transmitted.

Admittedly this would be very hard to do, but theoretically possible and with the resources of a nation state this may have already been done. As most machines are now built in the far east, what would stop the IE that ships with your computer from also having altered CA keys?

Would it even be possible to detect this? You could use MD5 checksums on your downloads, but most of the websites that show an MD5 are unsecure, so they could easily be showing a manipulated version of the checksum.

This strikes me as one of the biggest flaws of our reliance on SSL v2, v3, whatever.

Please tell me that this isn't possible.

Re:MITM attack on browser downloads

[cenc]

Yes, and how do know that the browser that you originally installed with your operating system was not forged? How do you know your OS or your bios can be trusted? Hell, for that matter how do you know you can be trusted?

Ooooooohhh the horror!!!!

Not to be a troll, but you are really pushing that off in to fantasy land. My point it that security vulnerabilities based on 'just so' hypotheticals, are less likly to be a real world threat. Possible yes. Likely no.

Re:MITM attack on browser downloads

[aembleton]

If you wanted to watch online banking transactions to a major bank like HSBC would this not be a way to do it?S ure, it would be difficult and would take a while, but you would gather huge amounts of information that is potentially worth millions.

The only difference between this and a completely unsecure connection is that it would take more effort and organisation and it would be limited to those browsers that you've set up a MITM attack for and have been downloaded. You could set up a MITM attack before a new release of a browser such as Firefox 4.0 and use a fake Verisign certificate.

This would only help you with listening to Firefox 4.0 connecting to https signed by Verisign; but this would be a way to gain access to bank accounts.

Re:MITM attack on browser downloads

[Anonymous Coward]

You could use MD5 checksums on your downloads...

Which is a dead avenue anyways -- even in Ubuntu you can't just right-click for 'show MD5 checksum'. Most users will never use it.

Re:MITM attack on browser downloads

[Anonymous Coward]

You can more or less verify that the software (browser, OS, etc) you just downloaded is the right one if the file is cryptographically signed by a key you know and trust to belong to the correct author.

Of course in practice you can't really be sure because:
  - is the public key you have the one that matches the real author's signing key? How do you know? Did you meet him/her in person and exchange keys, or did someone you trust do that and give them to you? Or, did you download the public key from some website and trust that it's "probably OK"?
  - did you audit the source code for your cryptographic program (GPG, or whatever) and compile it yourself, to know that it's not compromised?
  - did you audit the code for the OS you're running it on?
  - did you audit the source code for the compiler you used to build them both?

So all security online boils down to being "reasonably" confident that you're not being attacked. As to what's reasonable - that's up to each individual to decide, although if you're using the computer for nuclear weapons design for the government your bar for "reasonable" might be a bit higher than for someone to whom the computer is just a toy.

Re:MITM attack on browser downloads

[aembleton]

Agreed. However, with more and more transactions moving online; surely the incentive is growing everyday for this kind of attack to occur.

Maybe for large scale theft, or maybe to have access to bank account that can be used for money laundering.

Re:MITM attack on browser downloads

[rgviza]

It's definitely possible. You can add CA's willy nilly to any install. This feature is present to allow companies to have self signed certificates used by their employees. You just need to have a server online that it contacts for the CA verification. You can check the list yourself and compare it to what it should be at:

http://www.microsoft.com/security/

It will take some digging but it's in there. What's scary is that a hostile pc maker could replace the stock IE with their own that has hardcoded CA's which aren't visible by checking the list in IE... This would be tough to do though with the regular updates that MS does, unless they coded up a rootkit too, which hid the actual executibles from the update process and swapped the malware back in after the update.

Unlikely, but possible... The only way to be sure is to build your own PC and install "Genuine" media, which could be tampered with too, since it's packaged and printed overseas. Someone at Microsoft would catch on to that though, I hope.

Re:MITM attack on browser downloads

[Nerdfest]

That would be an excellent feature. Perhaps also an option to show it in the list of downloaded files automatically would be good.

Re:MITM attack on browser downloads

[ObsessiveMathsFreak]

What would stop someone carrying out a man in the middle attack on a web browser or distribution download that provided a different Firefox that contains different CA keys.

You have touched upon what for mean is the biggest argument against disallowing or downgrading self signed certs.

If someone has the resources to implement a man in the middle attack, what's to stop them doing so with your connection to the certification authority?

Personally, I believe that man in the middle attacks are little more than thought experiments, elaborate "what-if" scenarios, essentially no less fantastic than your nation state hijack theory. Has there ever been a single concrete instance of a man in the middle attack on a general purpose website, targeting the wider internet population? If an attacker has the means to intercept such traffic from general users, then what good would SSL be anyway?

The man, or Myth in the Middle, is not something most web users or browsers need to concern themselves with by default. By all means, add security exceptions for important or sensitive sites at the users request. But please, stop telling us that self signed certificates are somehow worse than no certificate at all.

Re:MITM attack on browser downloads

[Anonymous Coward]

Not to be a troll, but you are really pushing that off in to fantasy land. My point it that security vulnerabilities based on 'just so' hypotheticals, are less likly to be a real world threat. Possible yes. Likely no.

The problem you point out is exactly why security researchers divide attacks into two groups. Targeted, and not targeted.

Non targeted attacks are like the script kiddies or their virus/trojan software scanning for certain open ports or version banners to spread. Network sniffers placed at the ISP level by hackers,govt, or the isp. that type of stuff.

We all know its out there, and it aims for the lowest hanging fruit. With some basic protection, and common sense, it should be fairly rare to have to deal with those attacks.

Targeted attacks on the other hand are a different beast.
There is no such thing as Theoretical or not, only if it worked or did not work.
A huge chunk of what you would call "Theoretical, and not useful" while true for massive generic attacks, is a very dangerous falsehood when dealing with targeted attacks.

When a hacker wants in YOUR stuff, odds are you are already screwed.
All attacks, including SSL man in the middle, and including modifying the IE/firefox stream in transit over the internet for the browser download, done at the ISP or above level, is 100% possible and have been done before with targeted attacks.

Injecting a CA cert with your own credentials into a download can be done, and has been done.
It is just that the work involved in doing this, for each target, is massive.
If you have just one target, the days or weeks of setup time might be worth it.
When you multiply that time over more than one target however, it quickly becomes unusable.

The moral of the story is, for the large majority of attacks people have to deal with, you are correct in that the advanced theory based attacks are not an issue.
But if you are worth targeting, and some hacker has an interest in doing so, all bets are off.

Re:MITM attack on browser downloads

[mweather]

The only way to be sure is to build your own PC and install "Genuine" media, which could be tampered with too, since it's packaged and printed overseas. Someone at Microsoft would catch on to that though, I hope.

That's what signed code is for. Then all you need to trust is that the guy who signed it is trustworthy and wasn't compromised.

Re:MITM attack on browser downloads

[DavidTC]

If an attacker has the means to intercept such traffic from general users, then what good would SSL be anyway?

No shit. If someone can MitM wamu.com, or, more likely, hijack the DNS, everyone's screwed anyway.

All the attacker has to do is replicate the site without SSL. People will go there, login, whatever, and won't get SSL errors because the attacker's not using it.

Incidentally, the easiest way to stop attacks on banking website would be for banks to give out CDs that installed something like Mozilla Prism, a nice fancy branded icon that went straight to the banks web site (But not the public one.), checking that it was not only signed but signed by the right cert company and had the correct MD5 sum and everything.

It could update itself via some custom protocol...I would recommend just leaving the old SSL site intact, with the old cert, and putting a redirect on it (Along with expected MD5 and whatnot.) to a new one.

This application could also run off the CD, or install onto USB drive, for people who wanted to access their bank somewhere they couldn't install it.

If no one's ever expecting to go there in their web browser, but instead in their 'bank program' no one will fall for a MitM. And if they're given them on CDs, handed out at their bank (Big stack by the door, or the teller gives them when you sign up for online access.), they won't fall for download links.

I.e., SSL to stop MitM banking transactions is sorta solving the wrong problem. It is trivially easy to know we're actually dealing with our bank, because we have physical contact with our bank in advance of any electronic contact. They just need to give us something to help with that.

As an added bonus, their web site designers no longer need to code for 10 different browsers.

Re:MITM attack on browser downloads

[Anonymous Coward]

No, of course this is not possible to do, neither for your mistress' husband nor for the church choir you are embezzling. And we don't tap your phone. Really.

PS. Throw away the milk in the fridge before it start to smell.

Re:MITM attack on browser downloads

[cenc]

I think I was being a bit too sarcastic with my last post, and my point was lost.

Your attack assumes that you can insert a fake download and publish a fake md5sum. Which either you have access to the site that it is posted on, access to the real Firefox (or whatever browser), or the particular end user's computer / connection is already breached in some other serious fashion. Any of which I would think would be such a serious exploit to make messing around with a fake CA rather pointless. All the data your fake CA was suppose to gather, is already available by less complicated means.

Of the thousands of open source projects out there that publish free software on their sites along with the md5sum to verify it, I am not aware of any instances of anyone pulling this off. There have been a few cases of malicious code being uploaded to the servers and published, but they are caught rather quickly by the community because of the trickle down review effect.

They where however direct exploits inserted in to the code, not intercepting the download.

It is rarely the case that an md5sum is published in one and only one place (at least for big projects). I would also point out that most browsers (at least in Linux land) are distributed by the distro updates, not directly with firefox or whatever.

A bigger threat along these lines from my perspective would be the threat of a fully rogue linux distro being published. It has gotten fairly easy for people to spin their own, and there is sure a growing number of new users out there (both using and working on projects). What is to stop someone from pushing out one with malicious software in it?

Re:MITM attack on browser downloads

[Anonymous Coward]

What's to prevent them from MITM'ing the page that serves up the MD5 checksums?

Re:MITM attack on browser downloads

[the_one(2)]

There is a addon for that. (MD5 Hasher)

Re:MITM attack on browser downloads

[RzUpAnmsCwrds]

What would stop someone carrying out a man in the middle attack on a web browser or distribution download that provided a different Firefox that contains different CA keys.

On Windows, the Firefox installer is signed using Authenticode using a certificate signed by a "trusted" root CA (e.g. Verisign). When you see "Mozilla Corporation" come up as the "Verified Publisher" in the UAC dialog (in Vista or 7), that string is not simply a field in the executable, it's part of the certificate that Mozilla uses to sign Firefox installers.

Now, as to whether or not you should trust the root CAs, that's a different question. But if you can't trust the root CAs, then it doesn't really matter whether your Firefox build has a modified root CA list.

On Linux, your Firefox packages will be signed with your distro's private key(s).

Since when...

[jittles]

Since when have nerdy men ever truly understood Super Sexy Ladies anyway?

SSL has 7 times as many hits as TLS

[tepples]

Good luck. Google has 9,610,000 hits for ssl certificate and 1,350,000 hits for tls certificate.

Re:SSL has 7 times as many hits as TLS

[Anonymous Coward]

Strange how Google also has 22,800,000 for MS Certification....hmmmm

Lack of education.

[miffo.swe]

Personally i have thought about learning SSL from the ground up the "right way" countless times. The problem is finding a course thats general about implementation but dives down into the gritty details of SSL. I dont want to know howto meddle with SSL on a specifik product, i want to understand its inner workings so i can manage any implementation through good knowledge about wtf im doing.

Re:Lack of education.

[rgviza]

Or you could just install a free copy of VMWare server, a free linux distro, and install the free apache software with the free OpenSSL on it, then configure a virtual server, create a csr, process it to build the cert, install the cert and learn all about how it works using the documentation and How To's.

I'll give you a little hint though. Just remember that the certificate negotiation is done at the lower layers in the OSI model, so to have multiple certs on one server, you need to put each cert on it's own IP. It doesn't process the host request header til after the SSL connection is negotiated. Because of this you can't have a bunch of VHosts running SSL on the same IP. Only one will serve pages without a warning if you do... the exception being when all of the hosts are subdomains of the same domain, and you have a wildcard cert that's valid for all of the vhosts.

There's no better way to learn something than to do it, work through it and actually make it work ;)

Re:Lack of education.

[init100]

Because of this you can't have a bunch of VHosts running SSL on the same IP

Wrong. You can do that just fine. It does require the X509v3 extension subjectAltName to specify the list of valid host names for the certificate. That's what those multi-domain certificates that some CAs offer do. You are not alone in this misunderstanding though. The Apache developers obviously share it, since enabling name-based virtual hosts and SSL for the same virtual hosts gives a warning in the server log, although it works anyway.

You still need one IP per certificate though.

Bug 215243

[tepples]

By the way I use cacert to generate my certificates; it should be inlcuded in the default Firefox certification authorities list. I suspect there is money involved in getting into that list though.

CAcert failed a DRC audit. Bug 215243 comment 158 has the details.

Re:Bug 215243

[Hurricane78]

What does that mean? They were the only ones who hadn't enough money? I mean do you take DRC audits seriously?

Re:Bug 215243

[tepples]

What does that mean?

The auditor found some serious problems in CAcert's processes, and CAcert withdrew its request to get its root certificate into Firefox.

Blogs, forums, and wikis

[tepples]

From the article:

Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords.

A lot of non-SSL password forms are on small blogs, forums, or wikis that don't handle financial data. Might the widespread lack of SSL on password pages have something to do with the price of a certificate for each such site?

Re:Blogs, forums, and wikis

[IBBoard]

That, and the fact that the free ones you can get (e.g. startssl.com, who I use) aren't automatically accepted. Not a problem for my webmail and admin sections, which are only used by me and my family, but far more annoying if I had a wider range of users hitting "WE CAN'T VERIFY THE CERTIFICATE CHAIN!!!!!" messages when all I want to do is put HTTPS on my site.

Re:Blogs, forums, and wikis

[Kalriath]

StartSSL was included in a recent Windows Update, actually. My XP machine at work has it.

SSL is about trust.

[upuv]

SSL is all about trust in the end.

The monster problem is arrogant security people don't trust the other arrogant security people. Trust is implemented via certificates. EG I certify that this thing is what I say it is.

Problem. Who trusts the guy who gives out the certificate. Well as it turns out. Not many trust the other guys certificate. This leads to a problem. You can't build a pyramid of trust when you can't really trust the other guy.

So basically it makes it fairly impossible to create something like a local key store. I can't trust your key store because I can't trust the people that say your key store is a good one. Lets put this in terms people can understand. The government issues a locksmith with a certificate stating that this lock smith can hold copies of your home and safe keys. You can trust him because we the government trust him. Problem is no one trusts the government and no one believes that this guy actually has a real certificate. It could have been forged after all. So I'm not going to let him hold my precious keys.

So now I can't even trust my local key store. So just in case I'm going to add another level on top. I'm going to add a pass phrase. This is something I need to repeat every time I need to do something special involving security. Like say open a door. I turn the key and utter my pass phrase.

Again we got a problem. I have doubts about the pass phrase. Someone might have recorded the pass phrase and is able to play it back after they have used a dodgy copy of my key.

So in the end the trust chain is very fragile. Just one little bit of doubt in the system and it all falls down. This is what has happened. Due to now decades of mistrust of the trust systems layers and layers of paranoia trust have been piled on. And those too have suffered mistrust. So now you have this massive mess of mis-trusted trust and as a result security has broken down. Or rather it has never built up.

---
Basically I have given up all hope that certificate authorities can give me something that is trust worthy and future proof. Simply because they don't like to talk to each other and subsequently they under mine each others public trust. My business is private in that I deal with a customer at a time.

I issue my own private certs and ask them to accept them. They pay me for a service. The contract they sign with me puts legal consequences around the violation of trust of our financial agreement. Thus I simply state this contract is the legal trust you require. If you trust the contract your trust my certificate. In most cases the contract is less expensive than buying a cert. Everyone wins and we actually have a contract of trust. I make more money and they customer pays less. Of course this model doesn't apply to strangers dealing with strangers but it works great for me.

Of course astronauts don't get it

[iYk6]

Yeah. Prostitutes don't understand SSL either.

Slashdot has a weird definition of "pro". I figured it meant cryptography professionals. But if the title came out and said "IT professionals" or "lumber professionals" then it would be obvious that the story has no value.

Re:Of course astronauts don't get it

[SteveWoz]

David Wharton's wife might understand SSL.

TLS vs SSL

[Frankie70]

TLS 1.0 is based on SSL v3. TLS 1.0 is also called SSL 3.1 sometimes.
There isn't really a huge difference between TLS & SSL 3.0.

Pick me, pick me!

[Anonymous Coward]

I know how to what SSL is! Fo' real!

Look at Scottrade

[Anonymous Coward]

It's an HTTP page, but they put a *picture* of a padlock in the middle of the page, so you know it's "ok" to login. And millions of people just go ahead and login from that page.

http://www.scottrade.com/

(Yes, I know the login does go to an HTTPS server. But it's the general idea that counts).

Re:Look at Scottrade

[DavidTC]

The real joke is HTTPS pages with a form that submits to an HTTP page. Sorta a 'Ha, we tricked you!' page. Bonus points if it submits it as a GET.

I think modern browsers catch that and give a message, but I remember seeing that way back when.

Re:Look at Scottrade

[Jaime2]

Or an HTTPS form that accepts your credit card number, then mails it back to you in a confirmation message 20 seconds later. I had that happen to me once.

I also know of more than one site that accepts credit cards numbers and them has the site email the order requests, card number and all, to the reseller for processing. It's amazing how many people don't see a problem with it.

Quote

[kcdoodle]

This is not my quote, and I do not remember where I read it.

"Using SSL to transfer information from server to server is analogous to using armored cars to transfer bags of money from one park bench to another."

can you think about what you just said?

[circletimessquare]

you like the current browser implementation of SSL because it is convenient for you... as a developer

you don't happen to think that making your life a pain in the ass as a developer is gee, i dunno, slightly less important than making SSL implementation a serious psychological wall for end users? you don't consider that goal slightly more important than your CONVENIENCE with secure website development? you don't consider your browser use to be slightly more esoteric and exotic than what browsers are used for commonly? do you think maybe your convenience, as a developer for crying out loud, isn't the fucking point?

in fact, turn in your nerd credentials in on your way out, don't let the door hit you in the ass, because emphasizing convenience over security is expected in userland, but your average developer- heck your average SECURE WEBSITE developer, as you profess to be, better be fucking downright hardcore evangelical about security over convenience. as a fundamental component of his profession

i fear for whomever you develop for. when they discover whatever you lazily left unsecured... because i seriously question your priorities and your state of mind and its appropriateness for your presumed profession

Re:can you think about what you just said?

[trwww]

> you don't happen to think that making your life a pain in the ass as a developer is gee, i dunno, slightly less important than making SSL implementation a serious psychological wall for end users?

Nothing was said about it being a pain in the ass... its the cost. Are you really suggesting someone like me has to spend thousands more a year on certs that will never be used by an end user? And then to make that cert actually perform correctly on a web site, we have to buy additional IP addresses? There is already not enough to go around as-is.

user education is the answer?

[circletimessquare]

you're pretty funny ;-)

and yes, i consider the imposition on small businesses to be far less important than a firm psychological wall for regular end users when it comes to security and the browser session

and no, i don't work for a certificate authority

We do expect average people to understand SSL

[Jessta]

"'People still don't understand SSL. This isn't much of a surprise... no one expects that grandma and grandpa know how to what SSL is and what it does"

Actually, everyone expects that grandpa nad grandma will understand SSL..if they want to do any secure transactions online.
Not matter how the browsers display certificates, unless people know what they are and why they are there then they won't be secure.
What percentage of people would call their bank to complain if they internet banking website didn't give an SSL certificate?
Browsers make a big deal about fake certificates, or self-signed certificates, but don't say anything when you go do an unencrypted site.
It's a terrible state of affairs, and until either secure transactions get eaiser or certificates are used widely enough that browsers can warn when a site isn't using one transactions of the average joe won't be secure at all.

- Jesse McNelis

Doesn't surprise me

[magamiako1]

I did a sort of "audit" of IT people around me and their knowledge of TLS certificates and how to implement it--and most have no clue. It's really quite a shame. I've been working on doing all sorts of SSL stuff and many different implementations. The things I've tested and used:

-OpenVPN using pre-shared keys
-OpenVPN with a CA infrastructure where OpenVPN verifies that a certificate was digitally signed by a CA. Interestingly enough, I haven't found anywhere to configure OpenVPN to only accept certain keys signed by the CA (it only verifies the CA signature)
-SSH with key-authentication, password-protected keys
-WinSCP with the same
-Apache w/ SNI and virtual hosts with self-signed certificates
-Apache w/ SSL and self-signed certificates, 1 host per IP
-Apache w/ CACert signed certificate, providing a link on the HTTP version of the site to grab the CACert Root certificates.
-Apache w/ SSL key authentication and PKCS #12 files on each client machine w/ Chrome, IE, and Firefox

Most of the information and documentation is spotty on setting all of this up. For example, OpenSSL's documentation on building certificate authorities is terrible, as they expect you to dump the CA certs/keys in the "demo" directory. For some of my earlier implementations I used OpenVPN's built-in scripts to create a CA, then public/private key pairs.

When you attempt to do client side authentication with SSL, Firefox gives you a cryptic error message if you forget to include the entire chain of trust within the pkcs #12 file. This is even if you put the CA Root cert into its Certificate store....you still need the entire chain of trust in the pkcs file. FF's exact error was "Failed for unknown reasons." When trying to find out why it failed, I actually got the answer in a completely unrelated IRC channel of nerds.

The Windows crypto store is still vulnerable to the null character bug, so this still puts IE and Chrome in the shitter with that. Shouldn't be a problem moving forward, however.

In fact, I would say I learned the most about SSL by Moxie Marlinspike's slides than I learned anywhere else, combined with knowledge accumulated over the years.

Re:Doesn't surprise me

[dfay]

In fact, I would say I learned the most about SSL by Moxie Marlinspike's slides than I learned anywhere else, combined with knowledge accumulated over the years.

Wow, you should Paypal him a donation for helping educate you... oh wait...

Long-term solution

[QuoteMstr]

First of all, a better long-term solution is DNSSEC. Because DNSSEC records are signed, there's a chain of trust going all the way back to the DNS root servers. Because you can trust DNS with DNSSEC, you can just store a certificate alongside your A records, and the browser can validate using that instead of some third-party CA certificate list.

It's a much cleaner system than the current CA one because the incentive are in the right place: as the manager of your DNS, you have every incentive to make your identity hard to forge.

Secure SSL and DNS Hijacking

[al0ha]

"Nearly 50 of the survey's nontechnical respondents just clicked through security warnings without paying attention to them, he says."

Not sure if this is 50 persons or 50%, but I suspected that in part this is true, which coupled with DNS hijacking by ISPs makes a problem a bank I use had (hopefully), and perhaps other commerce and financial sites, a real problem.

A few months ago I alerted my online banking instituion to an NXDOMAIN problem they had where occasionally logged in customer requests were being sent to a non existent server and my ISP subsequently hijacked those requests and delivered their own stupid page. Obviously this is incredibly lame as anyone who chooses to ignore the SSL warning will then send all of their auth tokens to the ISP.

I never received a reply from my bank and even tried to get Schneier involved as this bank is a major player. Regardless of the lack of response however, about two weeks after I notified the bank, I have not run into this problem, so hopefully they fixed it.

OF COURSE not!

[Hurricane78]

I mean how relevant is it to their survival and reproduction abilities? (Biological as well as ideological.)

Not much. Yeah well, you could get into problems. But it's so rare that you usually don't know anybody in person, who it happened to.

If someone could DIE from misunderstanding SSL, or even get hurt a good bit, you could be 100% sure, that anyone who deserves to reproduce and survive, would perfectly understand every tiny detail. :)

Microsoft runs the certificate root

[Animats]

One problem is that CA's expect "instant gratification" when they issue a new root certificate. Properly, root certificates ought to change very rarely. They should be published a few years before they're used, so there's time for people to install new browser updates and be confident that a fake root cert didn't get through. Now, though, Microsoft Windows Update is being used as the source of root CA authority. We're seeing far more root certificates, more than are really necessary.

The U.S. Department of Defense is going to all-HTTPS for most military sites, even the public-facing ones. But they have far too many root certificates, and few browsers have them all.

For Java use BouncyCastle

[crowne]

The name is a bit crazy but its easy enough to use. http://www.bouncycastle.org/java.html

http://mitm.bad/cacert.crt

[tepples]

D (create a self-signed CA certificate and sign your web site's TLS certificate with it) isn't much different from A (self-sign your web site's TLS certificate). D would appear to have the same drawback that Culture20 mentioned for A: it "gives [visitors] a false sense of security unless you can contact the site owner off channel and verify the cert manually." Visitors don't know whether a man in the middle is replacing cacert.crt, just as they don't know whether a man in the middle is replacing a self-signed TLS certificate. Perhaps posting the fingerprint of cacert.crt on widely used social networking sites might help work around this.

just publish your CA cert at http://my-toy-site.example.net/cacert.crt and link from your home page; you'll be prompted to install it in your browsers trusted key-ring.

A user agent that makes it hard to use a web site with a self-signed TLS certificate will also make it hard to install a self-signed CA certificate, especially one not downloaded from an already trusted HTTPS site, for the same reasons.

I agree with you that publishing a domain's certificate through DNSSEC is a better solution. But the fact that so many domain name registrars are also CAs for traditional TLS certificates would appear to act as an incentive against implementing DNSSEC.

Re:http://mitm.bad/cacert.crt

[PybusJ]

A user agent that makes it hard to use a web site with a self-signed TLS certificate will also make it hard to install a self-signed CA certificate, especially one not downloaded from an already trusted HTTPS site, for the same reasons.

You'd think so wouldn't you, but it doesn't seem to be the case. The copy of FF3 on which I'm writing this requires fewer clicks to install a CA cert than to add an exception for a site with a self-signed cert. This despite the fact that if I do persuade you to trust my CA cert I can go wild and start signing my own certs for paypal.com. But then Mozilla are not the worst.

the fact that so many domain name registrars are also CAs for traditional TLS certificates would appear to act as an incentive against implementing DNSSEC.

I'm feeling irrationally optimistic about DNSSEC at the moment, I think that those who have huge business interests protecting their somewhat-dubious-in-the-first-place CA operations will slow down DNSSEC, but probably can't stop it. And once the .com is signed, I get to choose which registrar to use; I can avoid those that make it hard to publish certificates.

Re:http://mitm.bad/cacert.crt

[PybusJ]

D would appear to have the same drawback that Culture20 mentioned for A: it "gives [visitors] a false sense of security unless you can contact the site owner off channel and verify the cert manually."

Sure, but I'm trying to address the "I need a no cost solution for my non-commercial site and I don't like FF3's annoying interface" scenario of the GP. At least the user has to manually do something different to initiate the cert install, though I'm sure someone will find a way to persuade people that they must click the right boxes to access their bank account and it will be game over.

I do think we need a wider range of key management options in browsers, and more research on the right/wrong interfaces and features. Even with multiple clicks, allowing exceptions to EXPIRED certs without having to use some separate command-line debug option is crazy. EV is a step in the right direction, but options that also go the other direction and tie into web of trust (looks even more ready for widespread use in these days of social networking) and/or persistence of identity.

The latter has worked well for SSH, and is being copied by Zimmermann in ZRTP. You could have a mechanism (visually distinct from an either an ordinary signed cert, or an EV cert) where when you first contact a website it will use the cert without warning but without giving the reassuring key/blue blob/etc. Once you've signed up for your account to access "Bob's cool fishing tackle forum", what you really care about is that it's the SAME site you go back to and enter your password next time, not that someone once paid VeriSign. Let the browser store the info and warn if it changes; there would need to be some standardised mechanism to handle cert updates so they look/act different to bad site warnings.

Insufficient editing.

[Futurepower(R)]

Yeah, I noticed that. Insufficient editing. I was in too much of a rush.

There will be a followup article...

[theendlessnow]

There will be a followup article describing what SSL is once the author of the article understands it.

Stay tuned!

If you can't wait, feel free to purchase an advanced copy through his secured website...

Persistence of identity vs. MITM in the wild

[tepples]

Once you've signed up for your account to access "Bob's cool fishing tackle forum", what you really care about is that it's the SAME site you go back to and enter your password next time, not that someone once paid VeriSign.

Mac OS X uses the same concept of persistence of identity when deciding whether to apply firewall settings to an updated version of an application: if they were signed with the same publisher certificate, even a self-signed one, they're the same app. True, it helps detect if a man in the middle has been added since the user signed up. But it doesn't help if A. one uses two different computers and they don't have some way to share their keychains, or B. a connection has been MITM'd from day one. In fact, B has actually happened.

99% of developers don't understand PKCS...

[Anonymous Coward]

I read the article and it's a pile-o-crap but the title is correct...

99% of developers simply don't get what public key crypto is, nor how it works. They don't understand what the 'key exchange' phase of SSL is nor why it is needed (theorically, it's not needed, but practically, good luck without that phase).

How do you want developers to understand what SSL is when they don't understand how public key crypto works? (granted, in some case TLS works with pre-shared keys, but that's a tiny minority).

Of course they've got no clue about SSH neither. They just now that "SSH is more secure than telnet" but they have no clue as to why.

Wanna have fun? Ask during a job interview: "Why is a symmetric key exchanged when two parties need to communicate securely over an insecure network?"

To me programmers that don't understand how public/private crypto works SHOULD write a simple application that simulates how, say, a very basic RSA system works. It's not hard, it's lots of fun (who doesn't like messing with prime numbers ;)

I've done it last century, just for the fun it.

That's the real problem today: most developers use technologies they don't understand (like TLS/SSH) and tools the don't understand either (do you think developers have the slightest clue as to how a kernel or a device driver work? Of course not.

It all looks like "magic" to them. That's a very concerning issue.

 

SSH, SSL, Stack Segment Register

[HiggsBison]

We're talking about Secure Socket Layer, not Solid State Logic.

No, I think we're talking about the Low Byte of the Stack Segment Register, SS.
SSH is obviously the High Byte of the Stack Segment Register.
I mean... duh! Like, who doesn't know that?

SSL secure

[lonecrow]

Yes, I am sure that there are plenty of happy hackers knowing that their SQL injection or cross site scripting code is encrypted before being successfully injected.

The sad truth

[hesaigo999ca]

The sad truth is this is a very correct statement of today's website admins.
Many do not know what they are doing, and should not be heading any sort of B2E site...I logged unto a website to order something, and got all the way to the end to find out there was no ssl lock once they were asking me for my cc info.
I stopped there, and sent them an email stating that this was below par standard, and that they should involve a better company then the one who designed their site. They replied they had a verisign logo so all was ok....ummmm....ok.....I guess I won't be shopping there anytime soon!

There are so many misconceptions about SSL

[Zarf_is_with_you]

S.S.L. Its only part of the security solution, not the end all and be all. One thing I find exceptionally annoying is web browsers confusing the heck out of users with security with over alarming security warnings when they encounter a site that has self signed certificates just because a site does not have a Signed Certificate does not mean its a security risk, then you have to go though a series of many clicks to get the self signed certificate accepted.

Having a self signed certificate is no more or less sure than a signed one. A signed certificate only verify s that that cert was issued to that server. Users need to be aware of the risks. If your accessing your companies web mail server and it has a self signed certificate its likely nothing you should be concerned with as its there to protect the transport of your password and data.

If you accessing your Bank online and it has a self signed certificate or its expired don't log in as it points to a problem. I have seen fishing emails that take you to a bogus look alike bank web site, that has a signed certificate.

I agree that commerce sites should have a signed certificate that is valid for the comfort level to the end users, the idea that is sometimes portrayed to the end user is that this site is Legit because it has a signed certificate which as we know is bogus, it does not prove the site is legitimate at all.

People as always need to be careful out here.