The user will be presented with a certificate error (or denied outright, depending on the browser). If the user decides to add an exception, only then will a handshake succeed and the MITM be possible (in this particular scenario).
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?
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.
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.
They probably wanted to encourage the new owner to use TLS as well.
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!
When you use XPKI, you are trusting every single CA in the world to certify every single site in the world.
A sane PKI would limit what CAs are permitted to certify (e.g. TÜRKTRUST might be permitted to certify *.tr, but nothing else — not foo.br, bar.gov or baz.co.uk). But XPKI is neither a sane nor a secure PKI.
This scenario might be plausible for targeted attacks by nation states, but not for something as simple as public WiFi.
The fact that Trustwave still has their CA certificate proves you wrong. They provided a sub-CA to one of their customers for the purpose of MITM. They got a slap on the wrist, gave a promist that they'd never do it again, and that was it. Your browser still trusts this company that has demonstrated that they are perfectly willing to compromise the safety of the whole CA system for a sale.
It wasn't WiFi, but that's not really a relevant detail here. Selling certs for the purpose of MITM is.
[1]: https://wiki.mozilla.org/CA:Communications#February_17.2C_20...
The link you posted is indeed a MITM proxy for SSL, but it will generate certificate errors, as my grandparent said. Users will know the MITM attack is going on (unless the website doesn't use HSTS and the attacker has stolen/bought a signing key from a CA registered in your device's trust store).