As long as they treat an untrusted certificate as worse than plaintext (when in fact it's strictly better) this is all theater.
* Security without authentication (While slightly better than plain HTTP) is near useless in the real world. Without the authentication that CA trusted certificates provide, you have no guarantee that the host you are communicating with is the site and not a MitM attacker, all the certificate stops is passive eavesdropping.
* The SSH system of connecting to a host once and saving the certificate is unworkable on the larger web. You do not and can not know the certificate of any random site you visit, the CA system solves this problem.
* Browser vendors and CAs actively want websites to be using CA trusted certificates. If browsers accepted untrusted certificates a larger number of sites would use them, as opposed to CA trusted certificates.
* Unlike HTTP, a minuscule number of websites use unsigned certificates and as a result it is safe to penalise sites using them. The end game for browsers vendors is that every site uses a CA trusted certificate; this update to chrome further shows their intent to deprecate HTTP.
If they were treated like http there would be no dialogue.
Passive upgrade from HTTP to HTTPS would be a different thing.
In the case of Chrome visiting an untrusted CA, it already displays https:// in red with strikethrough, which seems like a perfectly adequate way to negate any expectation of security. So the scary warning which takes two clicks to pass seems like overkill.
If I was making a browser, I'd just show a "secure" symbol for valid, trusted certs, an "insecure" symbol for anything else, and no protocols in the URL bar.
It's easy to predict a future that's already happened!
Fun fact: if you have a .COM name, guess who becomes your de facto CA in an all DNSSEC+DANE world? You guessed it: Verisign!
Verizon may sign the .com TLD, but that's fine: there are lots of registration providers that offer free DNSSEC support for you (eg gkg.net). Once you have that, you can convey your certificate hash securely, and thus you no longer have to pay some racketeering jackass company $100-600 a year just to get "*.yourdomain.com" in the common name field.
The current reality with DNS is that it's the wild west. All this emphasis on security and yet a DNS provider is entirely unencrypted and hijackable by anyone to send you to an alternate domain. If you haven't visited the domain before, even HSTS/HPKP won't help you.
Why are we beating around the bush with this? DNSSEC is, on its face, a key escrow scheme. Why would we even consider adopting it?
If I'm being phished by organized crime, I'd still rather the NSA not also be able to listen in.
The blinkard refusal of parts of the security community to understand this is appalling. An untrusted certificate means I know I am communicating with one and exactly one agent, whose identity I may later negotiate by other means.
All you're doing, then, is attempting to replace a heavily vetted, non-MITMable identity-verification scheme with your own ad-hoc version of the same, and what the security community understands is that you're incredibly likely to fuck this up in a way that makes it trivial for your attacker to forge their identity.
If I'm on an unsecured wireless network at the local Starbucks, untrusted TLS means I know nobody else in the coffee shop is snooping on it or injecting anything into it.
Why is this so difficult for people to grasp?
Security involve both a technical and social aspect. While the unsigned cert may offer better security (but there is no way for you to know) it most certainly offers a worse social aspect, that being a false sense of security.
So I'd say you're wrong -- it is strictly worse, because it offers no better security but a worse sense of security.
That Starbucks access point you've connected to might actually be the Pineapple belonging to the guy at the corner table, and he's injecting his own untrusted SSL certs into your HTTPS traffic and snooping/injecting into all your traffic.
EDIT - and to clarify what others have said: HTTPS implies a trusted connection (unlike plain HTTP). And a self-signed certificate cannot be trusted under any circumstances.
Your only protection would be if you pre-installed said self-signed certificate before going to the coffee shop. Your warning would be that the certificate was suddenly untrusted again.
It also wouldn't prevent an attack by someone that could forge a certificate from a trusted intermediate CA. HPKP could help there; but if you have someone like that targeting you in a coffee shop, you have much bigger problems.
The important thing though is that this is still not worse than plain HTTP. And in fact, it's better: it makes the attacker's job a lot more difficult. Especially when done at large scale (eg ISP ad injection.)
Any of 2,000+ root and intermediary CAs can sign a certificate for any domain name. "That won't happen", except it did: we know of at least DigiNotar and MCS Holdings.
Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth.
Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.)
DNSSEC+DANE would also help, but again, that'd also reduce reliance on the CA system, so don't expect that to ever happen.
Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there.
"We don't want anyone spying on you! ... unless it's your school, workplace, or laptop vendor (eg Lenovo.)"
> Any hostile government can compel a CA to issue a rogue certificate, and then force them to not disclose that this happened. Our browsers today trust such certificates from basically every country on earth.
There's a massive difference between "anyone can MitM this connection" and "a small number of nation-state actors might be able to MitM this connection if you do not implement HPKP." A system that prevent such mis-issuance events from staying secret (Certificate Transparency) is also being worked on and is picking up speed.
> Name Constraints would help protect against this, except that no browser implements them. Probably because it'd also make self-signed certificates a lot safer in the process (much easier to trust a self-signed CA that can only validate one domain name.)
AFAIK all browsers except Safari support name constraints.
> Plus, if you're using a work machine, your IT staff can install a certificate that Chrome and Firefox helpfully refuse to accept HPKP on and will allow said certificate to validate any domain it wants to. The same goes for any malware that stealthily installs a trusted CA for you. And 99.9% of users don't even know where their CA store is, let alone which ones shouldn't be there.
This argument doesn't make any sense - if someone is capable of installing a trusted root certificate on your device, it's over and any enforcement by the browser could easily be bypassed.
So what's next? Browsers begin refusing all connections to sites which aren't pinning their keys and using a CA doing transparency? How much of the web do we have to shut off and force into ludicrously-insecure plaintext connections before people start to get that maybe there's room for a spectrum of options here?
Certificate Transparency is required for some CAs (with known mis-issuance events) in Chrome, and I expect it will become mandatory for all publicly-trusted CAs within the next couple of years. I doubt this would affect custom (internal) CAs.
I'm not sure I understand the rest of your argument.
I agree completely. But the parent poster said "not-MitMable", which was false. It's more difficult, but the CA system has quite a lot of flaws. Even HPKP isn't a total solution: there's still the initial connection. I don't think there's an HPKP browser built-in solution like with HSTS yet. DANE would be the better option here -- we could reduce the number of trusted authorities from 2,000+ down to ~5 or so. At least enough that we don't have to have CNNIC when we reside in the US.
Further, HPKP scares me. It requires you to keep a secondary key, but if something happens like a fire, you could lose both keys. Not everyone is going to make duplicate backups of certificate keys and store them in bank vaults or doubly encrypted cloud storage locations or something. Especially not for small-time personal websites. Combine it with HSTS and really long max-age values and someone can get themselves into a world of pain quite easily.
> AFAIK all browsers except Safari support name constraints.
Oh, that's encouraging! When I read up on it, I found "The Name Constraints extension is mostly unsupported by existing implementations of SSL. They are likely to ignore the extension." And I know it tends to take browsers several years to support anything related to security (see Firefox's open bug for Curve25519 for the past three years; how many years it took us to get AES256-GCM cipher support [still not in Firefox 48 but will be in 50]; etc.)
So then, perhaps we can petition browser makers to allow self-signed certificate installations to be less terrifying/complicated when they are name constrained to just the domain in question? Yeah, didn't think so.
> This argument doesn't make any sense - if someone is capable of installing a trusted root certificate on your device, it's over and any enforcement by the browser could easily be bypassed.
You're right that once someone has administrator access, it's game over. But you could at least make their lives more difficult: force their hand into compiling a hacked up version of your browser that bypasses HPKP. That would discourage a lot of casual workplace snooping (you'd have to block users from installing browers/browser updates, too.)
The real objection I have is that right now, browsers say, "yes this connection is totally safe and secure!", even though it's actually not. You're being MiTM'ed by your employer/school/etc. If the fear of self-signed certificates is a false sense of security, then surely this is much worse since you even see the green lock.
There are plenty of stories about employers snooping on SSL traffic, and their employees being stunned/unaware their employers are doing it.
You're free to outsource the risk of losing key access by pinning to a small number of CAs you trust (and possibly have a business relationship with) instead of keys under your control. You're already willing to trust at least a small number of organizations for DANE, so you might as well do the same for HPKP.
> So then, perhaps we can petition browser makers to allow self-signed certificate installations to be less terrifying/complicated when they are name constrained to just the domain in question? Yeah, didn't think so.
How is it complicated? Firefox has a simple UI where you can import certificate files in the trust store (I just counted - it's < 10 clicks). Other browsers typically use the OS trust store, to which you can add certificates by just opening a pem/pfx file and following a few steps in a wizard. For the group of users that I'd trust to make reasonable decisions when they're facing a certificate warning, you can't honestly tell me that this would be an obstacle.
> But you could at least make their lives more difficult: force their hand into compiling a hacked up version of your browser that bypasses HPKP.
Or in other words, give users a false sense of privacy, which you're never going to get on a device that's controlled by someone else.
You're also ignoring the fact that this could be a hindrance to HPKP deployment, as users that visit sites that deploy HPKP would see warnings and possibly be scared off, meaning the site might lose visitors initially. That's typically a good way to make sure no one adopts a protocol. I'd rather have a protocol that does not attempt to solve an impossible problem than one that doesn't see any real-life usage.
BUT PLAINTEXT ALSO ALLOWS THAT, and in addition allows eavesdropping and alteration by another middleman.
Imagine that today I visit https://example.com and I see a certificate from a CA that I trust. Everything is good: my browser shows a lock icon. Tomorrow (or a year from now), I visit again, and a malicious state actor intercepts the TCP session and returns a certificate that's self-signed or from a CA I don't trust. What should the user experience be?
It definitely shouldn't be exactly the same as the trusted cert from example.com! It shouldn't be trusted at all. The behavior where the untrusted certificate shows up as "bad" protects me from MITM -- the difference between trusted and untrusted is the protection. Even though self-signed certs are in some sense better than plaintext, treating them that way will compromise the security of path-validated certs: any degree of trust creates a risk that they'll be substituted for CA-signed certs and trick a user into continuing.
In a world where there are only plaintext and self-signed certs, I'd agree that self-signed are better and should be allowed. But in a world with path-validated certs, accepting and trusting self-signed certs has downsides. HSTS helps with this but isn't a complete solution.
Your comment would be better without the "bangs head on desk" and caps expressing your frustration. https://news.ycombinator.com/newsguidelines.html
If you really think sites should never be MITM-able, then you should complain just as loudly on a plaintext site as you do on an untrusted root.
If I go to gmail I'd like to get a warning instead of accidentally not noticing there is no lock indicator in my browser.
If you're arguing for opportunistic encryption for "http://" links, I'm fine with that, but if I'm expecting HTTPS, I want either a trusted certificate or a big, red warning that's hard (or impossible) to bypass. I'm also not convinced that opportunistic encryption is worth the effort nowadays, given that the price of a certificate is zero in all but the most obscure of use-cases.
They do care about someone casually sniffing the password to the blog's admin interface when they post from a coffeeshop, though. But for years -- it's only recently that viable zero-dollar browser-trusted certs became a possibility -- we told those people "screw you, you're so dangerous for wanting that, we have to produce the loudest, nastiest, most terror-inducing popup warnings we can come up with just to slap on your disgustingly evil site and shame you into paying hundreds of dollars to a corrupt cartel".
Which confuses the poor schmuck who just wants that little bit of security against that particular, but far more common than MITM, threat model. De-conflating the two concerns -- inability to eavesdrop, and inability to impersonate -- might not be such a bad idea for those people.
You can argue for opportunistic encryption in HTTP, but I'd argue that it's cheaper and easier for most affected parties if browser vendors just help push the price of publicly-trusted certificates to zero, which is exactly what Mozilla and Chrome (among others) did. Rolling out a new protocol would've taken years as well, so I don't think we've lost much time choosing this approach.
No. You and some other folks on HN expect that.
The general public does not know or care that HTTPS conflates multiple issues. Some random person who just wants to have a secure way to hit the login page of their blog does not know or care. There's room for a spectrum of things and ways to indicate where on that spectrum a particular site is, but HTTPS has been forced to be the one-size-fits-every-entity-in-the-universe solution and so has bundled in things that just aren't relevant to a lot of use cases and made it a binary "either you implement 100% of this 100% of the time or else" proposition when that makes no sense to do.
So hence, it's working.
Not quite. The general public is taught (often in school!) to trust “https://” links.
You can't trust that a self-signed certificate is from the site is claims. You don't even know if you're safe from your WiFi hotspot.
It doesn't matter whether you believe their actions are altruistic (protect everyone!) or sinister (protect the CAs!) ... by treating self-signed certificates as worse than nothing, they send a pretty clear signal to independents that it's the latter. Treating them both the same would be a great step toward building confidence to those who don't trust their actions currently.
Or about displaying a warning for websites using HSTS -- which Gmail does.
For untrusted certificates, the answer is clear: very severe. If https://www.facebook.com suddenly has an untrusted certificate, it is almost certainly a case of MITM. The typical end user is not in a position to make an informed decision about trusting it anyway "because it looks right", so the page should just be blocked. In current browsers, bypassing these warnings is very cumbersome. And frankly, making the warnings less conspicuous would be irresponsible.
Now, you may argue that plaintext is even worse than an untrusted certificate. But whether we like it or not, in today's internet a browser cannot just block all plaintext connections. Making plaintext warnings as conspicuous as untrusted certificate warnings is unrealistic.
That said, there are other steps browsers could take to keep pushing https. Browsers could warn when transmitting passwords unencrypted. And, I don't know if it goes too far, but perhaps browsers could even deprecate persistent cookies for unencrypted connections.
You know that no party other than the sender has read or altered the resource in transit.
Do you really not see the difference there?
I have a blog. If I link to it here with HTTPS, you still have no idea who I am. A third party's assurance that I am who I say I am doesn't help you, because you still don't know who I am. What you care to know is that nobody has read or altered the contents of the transmission (yes: it's possible you're being phished, but that was true before -- now you know this phishing attempt is not also being eavesdropped or itself altered). Which untrusted SSL provides.
Why people ignore such an obvious point is beyond me.
Granted this opens up attacks like ssl stripping, https://github.com/moxie0/sslstrip, but certificate pinning is making that more difficult.
Again: I link to my blog, with HTTPS
You have no idea who I am. "Bandrami" is not a meaningful string to you.
What does Thawte's assurance that I am who I claim to be add to this situation? You shouldn't trust your MITM'er any more than you should trust a verified me.
Why does this have to be forced to be such a jump-through-hoops-and-pay-strangers-money thing? Why shouldn't I just make my own cert, note its fingerprint, and call it a day? Why does my browser have to repeatedly go absolutely apeshit over that?
And more importantly, if this is really such a massive unbelievable vector that literally every web-connected computer on earth must behave this way, why does SSH still just say "want to trust this key? OK, I'll get out of your way now"?
Oh, and every browser I'm aware of allows you to import CA certificates, so why not just do that once and get a nice, green lock?
I don't know many non-technical users who use SSH regularly, but even for technical users, I doubt too many check the fingerprint, so the TOFU property of SSH is still a problem. That being said, SSH's TOFU is not all that different from the process of installing a CA certificate in your browser so ... just do that.
except that it's 10000 times easier and 10000 times easier to claim that the remote key and the key you just trusted is the same.
2) I'm pretty sure all the browsers work just like ssh -- where you can accept it once and then it doesn't bother you again.
Https is current form is snake oil.
Think about it, an encryption system that stops an end-point server from passing decrypted data to somewhere else is basically impossible. It would mean finding a DRM scheme that actually worked, and we know that's impossible because of the analog hole.
The only way to stop this would be for the end-point server to be unable to decrypt the data ever, but still manipulate it. That's called homonorphic encryption and it's still only theoretical.
1) Yes, browsers could accept SSL with a bad cert chain and just show the UI as if it was plain text. However, then they'd need to have multiple codepaths to support what should be a very rare occurrence, in a very security sensitive part of the code: you have to teach the address bar to display http:// when it's really https etc, because otherwise you're diluting the meaning of https, but URLs themselves still say https, etc. It's just complicated.
2) Your justification for why it's meaningful doesn't really work: if browsers used very long lived connections then it might be helpful but they don't, they re-negotiate and re-establish connections constantly. If an eavesdropper wants to MITM you and you aren't doing cert checking then they just need to wait a minute or two until you click another link on the page. It's not an especially interesting security upgrade. In your blog example you don't know the blog wasn't altered in transmission.
And it should receive the exact same treatment.
(And, yes, browsers are finally fixing this by warning on plaintext pages. About time.)