(I don’t think that was a Roger Corman film, but it should have been!)
I use the term “hacklore” to refer to the urban legends surrounding cybersecurity. Hacklore is everywhere, and this holiday season, you’re bound to hear it nonstop: “The Russians will load your phone with malware if you scan QR codes!” or “Hackers will steal your banking details if you use a USB charger at the airport!” and so on.
One of my favorite examples of hacklore is the notion that evil baristas can monitor all your internet activity if you connect to public Wi-Fi in a café. According to the myth, they can view your bank balance and place fake orders if you shop online. These tales are so exaggerated that it’s surprising anyone still buys into them.
While hacklore can be funny, let’s be clear: hacklore isn’t harmless. Diverting people away from evidence-based cybersecurity practices deprives them of the opportunity to improve their security posture. And no, the rare hypothetical instance where warning someone about evil baristas could be helpful doesn’t justify this misinformation. You wouldn’t advise people to avoid trees on a sunny day just because, in rare cases, lightning could strike.
With that in mind, let’s examine my own network traffic over the past six months. I tap my home network with a tool called Security Onion, an incredible open-source platform that every network defender should know. I’ve been able to gain useful insights into what’s actually happening on my network.
I’ll be looking at my Chromebook, and then my iPhone traffic. I’m looking at this time period: 2024/05/01 12:00:00 AM — 2024/11/01 12:00:00 AM
Chromebook
For my Chromebook, here’s the raw breakdown of HTTP to HTTPS (SSL) traffic. Note that I’m looking at the number of network connections, not hosts.
Let’s zoom in on the HTTP traffic to see what’s going on. In the next chart, we see the network connections to various specific hosts. I abstracted the host names to not embarrass the owners.
Some of these require a little explanation.
- The Google connectivity checks: These are connections to connectivitycheck.gstatic.com and there are a lot of them. The request is “/generate_204” and the HTTP return status code is indeed 204, or “No content”. It seems to be related to the Chromebook trying to figure out what network it is on, probably part of a captive portal strategy. If you have more information please let me know.
- Static assets: These can range from video from streaming services to static images (like CSS files or images). It’s possible that there could be some information leakage in this category. For example, if a drug store retailer used HTTP to load product images, then you might see which brands of mouthwash I was looking at. It’s unlikely that there would be private information in this category. I spot checked a bunch of items and they were uninteresting. But if you wanted to find a problem area, this might be a good place to start.
- PKI: These are things like OCSP queries to get certificate revocation status.
Since those are not really security risks so far as I can tell, let’s pull them out of the analysis. Here is the list of just the websites that used HTTP and not HTTPS.
This table shows the breakdown of sites, including the number of connections my laptop made and the number of destination hosts.
That adds up to 558 connections that the evil baristas could have observed and modified. These evildoers could have seen a vacation rental website that doesn’t use HTTPS, an old comic site from 2002, and my visit to a hobby website. Oh, and my trip trip down memory lane! The horror!
Some of the hobby-related HTTP sites had just one connection, which I confirmed were redirects to the HTTPS site. After that, all the connections were over HTTPS. I don’t know if they use HSTS headers. Maybe I’ll look into that later.
Out of 222,597 total connections, there were 558 non HTTPS connections (to 16 sites), which is about 0.25% of all connections that the evil baristas could have watched and modified.
It’s important to note what was not on the list of HTTP sites: Financial services like banking, online retailers, and search engines. These are precisely the sites some people use to stoke fear with public Wi-Fi hacklore. In 2024, if your bank doesn’t mandate HTTPS for all traffic, it’s time to change banks.
iPhone
Now let’s look at my iPhone traffic. This is a bit simpler since 99.9% of my connections were over HTTPS.
Here are the host counts:
The jibecloud.net reference relates to RCS texting. I was playing with the RCS setting on my iPhone on 10/10/2024. The others have self-explanatory names.
So basically I see zero HTTP connections to websites and services from my iPhone. I’m actually a little surprised. I expected at least one iPhone app to leak some information.
Conclusion
This analysis is, of course, anecdotal, and everyone’s traffic will look different. But in my case, the bottom line is clear: well over 99% of my web traffic now runs over HTTPS, making non-HTTPS sites a rare sight.
The progress made by the internet ecosystem over the past decade to make security the norm is remarkable. Web users everywhere have benefited from the dedicated efforts of device manufacturers, operating system developers, browser creators, website maintainers, Let’s Encrypt, standards organizations, TLS library developers, and countless others.
Yet, there’s still work to be done. Some challenges are technical, like driving further adoption of CSP, HSTS, secure DNS, and other security standards.
But some challenges are societal. Security professionals need to dispel outdated advice that warns average people against banking or shopping on public Wi-Fi. That’s not an actual problem today for most people. If you’re someone who routinely shares this advice, consider a shift in approach. If you believe the landscape is so dangerous that public Wi-Fi is unsafe, it’s time to specify which vulnerabilities need addressing. In other words, what changes would make you comfortable enough to tell friends and family it’s safe to use public Wi-Fi and set aside the vintage VPN recommendation?
I honestly want to know: What would change your mind? If your answer is “nothing” then ask yourself if you are making a technical and risk assessment, or a religious one.
