> 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.
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 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.
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.
A system that prevent such mis-issuance events from staying secret (Certificate Transparency) is also being worked on and is picking up speed.
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?
I don't think anyone has indicated that there are any plans to enforce key pinning (which is completely separate from Certificate Transparency).
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.
> 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."
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.
> Further, HPKP scares me. It requires you to keep a secondary key, but if something happens like a fire, you could lose both keys.
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.
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.
Untrusted TLS does not mean that nobody else in the coffee shop is snooping on it.
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.
A self-signed certificate can be trusted when my client recognizes it as one that I already trust. E.g., maybe it's for a server in my home, to which I have previously connected via my wired home network.
This part is wrong, sorry. An attacker can sign his own certificate for your domain, and send you that. Then he can communicate with the real site on your behalf.
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.)
Doesn't it just mean that they'd have to MITM you to snoop or inject? It's better, since it raises the bar some, but it doesn't really change what's possible there.
It's not strictly better -- it gives a false sense of security. As you plainly showed by believing that having https at a Starbucks with an untrusted cert is safe, which it is clearly not.
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.
For non-CA certs, you either manually verify hashes or install the self-signed root cert. So no, the attacker would have to at minimum find a SHA1 hash collision, otherwise the client will know they're being MitM'ed.
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.