[steventhedev]

MITM attacks are common, but noisy - BGP hijacks are literally public to the internet by their nature. I believe that insisting on coupling confidentiality to authenticity is counterproductive and prevents the development of more sophisticated security models and network design.

[orev]

You don’t need to BGP hijack to perform a MITM attack. An HTTPS proxy can be easily and transparently installed at the Internet gateway. Many ISPs were doing this with HTTP to inject their own ads, and only the move to HTTPS put an end to it.

[steventhedev]

Yes. MITM attacks do happen in reality. But by their nature they require active participation which for practical purposes means leaving some sort of trail. More importantly is that by decoupling confidentionality from authenticity, you can easily prevent eavesdropping attacks at scale.

Which for some threat models is sufficiently good.

[tptacek]

This thread is dignifying a debate that was decisively resolved over 15 years ago. MITM is a superset of the eavesdropper adversary and is the threat model TLS is designed to risk.

It's worth pointing out that MITM is also the dominant practical threat on the Internet: you're far more likely to face a MITM attacker, even from a state-sponsored adversary, than you are a fiber tap. Obviously, TLS deals with both adversaries. But altering the security affordances of TLS to get a configuration of the protocol that only deals with the fiber tap is pretty silly.

[pyuser583]

As someone who had to set up monitoring software for my kids, I can tell you MITM are very real.

It’s how I know what my kids are up to.

It’s possible because I installed a trusted cert in their browsers, and added it to the listening program in their router.

Identity really is security.

[steventhedev]

TLS chose the threat model that includes MITM - there's no good reason that should ever change. All I'm arguing is that having a middle ground between http and https would prevent eavesdropping, and that investment elsewhere could have been used to mitigate the MITM attacks (to the benefit of all protocols, even those that don't offer confidentiality). Instead we got OpenSSL and the CA model with all it's warts.

More importantly - this debate gets raised in every single HN post related to TLS or CAs. Answering with a "my threat model is better than yours" or somehow that my threat model is incorrect is even more silly than offering a configuration of TLS without authenticity. Maybe if we had invested more effort in 801.x and IPSec then we would get those same guarantees that TLS offers, but for all traffic and for free everywhere with no need for CA shenanigans or shortening lifetimes. Maybe in that alternative world we would be arguing that nonrepudiation is a valuable property or not.

[simiones]

It is literally impossible to securely talk to a different party over an insecure channel unless you have a shared key beforehand or use a trusted third-party. And since the physical medium is always inherently insecure, you will always need to trust a third party like a CA to have secure communications over the internet. This is not a limitation of some protocol, it's a fundamental law of nature/mathematics (though maybe we could imagine some secure physical transport based on entanglement effects in some future world?).

So no, IPSec couldn't have fixed the MITM issue without requiring a CA or some equivalent.

[YetAnotherNick]

The key could be shared in DNS records or could even literally be in the domain name like Tor. Although each approach has its pros and cons.