Unbelievable. I've been poking about here for like 6 months now. You are all very smart people. Why is this so hard to understand?
If you do not have a valid certificate signed by a CA, SSL is not providing any security.
Yes, the warning you get when you visit a site with an invalid cert is much scarier than what you see if you visit an unencrypted site. But it's the sites that use encryption that users care about, because those are the sites that get their passwords and credit card numbers.
Perhaps you think the browser should make an exception for self-signed certs. After all, there's nothing "wrong" with their signatures. Nothing's expired. No signature fails to validate. Why not just make the URL bar orange or something? Because anyone can create a self-signed cert and sub it into a Bank of America SSL connection.
It sure is annoying that you have to pay $20 every year to keep an SSL cert. I totally agree that this a problem. But right now, without that $20, you have a connection that provides cryptographically zero security. Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem.
I don't fully agree with what you are saying. A self signed certificate DOES provide 100% cryptographic security, in that nobody sniffing on the the wire, or whatever open wi-fi I happen to be using can see my data.
Securing the connection from 'spies' is only one part of an general SSL certificates function - the other is proving the identity of the site you are connecting to. A self signed cert provides zero use here.
So a self signed cert has some uses - that said, perhaps its the more techy person who would ever care about encrypted connections but not identity, and they can probably work out how to get FF to accept their cert anyway.
Would you like to bet your social security on that statement? I'll win that bet. If I can watch your packets on the wire, I can inject my own packets, or redirect you to the middleman of my choosing. If I can inject my own packets, I can sub in my own certificate. You won't know, because you're using self-signed certificates --- meaning, meaningless certificates.
If I can watch your packets on the wire, I can inject my own packets
You're certainly persistent, but this is not strictly true.
1. Major links that are sniffed, summarized by ASICs, and backhauled. These are necessarily passive, and public key ops are too expensive to do at this scale.
2. Service providers would take a lot of heat from both the public and banks themselves if they started proxying encrypted connections to insert ads or track browsing history.
If I can see your packets, I can sub in my own ARP (local) and DNS (remote) responses. In the absolute worst case, which never happens, I also see your TCP sequence numbers, and can simply inject segments directly. You have no hope of keeping me out of your connections. The "passive-only" attacker is a myth --- hackers don't use solsniff.c anymore.
Yes, I've used ARP spoofing to perform MITM attacks.
You seem to be ignoring that some established institutions are malicious these days. An ISP can happily track their users all day long, and perhaps inject some ads that the average user won't care about.
However, an ISP cannot routinely proxy SSL connections. As I said, such blatant tampering would cause too many complaints (at least at this time). And is a bank supposed to accept risk from the ISP proxy being compromised?
When the gloves are off and ISPs are inserting themselves that far up the protocol, I'll gladly say that crypto without PKI is absolutely useless. Until then, there is a class of passive only attacker. Perhaps you don't see this kind of attack as a problem, but some of us do.
It seems bizarre to me that someone would engineer a protocol that makes connections resilient against nosy ISPs, but not resilient against the lowest common denominator of organized crime.
Which is why I frown when I see somebody who wants to "dabble" in crypto by making their own cipher that probably "wouldn't stand up to serious analysis" (is there any other kind?).
But the protocol has already been engineered. Its a matter of handling certain a use case sanely rather than flipping out. An https connection with an untrusted CA has exactly the same absolute security as a plain http connection. Why doesn't Firefox throw up big warnings for every http page I visit?
Having said that, Mozilla could alleviate the situation by including CAcert in their trusted certs. Domain ownership assurance is really the only thing common SSL certs get you anyway. (And I've got no problem with "high assurance" CAs getting special indications).
I agree. An HTTPS connection with an untrusted certificate has exactly the same security as a plain HTTP connection. So don't use HTTPS without trusted certificates. It's confusing to end-users and, by instilling the click-through reflex, is damaging the security of the Internet.
It is vanishingly unlikely that Mozilla is ever going to include cacert.org among their trusted CAs, because hundreds of thousands of people use Firefox to access their banks, and there are plenty of smart security people that work at and with Mozilla.
The algorithmic security of unsigned HTTPS is the same as HTTP. Luckily, Mozilla already has a method of displaying such a page - leaving out the lock icon and colored background. There should be no "click through" unless you're proposing a user click OK for every http page they visit as well.
PKI is a hard problem, and CAs do it well for brick and mortar identities. However, that is certainly not the end of the story. The reason someone would choose to run SSL without paying for a certificate is that they believe most everything should be encrypted, but do not value the security properties provided by CAs.
You still haven't said why Mozilla should arbitrarily block the use of HTTPS in such a fashion. Should GPG prevent me from verifying a signature if it is not in my web of trust?
The only thing a basic SSL certificate (from one of the 47 (!) default CAs) does is guarantee ownership of a domain. This is exactly what CAcert does. Visiting paypal.com, I see the name of the company and country in green, from a higher assurance certificate where more thorough checks were done. This is what banks should be using.
You're steadfastly avoiding answering a really basic question:
If Mozilla "accepted" self-signed certs (to some definition of "accepted"), what should it do when someone browsing to onlinebanking.bankofamerica.com receives a self-signed cert that an attacker has spliced into the connection? It sounds like you want to make the warning for that condition less severe. Your browser cannot tell the difference between your personal self-signed cert on your own app, and an attacker's self-signed cert appearing on a BofA connection.
If the user is already interacting with onlinebanking.bankofamerica.com and the certificate changes, that's a serious error.
If the browser has a longer-stored certificate for onlinebanking.bankofamerica.com (say because they've bookmarked it), and the level of the certificate changes, that's an error.
If the browser has no idea about onlinebanking.bankofamerica.com (perhaps the user typed it in, probably without the https prefix), then the user must verify the security properties of the site. This is what a user must do now, as there may be no redirect to https, or redirect to an arbitrary https. If the site sends a certificate signed by an unknown CA, the user would not see a lock icon, blue background, green company name, etc.
I missed this comment because it's 4 days old, and I waste too much time here so that's like 5 clicks back through my comment history. But here's the answer to that: the first time you connect to a site, your browser has no certificate to "remember". People are unwilling to accept a security model that doesn't protect their first access to B of A, especially when a security model that does is available.
(And who knows if you'll get this. Interesting that HN fails at direct discussions)
The current usage model doesn't protect my initial access to BoA without me verifying that:
1. I've got a https connection
2. I haven't been redirected away to a rogue (SSL) site
You see the (https url)->(page retrieval) process as uniformly trusted (correct me if I'm wrong). I see stratification based on which third parties are doing the verification. Perhaps I'll have to wait for the emergence of a protocol explicitly designed for such things.
To borrow from Eliezer, if you really can't believe something that is happening can happen, then your mental model is wrong.
I originally posted: Every time I have hit this message, it has been mostly irrelevant to me and disrupted what I was doing
[I'm no longer so certain - I can't be sure my router configs haven't been stolen by a MITM attack. I suppose I really ought to find out how to generate and install SSL certificates from a trusted root on them, and post them to someone at the remote sites on an encrypted pen drive.]
I manage a fair amount of networking kit, I find Google results to mailing lists with mysterious and pointless SSL connections. As someone posted in the "End of the Windows Era" thread: "I don't care what OS you have, as long as you have a reasonable browser". This isn't reasonable behaviour.
SSL does not prove anything useful - at the very most that you are connecting to the site your browser intended to connect to, assuming the site DNS hasn't been hacked.
Anyone can pay $20 and get a valid certificate and that doesn't mean you should trust them with your bank account details. Any site with a valid SSL cert might have been hacked behind the SSL termination. If you're scared of MITM attacks, aren't you just as scared of valid SSL certificates on sites with fake DNS or hacked servers?
The security of the DNS and the security of SSL are unrelated. This is one of those Reddit memes that won't die. You can claim to be bankofamerica.com all you want, but you cannot complete an SSL exchange with a signed certificate that says so.
If Eve can take control of DNS and redirect bankofamerica.com to an IP on her servers, and it goes to a webserver with a ceritficate signed for "bankofamerica.com" by a widely trusted CA, then the browser will load it without complaint and show it as a padlocked site.
The only guard seems to be whether she can get any certificate company to sign a certificate for bankofamerica.com. Since it's cheap and easy to get basic SSL certificates from many places, this doesn't seem a very difficult obstacle for her to overcome with a bit of forging, social engineering, insider access, bribery, etc.
(I imagine that she could go to the real bankofamerica.com, save the certificate details it presents, and pass them on MITM style - but hope there are replay-prevention techniques involved. This doesn't affect the question above, though).
The premise of your argument is that it is "cheap and easy" to get a certificate signed by a CA trusted by Firefox and IE for a "bankofamerica.com" domain.
It is not "cheap and easy" to get that certificate. As evidence for that argument, I put forth the fact that no criminal has ever managed to do it.
Now you're starting to see why certificates are so important to security of SSL!
That event was so rare that it made national news, hasn't happened since, and has never happened to a financial institution.
If your argument is that Verisign sucks, though, I won't contest it. I'm not saying the CA business model is good; I'm saying that it's silly to say you can run SSL without CAs.
"Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem."
Good point. You won't find it - performing proper background checks cost more than that.
That's not to say you can't get cheap certificates - they're the domain-only validated ones where you only have to prove ownership of the domain.
These are bad because they appear the same as properly-validated certs when they shouldn't. Kaminsky's recent work shows the DNS system can't always be trusted, and so certificates validated on that weak system cannot be trusted either.
However, until GoDaddy and Geotrust stop having lots to lose from DV certs being marked-down by browsers, I doubt they'll let MS, Opera, Mozilla and the rest do such a thing.
You might be overestimating the intelligence of your audience. Reddit, one of the ycombinator startups, famously kept all its users passwords in clear text, as 'using hashes was too hard' - until they were hacked.
If you do not have a valid certificate signed by a CA, SSL is not providing any security.
Yes, the warning you get when you visit a site with an invalid cert is much scarier than what you see if you visit an unencrypted site. But it's the sites that use encryption that users care about, because those are the sites that get their passwords and credit card numbers.
Perhaps you think the browser should make an exception for self-signed certs. After all, there's nothing "wrong" with their signatures. Nothing's expired. No signature fails to validate. Why not just make the URL bar orange or something? Because anyone can create a self-signed cert and sub it into a Bank of America SSL connection.
It sure is annoying that you have to pay $20 every year to keep an SSL cert. I totally agree that this a problem. But right now, without that $20, you have a connection that provides cryptographically zero security. Short of coming up with a way to create a trustworthy CA that runs for less than $20 a year, there is no great solution to this problem.