Two weeks ago, in a sentiment echoed far and wide on the interwebs, I talked about the human, and logistical difficulties associated with our hierarchical trust model for SSL certificate signing. This week, I’d like to point out that – even in the absence of a good authentication system (a really difficult problem to solve) – HTTPs has a lot of value.
HTTPs is actually a pretty good protocol. It uses appropriate encryption to protect the contents of internet traffic. It uses appropriate handshakes to produce session keys. Although vulnerabilities have occasionally been found, they are often minor. HTTPs is a good end-to-end encryption system. However, that doesn’t mean that it can solve the authentication problem.
Although HTTPs ensures that you’re using an encrypted connection, it doesn’t guarantee who you’re connecting to. Mallory, the perennial malicious party, can still eavesdrop your (unauthenticated) HTTPs connection by tricking you into make an HTTPs connection with her, then perpetuating a man-in-the-middle attack for the rest of the session. Unfortunately, there’s not much you can do about that, without the ability to verify that the end party is who they say they are. Authentication is a pretty non-trivial problem.
However, this does not make HTTPs useless, it just prevents it from being a silver bullet for all our www security woes. Conversely, there’s actually a lot that you can do with HTTPs, without even coming close to solving the authentication problem. Indeed, you can make lots of shortcuts to give you significant value in the authentication space, without solving the problem. In a world without CAs, your browser could accept SSL certificates by default, and warn you on if the certificate changed for a particular site. Measures like this are by no means foolproof, but they do give HTTPs a good deal of value over straight HTTP, even if authentication is hard.
While using HTTPs in this way doesn’t give you true authentication, it does have benefits. One of the parties most able to eavesdrop on a typical user’s connection is that user’s ISP. Unauthenticaed HTTPs doesn’t prevent this attack, but it does make it illegal. Conducting such an HTTPs MiM attack probably constitutes wire fraud in the USA. Many other countries have similar statutes about this sort of behaviour. Reading the contents of your email just went from trivial to felonious in an easy security measure.
There are weaknesses to this protection. Your ISP (any anyone else – like Eve the eavesdropper – listening on the wire) still knows what sites you visited, and what pages you read. They still have clickstream and timing data on you. If your sites use HTTP GET rather then POST, then much more information may be exposed. However, you’re significantly better off than you would be with plain old HTTP. Eve can no longer see your website usernames and passwords (more on that next week). If you’re using cookies to log in before you view private pages, nobody can determine the contents of those pages. Even for public pages, Eve would have to request that content herself, which gets very bandwidth-intensive if Eve’s trying to watch millions of ISP customers.
Even in the absence of trusted or trustworthy authentication, HTTPs is valuable. With contemporary computers able to handle the encryption tasks without pause, there is no reason not to use HTTPs for every page on every website.