Threat models: the sushi place’s static website

At the USENIX Security Symposium 2017, Adrienne Porter Felt and April King gave a terrific presentation about HTTPS adoption and in particular showed the problems related with the long tail of websites that are not set up, or at least not set up correctly. After the talk, one of the people asking questions explicitly said that there is no point for static websites such as the one of the sushi place down the road to use HTTPS. As you can imagine, many of the people in the room (me included) disagree with this opinion drastically, and both April and Adrienne took issue with that part of the question.

At the time on Twitter, and later that day while chatting with people, I brought up the example of Comcast injecting ads on cleartext websites – a link that itself is insecure, ironically – and April also pointed out that this is extremely common in East Asia too. A friend once complained about unexpected ads when browsing on a Vodafone 4G connection, which didn’t appear on a normal WiFi connection, which is probably a very similar situation. While this is annoying, you can at least guess what these ISPs are doing is benign, or at least not explicitly malicious.

But you don’t have to be an ISP in the common sense to be able to inject into non-HTTPS websites. You can for instance have control over a free WiFi connection. It does not even have to be a completely open, unencrypted WiFi, as whoever has control of the system routing a WPA connection is also able to make changes to the data passed through that connection. That usually means either the local coffee shop, or the coffee shop’s sysadmin, MSP, or if you think you’re smart, your VPN provider.

Even more importantly, all these websites are the targets for DNS hijackers, such as the one I talked about last year. Unsecured routers where it’s not possible to get a root shell – which are then not vulnerable to worms such as Mirai – can still have their DNS settings hijacked, at which point the attacker has space to redirect the resolution of some of the hostnames.

This is even more trivial in independent coffee shops. Chains (big and small) usually sign up with a managed provider that set up various captive portals, session profiling and “growth hacks”, but smaller shops often just set up a standard router with their DSL and in many cases not even change the default passwords. And since you’re connecting from the local network, you don’t even need to figure out how to exploit it from the WAN.

It does not take a particularly sophisticated setup to check whether the intended host supports HTTPS, and if it does not, it’s trivial to change the IP and redirect to a transparent proxy that does content injection, without the need for a “proper” man in the middle of the network. DNSSEC/DANE could protect against it, but that does not seem to be something that happens right now.

These are all problems to the end users of course, rather than the problems of the Sushi restaurant, and I would not be surprised if the answer you would get from some of the small shops operator is that these problems should be solved by someone else and they should not spend time to figure it out themselves, as they don’t directly cause a problem to them. So let me paint a different picture.

Let’s say that the Sushi restaurant has unfriendly competition, that is ready to pay some of those shady DNS hijackers to particularly target the restaurant’s website to play some tricks. Of course everything you can do at this point through content injection/modification you can do by defacing a website, and that would not be stopped by encrypting the connection, but that kind of defacement is usually significantly simpler to notice, as every connection would see the defaced content, including the owner’s.

Instead, targeting a subset of connections via DNS hijacking makes it less likely that it’ll be noticed. And at that point you can make simple, subtle changes such as providing the wrong phone number (to preclude people from making reservation), changing the opening hours to something that makes it unwelcoming or even change the menu so that the prices look just high enough not to make it worth visiting. While these are only theoretical, I think any specialist who tried to do sysadmin-for-hire jobs for smaller local business has at least once heard them asking for similarly shady (or worse) tasks. And I would be surprised if nobody took these opportunities.

But there are a number of other situations in which a non-asserted content integrity can be interesting to attackers in subtle ways, even for sites that are static, not confidential, and even not controversial — I guess everybody can agree that adult entertainment websites need to be encrypted. For instance, you could undercut referral revenue by replacing the links to Amazon and other referral programs with alternative ones (or just dropping the referral code). You could technically do the same for things like AdSense, but most of those services would check where the code is embedded in and make it very easy to figure out these types of scams, the referral programs are easier to play around with.

What this means is that there are plenty of good reasons to actually spend time making sure small, long-tail websites are actually available over HTTPS. And yes, there are some sites where the loss of compatibility is a problem (say, VideoLAN, that still gets users of Windows XP). But in this case you can use conditional redirects, and only provide the non-HTTPS connection to users of very old browsers or operating systems, rather than still keeping it available to anyone else.