Mozilla SSL policy bad for the Web
cs.uml.edu
cs.uml.edu
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.
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.
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.
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.
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.
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).
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.
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.
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 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.
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.
(2) is not a real problem; your browser won't let you hit a "rogue" SSL site without clicking through a scary warning.
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?
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).
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!
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.
http://blog.johnath.com/2008/08/05/ssl-question-corner/
An especially pertinent point from his post:
"Several CAs accepted by all major browsers sell certificates for less than $20/yr, and StartSSL, in the Firefox 3 root store, offers them for free."
As suggested by the original article, the correct behaviour would be to treat it as though there's no security whatsoever. After all, logically, how is being encrypted but unauthenticated worse than being unencrypted and unauthenticated?
(1)
A connection to onlinebanking.bankofamerica.com in which an attacker has hijacked the SSL handshake and subbed in a self-signed certificate, and
(2)
A connection to https://login.ratemykitten.com?
You appear to be arguing that the warning for this situation should be tuned to (2).
If we're not going to warn folks about unencrypted links where every proxy in the way is a man-in-the-middle attack waiting to happen, why are we going through such contortions to warn them about the same attacks in a situation where they are much harder to accomplish?
I've never understood this warning at all.
While I understand you want to be very egalitarian about it most users would value their personal information's safety over the principle of a completely open web.
In the spirit of the open web you are free to a) not use Firefox b) fork the Firefox project c) file a bug with Firefox d) contribute to Firefox and argue for this feature to be removed
The warning is vibrant because the condition it reports on can be created by an attacker on any SSL connection. That stupid warning might be among the top five security mechanisms on the Internet.
You're assuming all kinds of facts not in evidence. My point was simply that the FireFox tradition (now enhanced) of warning about secure transfers to unverified sites was dumb: it creates a clear incentive for sites not to use HTTPS, so as not to scare their users.
Self-signed certificates are "insecure", if you want to use that word, because there is no way to verify them. If you're Bob sending your certificate to Alice, Alice has absolutely no way to tell if she's seeing your cert or Mallory's.
Self-signed certs get used in non-HTTP apps, and in internal apps, because an out-of-band mechanism (thumb drives, key continuity, etc) is being used to distribute the certificates. If Alice already has your cert, and all you have to do is prove you hold the privkey for it, you and Alice have no problem.
Of course, if you think about this for 5 more seconds, you quickly realize that nobody on the Internet has your cert already, and without Verisign to break the tie between you and Mallory, you're totally fucked.
What should the browser do in this situation? Someone pointed out that an HTTPS connection with an unknown self-signed certificate identifies the site just as well as a plain HTTP connection, suggesting that we should treat both connections as equally insecure: so simply hide the yellow bar.
please, don't try to tell me that users look at the yellow bar
You really want to warn the user in this situation, so Firefox gives them a big error message and makes them take positive action (adding the unverified, possibly malicious, certificate to their list of fully trusted root certificates) before they can get past it. That is fair enough.
But then there is the kicker. The browser can only tell that a certificate has changed if it has already recorded the old one. It can't distinguish between a site which has always had a self-signed certificate and one which just happens to have one today, unless it recorded the certificate yesterday. So it treats both as man in the middle attacks, which explains why Firefox will always give you a warning about unverified certificates until you verify them yourself.
It's one thing to force users to confirm something whose security can't be guaranteed. It's another to make it so hard they stop using your app. FF3 has other nice security features I can't benefit from at all if I'm not using it.
And StartSSL may be free, but it's not easier than "click the Safari icon".
Encryption should be separate from identity verification.
Of course identity verification should be properly vetted and you should have to pay a fee, and have documents checked etc.
If however, you just want to provide security for your users by encrypting http, you should not have to jump through hoops and spend money.
Now, the idea of "I'm talking to the same person I talked to last time" is useful, but if the users are all conditioned to accept random certificates without understanding, then when they go back a second time (and the attacker is waiting), they'll agree to the new cert, just like they did the first time.
HTTP < Encrypted HTTP < Encrypted,signed HTTP
Unauthenticated encryption is 'better' than a plaintext in just one thing - it protects against passive snooping. Anyone willing to splice the connection will have full access to all your plaintext data and you won't even know about it. As such it's nothing more than an equivalent of reversible traffic obfuscation.
So if your "better" meant "obfuscated", then, yeah, it's better. But it's no more secure (in a conventional security sense) than a plaintext.
Encryption is useful, and separate to identity verification.
You can absolutely do what you're requesting by creating your own CA and signing certs for your sites and distributing your CA cert to your users somehow.
If you can figure out how to reliably provide this service for free you could revolutionize crypto on the internet. You might start by looking at what cacert.org has done to see what problems they've hit and why it's not as easy as it seems.
The business model behind certificates may very well be a huge scam. Unfortunately, the technical model behind having a small number of trusted certificates shipped with your browser is not. Until that link breaks, you don't get security without paying Verisign.
The reason you 'trust' Verisign/Thawte/Comodo/Geotrust/GoDaddy is because their roots are in the OSs & browsers. You can't get in those root stores without a hell of a lot of hoop-jumping. I know this. The money you pay for a cert does go to covering the costs of the background checks you have to pass through before you get the certificate.
Trust has to start somewhere - why not with large companies who have undergone rigorous procedures that also have been vetted by the companies you're implicitly trusting by installing their software?
What you and I are really saying is that a company like Thawte has staked their business on those pubkeys, so that we at least know that if they screw up, they stand a good chance of losing the company.
Webmaster Bob wants to add his key to the server. Bob goes to the server page and hits add key button, puts in an email address for the webmaster, his public key and submits. Then the public key server sometime in the next couple hours goes outs and checks the website itself. If the two match it adds it to the database.
You can have the server require a reverse DNS lookup and also have it use something along the lines of OpenDNS to help secure against fraud. Also if the server itself uses a CA cert to secure data on transit that would also help secure it. Require a revocation key to invalidate self signed keys on the database would also further security.
Then user Joe can add "Self-sign Pub key extension" to Firefox to automate the checking of public keys.
This allows for a relatively cheap self-signing check. Does a minimal amount of is this the real website I'm using but still not quite the level of a paid CA cert that say a bank should have.
(Apologies about the ramblyness of this post)
http://www.cs.cmu.edu/~perspectives/
(hat-tip Lauren Weinstein)
Encryption ensures that only the entity you are sending the message to can read it. If you can't be sure of the entity you are sending the message to, then what's the point of encrypting it in the first place?
Why does the article pick out Mozilla in particular? Are they suggesting that FireFox makes it overly complex to ignore the warning and continue on?
The MITM pretends to be the bank's server (or whatever) when talking to you, and pretends to be you when talking to the bank's server. Both channels can be encrypted, but the attacker still sees (and can modify) everything that you think you're sending directly to the bank's server.
This is the key point that most people seem to be missing here. If browsers didn't warn about self-signed certificate, the entire system would break down because an attacker could just use a self-signed cert in a MITM attack, and the user would have no idea.
Am I talking to this guy.
Am I talking to the same guy as yesterday. << Anonymous certificates handle this use case.
If paying $20/year is too inconvenient for you to transfer your data securely, then perhaps the data isn't sensitive enough, and you shouldn't bother.
The problem with not having a valid certificate is this: if both sides can't tie every packet in the SSL handshake back to Verisign or Thawte's pubkey, attackers can inject their own handshake passwords and set the session key.
I think this a good thing. 99% of user probably don't need to or shouldn't interact with pages with self-signed certificates. That's a good thing. Self-signed certs should really only be on development pages. I'm sure this is a good anti-phishing measure.
A certificate, signed or no, is a means to establish a secure connection between Alice & Bob. This ensures no one is snooping or modifying the data passing between them. this is a good thing that should be encouraged in an age when your ISP injects ads and the government keeps tabs on what sites you visit.
A signed certificate is a means of authenticating the identity of the presenter of that certificate, to give some reassurance and trust about the other party.
These two things can and should be kept separate. What Mozilla is doing is making it much more difficult to have a secure-by-default Web.
Imagine if your mail program suddenly stopped receiving email unless each sender either paid 100 bucks per year to VeriSign, or faxed a copy of their passport to Microsoft, or you went through a scary, four-step process to "enable" them.
Let's not encourage people to adopt security mechanisms that provide no real security. Let's make the security mechanisms we have today, which are strong enough to stop many governments and all of the largest corporations, cost-effective and easier to deploy. Let's solve the right problems, instead of trying to make ourselves feel better by sugarcoating browser warning messages.
Unless you have a means of verifying the public key fingerprint I you are SOL. Wish I had more modpoints for you.
If self signed certificates were indistinguishable, I may have been making connections through man in the middle machine located there without any way of knowing.
Since SSL covers two cases of security, both encryption and identity, maybe it's time to invent a new icon - i.e. this web site is secure (a lock) but its identity could not be verified (an id card).
Self-signed certs wouldn't show warnings, but wouldn't show the ID-verified icon. CA certs would show both.
If they're worried about user education, the first time firefox encounters a self-signed site, it could provide a permanently dismissible dialog.
So don't even show the user that it's SSL. I don't care if my site seems more secure to the end-user, it just should be SECURE without regard to the mindset of the individual operating on it. Heck, even hide the https! Banks and online stores, sure, they should buy SSL certificates so they ease the end-user's mind. That is a relevant operating cost to incur for those individuals.
I wouldn't be so sure about that.
Umm, I would. Running Wireshark or tcpdump to sniff traffic over the wire is easy, and analysis can be done offline at the attacker's leisure.
Hijacking DNS and phsishing for users' login credentials to other sites requires a lot more preparation, and in most cases, prior selection of the desired target sites.
An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. Without SSL in the way, she now owns several thousand bank account logins and Yahoo Mail passwords.
(2)
An attacker in Estonia manages to compromise a single DNS cache serving a residential cable ISP in Tuscon, AZ. With SSL in the way, she now owns several bank account logins and Yahoo Mail passwords.