Title: â€˜HTTPS Everywhere’ Less Harmful Now

Author: Bob Schmidt

Date: 04 March 2020 23:09:43 +00:00 or Wed, 04 March 2020 23:09:43 +00:00

Summary: Silas S. Brown takes another look at web security.

Body: 

This is a follow-up to my article in C Vu 27.6 (January 2016), ‘HTTPS Everywhere Considered Harmful’ [1].

At the time (end-2015), I was particularly concerned about people whose only connection to the Internet is via 2G GSM, reading public articles. Since the question of ‘which article are you reading’ could be answered via traffic analysis (unless we make all articles the same length), in this situation HTTPS gave little benefit and had the huge drawback of being almost unworkable at 2G data speeds.

Of course, nowadays fewer people are stuck on 2G speeds, and some places (like Taiwan) have even turned off their 2G networks completely. Additionally, TLS 1.3 is making the protocol work better on high-latency connections, and browsers have made other optimisations that can actually make HTTPS even faster than HTTP. The only remaining problem is low-income users on ancient equipment that cannot keep up with the latest developments in encryption software.

Faster than HTTP?

The reason why modern browsers make HTTPS faster than HTTP is that they turn on the HTTP2 protocol (a successor to SPDY) and use its ‘multiplexing’, which is like an improved version of the ‘pipelining’ feature in HTTP/1.1 that most browsers didn’t actually use (they benefitted from Keep-Alive, but everything else was done by opening separate connections to the server rather than true pipelining). That means, on a page with images, scripts, etc, HTTPS can now result in less network traffic than HTTP, reversing the previous situation. The ‘BREACH’ attack (which relies on being able to trick somebody’s browser into sending chosen strings to the server and observing the size of its compressed responses) threatens to undo this if server administrators elect to mitigate it by switching off HTTP compression, but hopefully they’ll be sensible enough not to switch off compression when the Referer header confirms the request is a follow-up to the same domain.

Integrity and Wi-Fi

My previous position was that HTTPS is needed for situations where private data is being exchanged, such as in banking or private messaging, but it’s less-obviously needed when you’re reading public articles, especially if the question of ‘which article are you reading’ can be guessed anyway from response lengths (not to mention surveillance cameras and screen-recording software) so using HTTPS doesn’t actually buy you much. But what if someone tries to tamper with the article?

I would have guessed that if the websites you read are going to be tampered with, then this dark deed would far more likely be done by malware on either the machine you’re using or on the server itself, rather than the network in the middle. But then I visited London and tried to use the Underground Wi-Fi.

It’s generally accepted that public Wi-Fi services will intercept your first HTTP request and redirect it to an ‘accept our terms’ page. Newer smartphones even issue a test request automatically, to save you the trouble of finding an HTTP-only website to do it yourself. But the London Underground Wi-Fi was stuck on intercepting all HTTP requests, even after the terms had already been accepted and HTTPS was working perfectly. Since HTTP-only websites are a dying breed, the developers are now less likely to test that use-case, and we are going to see more public Wi-Fi that inadvertently blocks HTTP-only sites, so if it’s not available on HTTPS it simply won’t be available. (Thankfully I wasn’t stranded on the Underground: I had someone with me, plus I’d downloaded the blind-friendly descriptions of all stations from Describe Online in advance of the trip: I wasn’t naive enough to rely on the Wi-Fi working for essential navigation data. But the problems I had with non-essential access may show what’s coming.)

And that’s not even considering the possibility of malicious Wi-Fi networks injecting malware into pages, nor the question of whether having non-sensitive websites on HTTPS actually helps the more sensitive sites out there, by cultivating a general expectation that HTTPS is ‘normal’.

But what about old equipment?

The one remaining problem with HTTPS is that of old equipment. I’m not worried about the climate-change implications of doing cryptography on the server (it’s now negligible, and probably outweighed by the positive contribution of the latest protocols’ reduced traffic), but I do feel sad about client hardware having to be replaced before it’s physically broken (unless the new one has significant power-consumption benefits), and I’m also concerned about low-income users who can’t afford to upgrade their hardware as soon as their old device is no longer supported by software updates. Many newer Certificate Authorities are not recognised by the software installed on older devices, resulting in these users having to click through a myriad of security warnings (which is undesirable but manageable), or being locked out by HSTS (which means they have to look up how to clear the browser’s HSTS cache), but a bigger problem is an increasing number of servers, like Wikimedia’s, are insisting on using only the latest and most secure encryption methods, thus cutting off these users altogether unless they find a transcoding proxy service (such as the one I run, but it has traffic limits so I don’t advertise it prominently).

For a non-sensitive website, you could say ‘I’ll use HTTPS to work around Wi-Fi issues, but I’ll still allow old equipment to connect with broken old cryptography, because the risk of the network running a cryptography exploit is low enough, whereas the odds of plain HTTP being intercepted are higher’. But that position requires you to have fine-grained control of which types of cryptography your HTTPS server supports. If it’s a shared server then some well-meaning administrator could come along and turn off the old ciphers, but even if you run it yourself, you’re still at the mercy of your software vendor when you apply security patches, unless you want to take over responsibility of maintaining your entire software stack from the ground up. It seems paradoxical that plain HTTP, whose security is even worse than that of the broken ciphers, will likely be supported by vendors for longer than old-HTTPS will, but at least administrators are more likely to know what they’re getting by turning it on.

My personal website recently moved from being HTTP-only to accepting both HTTP and HTTPS. I wasn’t sure which old browsers support URIs starting with ‘//’ to mean ‘use the current protocol’, so I made all internal links relative and am currently considering mechanisms to select the protocols of external links when I know the site I link to supports both protocols (which few now do). At the time of writing I still declare plain-HTTP to be the preferred ‘Canonical’ URLs of my pages for search engines, which strongly advise you to choose a single ‘Canonical’ URL to accumulate all ranking points from different versions of the same page; most Western search engines now use HTTPS-only anyway, so you may be tempted to say ‘if the visitor was using a search engine then they must have equipment that can handle HTTPS’, but the dominant Chinese search engine ‘Baidu’ is still on plain HTTP, and there’s no way to declare different ‘Canonical’ URLs to different search engines (at least not without using user-agent based ‘cloaking’ which is inadvisable: they do spot-checks from other browser strings and IPs), nor is there a way to tell Google you have ‘moved to HTTPS’ without actually 301-redirecting all requests to it, which would defeat the purpose of supporting both protocols. Also, search engines tend to exclusively own their IP addresses and so don’t have to worry about old browsers not supporting SNI (Server Name Indication) when checking the site’s certificate, whereas this is more likely to be an issue for a smaller site on a virtual-hosting service. So I’m still not sure when I should set ‘Canonical’ to HTTPS, but at least I’m now supporting both protocols and will take links/bookmarks on either.

[1] Available to members at: https://accu.org/index.php/journals/2192

Silas S. Brown is a partially-sighted Computer Science post-doc in Cambridge who currently works in part-time assistant tuition and part-time for Oracle. He has been an ACCU member since 1994.

Notes: 

More fields may be available via dynamicdata ..