This might be intended. Supporting SSL is better than not supporting it (well, except in situations where an OpenSSL bug could leak your server's memory, but that's a bit of a stretch <http://filippo.io/Heartbleed/#www.peereboom.us> -- but put this aside), because it's always better to encrypt traffic even in a way vulnerable to passive attacks; and some people may reasonably opt-out of the SSL CA business because they do not like the way it is structured, doubt the security it offers, or feel that they do not need it.
(I use a free StartSSL signed certificate, but only because it's free and not very hard to get. If there were no free provider with widespread support, I would be very happy to use a self-signed cert and think of it as a protest against the stupidity of browsers which present SSL+self-signed as less secure than plain HTTP).
If someone has passive access to snoop, the odds they can perpetrate an active attack are so close to 100% as to make the distinction immaterial. Encryption without authentication accomplishes nothing.
Worse, self-signed certificates train users to freely click through certificate warnings. People running servers with self-signed certificates are actively reducing what security we have available for the web.
If we ever do get anything better than the existing CA structure, it won't do us any good if users have been trained to ignore browser security warnings anyway.
His claim is that browsers treating websites with self-signed certificates as less secure than non-encrypted websites by displaying big fat warnings is just about the greatest gift we can give to organisations like the NSA. It's not true that there is no material distinction between an active attack and passive eavesdropping. For the NSA to do active MITM attacks on all self-signed https traffic (in a world where all unencrypted http is replaced with self-signed https) would take massively more resources than passively monitoring unencrypted traffic. Plus the odds of them getting caught would be very high (since some people are going to notice that the certificate that shows up on the client is not what the server sent).
You can't make browsers simply treat self-signed certificates the same as plain HTTP. You still have to warn the user that their desire for a secure connection (conveyed by their request to retrieve an https URL) cannot be fulfilled, and do so in a way that assures all users will notice before they do something like, say, type in their password.
There is very little self-signed HTTPS traffic out there. The NSA assuredly has the resources to MITM all of it.
Yes, someone at some point would notice if it were all attacked, but the key thing is that, almost all of the time, nobody would, and you yourself have no assurance that your connection has not been MITM'd unless you have done some other out-of-band verification on that specific certificate. That is almost never done, especially by the general public.
You might be willing to gamble your own security, but you should not gamble everyone's security.
There is very little self-signed https traffic out there because browsers have chosen to treat it as somehow less secure than unencrypted http. (I do realise it's rather problematic to mess with the security expectations of https at this point, but you could imagine an http variant that allows encryption without authentication, without giving dire warnings to users.)
If all http traffic instead used self-signed https, then the NSA assuredly would not have the resources to MITM all of it. So because of the reflexive "self-signed certificates are worse than no encryption!" dogma, we have an Internet where most traffic is unencrypted and therefore trivial for governments and criminals to intercept.
Regarding certificate warnings: even if self-signed certificates were accepted, browsers could still put up a warning if the certificate changes between visits, similar to ssh's treatment of host keys (being relatively unsuspicious of unknown hosts, but putting up a big fat warning if the host key has changed).
This is why I disagree with many things PHK says. Like you, he pays a great deal of attention to how he wishes things had turned out, instead of figuring out how to make what we have better.
Get browsers to act in the way you want, then we'll talk. Until then, people using self-signed certificates are causing active harm now.
Counter point: If you self sign your browser does cert pinning.
With CA certs it accepts ANY valid certificate.
Certificate pinning should be on by default for all certs. I use CertPatrol to accomplish this: https://addons.mozilla.org/en-us/firefox/addon/certificate-p...
> You still have to warn the user that their desire for a secure connection (conveyed by their request to retrieve an https URL) cannot be fulfilled
Normal users do not enter URLs in their browsers, much less https ones, and do not pay attention to the https prefix when clicking a link or pasting an URL, so the client retrieving an https URL usually does not indicate a desire from the user to have a secure connection.
I believe that users have been trained to pay attention to the presence of padlocks and colors in the address bar, not to the presence of the "https" prefix, so that self-signed HTTPS could look the same as plain HTTP from that perspective and I don't believe security harm would ensue.
> There is very little self-signed HTTPS traffic out there. The NSA assuredly has the resources to MITM all of it.
I find this doubtful. I am willing to believe that the NSA might be passively snooping on a large portion of HTTP traffic, but performing active attacks, even when you have the resources, is a lot harder to be doing smartly (unlike passive attacks, which are invisible).
If the NSA were routinely MITMing self-signed HTTPS traffic, knowledgeable users would have noticed. They would be investigating under which conditions, and along which routes, does the MITM take place. As nobody seems to have witnessed this, I doubt that is happening now, or that it is likely to happen in an indiscriminate way.
> You might be willing to gamble your own security, but you should not gamble everyone's security.
Even then, how is MITMed HTTPS traffic worse than passively monitored, and potentientally MITMable, HTTP traffic?
As for your point about training users to ignore security warnings: blame the browsers, not the websites. If using self-signed HTTPS is no worse than HTTP, those messages are stupid, and I'm not going to give up on the additional security of self-signed HTTPS just because browsers are doing something stupid with it.
That doesn't make any sense.... even if you don't trust a CA at all, it is impossible for a self-signed cert to be MORE trustworthy, since it provides absolutely ZERO authentication. It could be created by anyone at all, including on the fly by a MITM.
That's only true if you're not verifying the identify of the presented cert - how do you suppose client/server certificates work? For example, along the lines of what every VPN system in the world uses? VeriSign isn't involved in the transaction between my company laptops and the ASA in my datacenter.
Besides, having the third party CA signature in this day and age doesn't tell me much other than the person presenting the cert coughed up whatever protection money the particular face of the PKI protection racket demands, and ostensibly the CA did some level of verification (could be more, could be less, I honestly do not know or have time to find out) as to the "identity" of the person who's info is on the CSR.
Really, for your own uses, you're better off self signing with your own CA, noting down the identifying information of the cert at generation time, and then installing that cert as trusted either ahead of time, or hitting it from the third party and double checking the information matches up.
Maybe he is saying by removing trusted root certificates he will trade the possibility of receiving a fraudulent certificate the first time he uses a site for the possibility of not being warned if a certificate changes because the trusted roots are compromised. If he needs to worry about state actors there is an argument to be made for this trade-off, but really if he was worried about that he would be delivering certificates out of band and not visiting any unknown websites on the machine he needed that level of security on. (Maybe justifiable against mass surveillance where you're a general target rather than a specific one).
Ah, yes, certificate patrol[0]. However, your argument, I think, is not valid. Sure, it's technically possible for him to know if any cert changes, but in reality very few people are going to install the extension and those that do might not even notice the message because it notifies the user so frequently (fully desensitizing them I imagine).
I don't think that his choice not to install an extension invalidates his argument.
very few people are going to install the extension
My argument is, pinning certs is a bad reason for removing the root certs from the browser, since you can pin them without breaking the CA chains.
I'm not sure how does that work as a counter-argument; We're discussing a decision of a particular person, not some broad policy. How is the number of people who install the extension relevant?
those that do might not even notice the message because it notifies the user so frequently (fully desensitizing them I imagine)
So does the browser, if you remove the root CA certs.
Yes, verifying certs out-of-band is most likely more secure than a CA. I was not counting that in the self-signed cert vs CA signed cert comparison, since that is not what most people mean when they talk about a self-signed cert.
You ignored my first point. You can trust the self signed certificate to be used by the same entity(A or C) after the first connection, admittedly you may have been MITM (by C) for that first time(and renewal times) and because of that you may be screwed. Alternatively if you are trusting other entities(B) to verify the certificate of A while B are not trustworthy then after that first communication (even if that first communication was legitimate) another entity (C) can pretend to be A and so long as B verifies C then you are in trouble. I am pointing out that they are different risks and I agree that in nearly all use cases it is better to use verified certificates than self-signed for general internet use, that doesn't mean that there isn't a reason to do otherwise though.
Yes, if you use a self signed cert and out-of-band verification, then yes it would probably be more trustworthy than a third-party verified cert (like a CA).
I don't think that is what the parent was saying, however, in saying he would trust a self-signed cert. I don't think he meant "Call up the website host and ask for them to verify their public key"
TOFU: don't most browsers tell you if you've been to the site before, and whether the cert has changed since your last visit? I seem to recall that at one time Firefox could be configured to not even complain when it saw a self-signed cert it recognized?
I have been using the following phrase a lot lately:
Schrodingers-Murphy's-Law:
"When you look at it, it breaks!"
I joined this company in January and had to peel back all the layers of hte onion to find out where its weaknesses were, and as soon as we start looking at how a component of the system is built and how it works - it breaks. We learn a ton real fast and figure out how to make it resilient.
Yesterday in my Ops Stand-up I told my staff: We have come a long way in rebuilding the infra; I am now paranoid that a security vulnerability will be the next thing that causes an outage...
Lucky, our ELBs on AWS were all updated without issue...
[1] - http://en.wikipedia.org/wiki/Muphry's_law