== How encryption without authentication would still be useful on the web In [[HTTPS is a legacy protocol HTTPSLegacyProtocol]], I talked about how we are stuck with encryption being tightly coupled to web site authentication then mentioned in an aside that they could be split apart. In a comment, Alexy asked a good question: > How could encryption be useful at all without authentication? Without > authentication, any MITM (i.e. ISP) could easily pretend to be other > side and happily encrypt the connection. And we would still get our > ISP-induced ads and tracking. The limitation that Alexy mentions is absolutely true; an encryption-only connection can still be MITMd, at least some of the time. Having encryption without authentication for web traffic is not about absolute security; instead it's about making things harder for the attacker and thus reducing how many attackers there are. Encrypting web traffic would do this in at least three ways. First, it takes passive eavesdropping completely off the table; it just doesn't work any more. This matters a fair bit because passive eavesdropping is easy to deploy and hard to detect. If you force attackers ([[including ISPs ISPsAreThreats]]) to become active attackers instead of passive listeners, you make their work much harder and more chancy in various ways. All by itself I think this makes unauthenticated encryption very useful, since passive eavesdropping is becoming increasingly pervasive (partly as it becomes less expensive). (One of the less obvious advantages of passive eavesdropping is that you don't have to handle the full traffic volume that's going past. Sure, it would be nice to have a complete picture, but generally if you drop some amount of the traffic because your eavesdropping machine is too overloaded it's not a catastrophe. With active interception, at least some part of your system must be able to handle the full traffic volume or increasingly bad things start to happen. If you drop some traffic, that's generally traffic that's not getting through, and people notice that and get upset.) Second, using encryption significantly raises the monetary costs of active MITM interception, especially large-scale interception. Terminating and initiating encrypted sessions takes a lot more resources (CPU, memory, etc) than does fiddling some bits and bytes in a cleartext stream as it flows through you. Anyone who wants to do this at an ISP's network speed and scale is going to need much beefier and more expensive hardware than their current HTTP interception boxes, which changes the cost to benefit calculations. It's also probably going to make latency worse and thus to slow down page loads and so on, which people care about. Finally, in many situations it's probably going to increase the attacker's risks from active MITM interception and reduce how much they get from it. As an example, consider the case of [[Ted Unangst's site https://www.tedunangst.com/]] and me. I haven't accepted [[his new root CA https://www.tedunangst.com/flak/post/moving-to-https]], so in theory my HTTPS connection to his site is completely open to a MITM attack. In practice my browser has a memorized exception for his current certificate and if it saw a new certificate, it would warn me and I'd have to approve the new one. In a hypothetical world with encryption-only HTTP, there are any number of things that browsers, web sites, and the protocol could do to make MITM interception far more obvious and annoying to users (especially if browsers are willing to stick to [[their current hardline attitudes BrowsersAndStrictHTTPS]]). This doesn't necessarily stop ISPs, but it does draw attention and creates irritated customers (and raises the ISP's support costs). And of course it's very inconvenient to attackers that want to be covert; [[as with HTTPS interception today HTTPSInterceptionNowRisky]], it would be fairly likely to expose you and to burn whatever means you used to mount the attack. None of this stops narrowly targeted MITM interception, whether by your ISP or a sufficiently determined and well funded attacker. Instead, unauthenticated encryption's benefit is that it goes a long way towards crippling broad snooping on web traffic (and broad alterations to it), whether by your ISP or by anyone else. Such broad snooping would still be technically possible, but encryption would raise the costs in money, irritated customers, and bad press to a sufficient degree that it would cut a great deal of this activity off in practice.