5 ms·

If one doesn't understand exactly how TLS works, this is the usual question regarding MITM. If there is "end-to-end encryption", just how exactly is it even pos

If one doesn't understand exactly how TLS works, this is the usual question regarding MITM. If there is "end-to-end encryption", just how exactly is it even possible to do MITM? In an ideal world, it just wouldn't be possible. With the existing system, certificate "errors" that are really just "warnings" should not be allowed to be bypassed. The fact that certificate errors can be ignored is something that should never have been allowed to take place. Unfortunately with the historical fact that legit certificates were inexcusably expensive to obtain for internal/test projects meant that self-signed certificates became commonplace. We're waiting for a genius to come up with a new strategy for encryption that doesn't rely on trust being determined by a third party entity (ie: certificate authorities). Letsencrypt is nice and all, but it's still just a free workaround for a system nobody really wants. "It's not possible to do it any other way" is just pseudo-speak for "nobody has invented a better way yet". Why the strategy for encryption has relied on public/private keys for so long with no real alternative strikes me as odd. After 30+ years, nobody has thought of something else?

schoen 10y ago
If sites use HSTS, browsers won't allow users to bypass the errors. See section 12.1 of RFC 6797: https://tools.ietf.org/html/rfc6797#section-12.1 https://tools.ietf.org/html/rfc6797#section-12.1 So you can encourage people to use HSTS and then get part of that behavior at least for individual sites.
- developer2 10y ago
  The HSTS preload list (referring primarily to Chrome's, which is also included by other vendors) in particular is something I find really strange. The current domain owner adds the domain to the HSTS preload list. That domain then expires or is released by that owner, without them requesting its removal from the preload list. Then someone else buys the domain without having planned to use SSL/TLS. The result? Weeks, even months, of not being able to use the domain without encryption, all because someone else previously had the domain added to the HSTS preload list. Removal from the preload list is by request only; there is no automation in place to detect the lack of an HSTS header to mean that the domain is no longer to be considered a participant. Even worse, the request to be removed can take an indeterminate amount of time to be disseminated to end users of the browser. The preload list is not pushed to clients via something like a daily digest; the list is hardcoded into releases of the browser. This means it can take an absurd length of time to see a domain removed from the list, as it depends on every individual user updating the browser to the latest version, and only once the vendor even gets around to updating the hardcoded list in a given release to include your domain's removal. How such a mechanism was ever acceptable is beyond me. Domain ownership is technically fluid, and yet the implementation was designed in such a way as to assume that domain ownership never changes.
  - nitrogen 10y ago
    How such a mechanism was ever acceptable is beyond me. They probably wanted to encourage the new owner to use TLS as well.
    - developer2 10y ago
      That makes little sense. Far more likely they just didn't take into account the fact that not every domain is a long-term "google.com" owned by a single entity for its lifetime.
teraflop 10y ago
> "It's not possible to do it any other way" is just pseudo-speak for "nobody has invented a better way yet". ... After 30+ years, nobody has thought of something else? Not really, I think you've hit the nail on the head. There are plenty of pie-in-the-sky proposals that start from an axiom like "we should replace the centralized CAs with a distributed, decentralized system", but so far I haven't heard of anything that is robust enough to credibly improve on the current architecture. Off the top of my head, the closest things I can think of to what you're asking for are: - Namecoin (depends on the Bitcoin blockchain, with everything that implies e.g. huge computational overhead, tight coupling to the volatile Bitcoin economy, and potential attacks from mining cartels etc.) - The PGP web-of-trust (places additional burden on users who have to decide whether many different intermediaries are "trustworthy"; totally impractical for John Q. Public, in my opinion) - CACert.org (still relies on a centrally trusted certificate issuer, but crowdsources the identity validation stuff) If you have better ideas, let's hear them!

schoen 10y ago

If sites use HSTS, browsers won't allow users to bypass the errors. See section 12.1 of RFC 6797: https://tools.ietf.org/html/rfc6797#section-12.1 https://tools.ietf.org/html/rfc6797#section-12.1 So you can encourage people to use HSTS and then get part of that behavior at least for individual sites.

developer2 10y ago
The HSTS preload list (referring primarily to Chrome's, which is also included by other vendors) in particular is something I find really strange. The current domain owner adds the domain to the HSTS preload list. That domain then expires or is released by that owner, without them requesting its removal from the preload list. Then someone else buys the domain without having planned to use SSL/TLS. The result? Weeks, even months, of not being able to use the domain without encryption, all because someone else previously had the domain added to the HSTS preload list. Removal from the preload list is by request only; there is no automation in place to detect the lack of an HSTS header to mean that the domain is no longer to be considered a participant. Even worse, the request to be removed can take an indeterminate amount of time to be disseminated to end users of the browser. The preload list is not pushed to clients via something like a daily digest; the list is hardcoded into releases of the browser. This means it can take an absurd length of time to see a domain removed from the list, as it depends on every individual user updating the browser to the latest version, and only once the vendor even gets around to updating the hardcoded list in a given release to include your domain's removal. How such a mechanism was ever acceptable is beyond me. Domain ownership is technically fluid, and yet the implementation was designed in such a way as to assume that domain ownership never changes.
- nitrogen 10y ago
  How such a mechanism was ever acceptable is beyond me. They probably wanted to encourage the new owner to use TLS as well.
  - developer2 10y ago
    That makes little sense. Far more likely they just didn't take into account the fact that not every domain is a long-term "google.com" owned by a single entity for its lifetime.

teraflop 10y ago

> "It's not possible to do it any other way" is just pseudo-speak for "nobody has invented a better way yet". ... After 30+ years, nobody has thought of something else? Not really, I think you've hit the nail on the head. There are plenty of pie-in-the-sky proposals that start from an axiom like "we should replace the centralized CAs with a distributed, decentralized system", but so far I haven't heard of anything that is robust enough to credibly improve on the current architecture. Off the top of my head, the closest things I can think of to what you're asking for are: - Namecoin (depends on the Bitcoin blockchain, with everything that implies e.g. huge computational overhead, tight coupling to the volatile Bitcoin economy, and potential attacks from mining cartels etc.) - The PGP web-of-trust (places additional burden on users who have to decide whether many different intermediaries are "trustworthy"; totally impractical for John Q. Public, in my opinion) - CACert.org (still relies on a centrally trusted certificate issuer, but crowdsources the identity validation stuff) If you have better ideas, let's hear them!