This Time Self-Hosted
dark mode light mode Search

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.

Comments 5
  1. At a previous employment at a pretty big Telco/ISP a major vendor showed off their DPI gear that could not only throttle bittorrent (which the company wanted because airspace is a shared medium and one person torrenting actually does hurt everyone else in that mobile cell), but they also bragged about how it could replace ads on websites and replace with the Telco’s ads, thus producing revenue for the Telco.I asked them “How is that not straight-up stealing?”, and they responded by changing the subject.

  2. A lot of DNS providers do not support DNSSEC… Zuver will let you enable DNSSEC on your domain, but when I did, I quickly discovered their own DNS server was not able to accept the records needed, and the process couldn’t be reversed.I had to scramble to get BIND9 hosting my DNS and find someone to act as the slave. Quickly, I found BuddyNS which worked to get things resolving again, but they don’t support DNSSEC, so that presented issues. Roller Network used to provide this service free and worked fine when they did, but then they decided to make that US$5/month… for that price I can get a VPS which is what I’ve done. As an extra safety net, I also have puck.nether.net which also offers a free service.So with my host in Brisbane, an OpenBSD 6.1 instance running in Vultr’s Sydney data centre, and puck.nether.net, that gives me the geographic distribution I’m after. Some point I’ll set up the Vultr instance as secondary MX too, because at least it’s on Australian soil. ;-)Doing DNSSEC has meant that I’ve needed to get my head around the tools and key management, how to set up and manage a primary DNS server, and how to configure slaves to do AXFR transfers. It’s been a good learning exercise for me, but a steep learning curve… and I think one that would be beyond the typical owner of a small non-IT business.

  3. So I have some notes on this in the post that is scheduled for next week. One of the other talks and papers at the same conference was «A Longitudinal, End-to-End View of the DNSSEC Ecosystem» https://www.usenix.org/conf… which effectively boiled down to “Not ready yet”.

  4. Yeah… that link is broken it seems (is this it here? https://www.usenix.org/node… but that’s the impression I get too having done it myself.If you’ve got a very savvy IT person/department (ideally more savvy than me) looking after your website and domain, you at least have a chance of getting this to work. If we’re going to expect widespread adoption though, we need to reduce the barriers to usability.Sadly, DNS is one of these things (like SMTP) that was invented when the Internet was a little village. Now that the Internet is a major city, you really can’t leave your front door wide open the way you’re used to… DNS does need to evolve, bolt-on solutions like DNSSEC really aren’t going to cut it long term and the challenge is working around the inertia of a community that have relied on a protocol in its current form almost as long as I’ve been alive.

  5. (Fixed the link.)Totally correct on the usability problem! And indeed the following talk from the one I started this post from was about the usability of HTTPS itself :)And yes, DNS like SMTP and BGP clearly need to be replaced, but there is a big problem with trying to change these protocol, as too many people rely on them. It would be an even bigger problem than moving everything to IPv6. Sigh.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.