4 ms·

> 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

by byuu 10y ago

> 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.

pfg 10y ago
> 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.

by byuu 10y ago

pfg 10y ago

> 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.