This post is brought to you by a Mastodon post, from Italian blogger Paolo Attivissimo back in October, complaining about the ease with which he can identify the names of other people around him when connected to a hotel WiFi.
It’s a perfectly valid concern, particularly when considering that WiFi is pretty much table stakes for public venues nowadays, despite the widespread 4G/5G phones and tablets, as modems in computers are if possible less common than they were ten years ago (Filippo has been wondering too), and different providers take different dim views of tethering.
Unfortunately, in the replies that followed, I ended up with a fairly warmed up exchange with an unfortunately common character: someone who has heard about a problem existing many years ago, and has not followed up with the improvements in technology to address said problem, repeating the same slogan all these many years later.
So I decided to set the record straight by writing up a modern view of hotel and public WiFis, to update my older post that these many years later is quite outdated. It helps that, now that lockdowns (though, let’s be clear, not the COVID infections) are a thing of the past, I’m back on the road enough that I have quite a bit of experience of how various places handle their WiFi. And quite ironically, I drafted this post from an A380 and “typesetting” it in a hotel room.
First of all, let’s look at what my original post covered in quite a lot of details: the problems related to routing traffic over public WiFis: clear-text traffic being easily discoverable, and DNS resolution “leaking” which site people are visiting even when using HTTPS.
The first part of this is, for the vast majority of the Western world, almost completely fixed. The combined efforts of Google and Mozilla over the past ten years to push HTTPS everywhere paid off, and nowadays it’s effectively impossible to find a non-encrypted login page, and it’s exceedingly rare to find non-encrypted sites at all — at least within Europe and North America.
With the exception of a few contrarians (and the excellent NeverSSL), we seem to have accepted that the cost of encrypting all the traffic is worth it to completely root out the risks related to clear text traffic. The talk by April and Parisa is still worth a watch, and if you’re not convinced about the importance of encrypting all traffic, please see my other post.
Leaking websites through DNS requests is not something that is completely solved, but it’s getting closer. DoH (DNS over HTTPS) is a solution to this: instead of sending the request through the existing cleartext protocol, DoH uses HTTPS as the transport layer, encrypting the connection, and allow validating the identity of the server you’re talking with.
Deployment had lagged behind for a while, mostly because the main users of this feature have been the browsers rather than the operating systems, and Mozilla had (in my opinion unfounded, but understandable) concerns about routing all the resolutions to GoogleDNS.
Nowadays, though, I believe Chrome defaults to using DoH opportunistically, and you can use it as the system resolver both in Linux (when using systemd) and Windows 11, if you so configure it. Unfortunately, it does appear like DHCP and NDP are currently lacking a way to autoconfigure this on the clients.
The remaining hot point is traffic confidentiality: back when I wrote the post, I spoke of how easy it is to convince an access point to send you a copy of the traffic that is not meant for your device. While this can be fixed with configuration (namely, enabling client isolation), this has other implications (which I’ll get to later) and cannot always be enabled. There should really not be any reason for fully public WiFi networks not to enable this, though.
But even when the router does isolate the various clients, thus just setting your WiFi client in promiscuous mode doesn’t send you everybody else’s traffic, there’s still the problem that password-less WiFis (which are still the most common case of public WiFi, possibly more now that many hospitality venues switched to QR-code links rather than physical menu leaflets) have effectively no encryption, as the only practical, password-less, encrypted WiFi security option is WPA3, which is not widely deployed for a multitude of reasons.
And while WPA was already weak when I wrote that article, my understanding is that WPA2 is basically broken already by now. Passive collection of wireless frames for offline decoding is a feasible attack, if you’re at risk enough.
So, should you use a VPN to protect the confidentiality of your WiFi traffic? I would say no, but with a few caveats. When most people think of VPNs nowadays they think about commercial players that offer a way to tunnel your connection via their own server. These are heavily advertised in podcasts and YouTube videos as either a way to defend from hackers (LOL) or more realistically as a way to defeat region locking (I’m still baffled by how many legit podcasts don’t fear suggesting people to outright break the terms of service of Netflix and the other streaming services!)
Using these solutions solutions would encrypt a good part of the traffic indeed, at least between your device and the router, but you’re just shifting who can see the traffic between your device and the Internet: instead of the operators of the router (and possibly anyone in physical proximity of you), you need to put trust in the operators of the “VPN” service.
An alternative to this is to use Tailscale, creating an exit node always present in a safe location (a rented VPS, or home), and routing all of the traffic through that. I actually do something like this to get IPv6 support (because much as a contrarian, I do like having easier access to my own network software!) In that case, you’re trusting whoever is your ISP there, but since you’re likely already trusting them, I can’t imagine that to be a significant stretch. Whether you prefer trusting an ISP that at any rate already sees likely most of your traffic, or the operator of a service that boast putting your accounts at various streaming services at risk of being terminated in their own ad copy, is up to you.
Also, before people write in for this particular reason, the reason why I’m putting scare quotes around “VPN” is that the original meaning of the term referred to Virtual Private Networks that would be established between one or more geographically diverse sites, like multiple offices of the same company, or the home and and office of professionals. Traffic aggregators use this name because, from the client itself, they’re virtually indistinguishable from the original use case (indeed, most of the time they are implemented using the same APIs!), but the way these services imply the Private part refers to your privacy honestly upsets me.
So, yes, if you don’t trust the operators of the public WiFi you’re on (which in many cases would indeed be a good idea), consider using Tailscale before paying some traffic aggregator to be able to pin your movements.
Finally, one of the strawmen I used in my previous post was the possibility to turn one of those pocket WiFi routers into something that stays connected, possibly hidden, to an open network to gather as much data as it possibly can surrepticiously. Discussing this MacGuffin recently, I was told that many professional WiFi management systems do have the option to kick and block MAC addresses that try to stay connected longer than a specific amount of time, precisely for this reason.
I find this cute — while MAC addresses used to be the one stable identification of a device on a network, and indeed allowlists of MAC addresses used to be a simple and cheap option to “protect” networks. Unfortunately, threat modeling and technologies move on, and for similar reasons why OUI-derived stable IPv6 addresses are no longer the default, most operating systems (at least Android, Windows 11, iOS, and I would suspect macOS) provide a pseudo-random MAC addresses to WiFi networks, changing usually daily (now you know why sometimes paid-for WiFi networks on planes take your money twice.)
What this means is that the specific device doesn’t need to stay connected 24/7 with the same MAC address to be able to covertly access the network: it can connect every 8 to 12 hours with a new MAC address, and there’s little left in terms of options to block them short of rotating the credentials.
So, what is the problem that Attivissimo complained about, and what can be done about it? Well, his post was vague at first, but knowing him, and following up with more context on the following weeks, it is now clear that he was referring not at the fact that he could see which other computers were connected but more importantly who did they belong to.
This is because most of the computers connected to a local network broadcast their host name over mDNS. This might not be the case for most Linux devices (like anyone cared), but it would be the case for Windows devices that didn’t select the Public Network option, and I believe it’s the case by default for both iOS and macOS devices.
I’m not quite sure why these two latter systems do that by default, I assume that it has something to do with the ability to seamlessly switch from iOS to macOS or between macOS devices, so that they can sync somewhere locally. Back in the days, mDNS (which was popularized by Apple under the name Bonjour) was also fundamental for features such as AirPrint and iTunes Music Sharing (DAAP) but these feature feel like they should be gated under being connected to a home network, rather than at a random public WiFi.
Even worse, and not something I knew at that point, is that the MAC address randomization (which I already hinted at above) didn’t extend to the address provided in the mDNS responses. But at least that article confirmed that having a VPN client connected doesn’t disable mDNS on the local network.
Worse yet, Apple devices default their system’s name to be extremely descriptive, for ease of use of an user with multiple devices. This dates back to at least 10.3 and the iPod: the naming scheme includes the name of the user, and what the hardware is — I believe they switched from full name to first name at some point, but I do remember learning about HFS+’s Unicode normalization because iTunes helpfully named my iPod’s filesystem “Diego Elio Pettenò’s iPod” and Linux lost it with the accent normalization.
So you may end up looking at the devices connected to an open network and see Michael’s iPhone, Wendy’s iPad and Niamh’s MacBook Pro because people don’t bother rename their devices, not realizing that they might be broadcasting their names to everybody around them. Whether this is something that they would actively want to keep hidden depends on their threat model though, particularly with common first names. It might be worse when you go by a particularly unique name — you won’t see Flameeyes’s MacBook any time soon.
It also seems naive to believe that Apple will make any change to this particular feature any time soon. Particularly as the device name carries over in practically every interaction with said device: not just local network but Bluetooth and AirDrop.
Are there any solutions that the operators of public WiFi networks could proactively implement to increase the safety of their customers? It’s complicated.
The reasons why these names are exposed to other users of the network are mainly two: the devices are allowed to broadcast to the network, and the lack of client isolation allow the traffic from one client to reach another (rather than allowing a client to only communicate to the router.)
For public venue WiFis, such as a restaurant, a train station, a plane, or a public park, enabling client isolation and disallowing broadcast packets should be a no-brainer. There are little to no reason why two clients on the same public WiFi should be interacting with each other for the expected usage of these types of network. (No, sorry, you developing the firmware for a new device at a cafe and wanting to be able to access it from your laptop is not an expected usage, if it works it works but don’t expect it to!)
The situation becomes more complicated for hotels: many hotels make Chromecasts available to their guests, others still allow guests to bring their own similar device. For these devices to work you need to be able to discover them on the network, which effectively requires mDNS and other broadcast packets being correctly routed.
One common tradeoff to handle this is to use limited-power access points in each room, and only allow broadcasting within the access point’s connections. This does not even require separate network address space, as the “easy” solution is for the access point never to forward those packets to its upstream. Unfortunately this has the drawback of making the cast finnicky, since it is possible for the Chromecast and phone to end up connected to different access points. Plus it’s a lot more expensive than having a few high-power long-range access points, particularly for smaller hotels.
You could do better, though: you could use separate networks for each room. This scales a little better for smaller hotels with a dozen or so rooms, but it comes with its own drawbacks: devices on different networks would be able to avoid collisions, and while having long range access points with multiple networks is indeed an option, those tend to be more expensive than a handful of uncoordinated access points.
Separate networks also create more problems and more tradeoffs to be evaluated: if each room is assigned a static password, repeated guests risk connecting to the wrong room (if you don’t believe repeated guests in specific hotels you still haven’t traveled for business enough — I’ve been repeatedly upgraded to the same room when visiting Mountain View), and if the password is easily guessable… I’ll get to that in a second.
Big chain hotels usually connect their WiFi with their guest management system, which is where the reservation details are held, though not all of the times. The cynical view of this is that the hotel can charge you extra for having an Internet connection, particularly true in Europe and North America (in Hong Kong our hotel not only didn’t charge for Internet, they even provided a convenient pocket WiFi router since you can no longer easily get local SIMs) but there are less user hostile reasons to do so.
For instance, you could assign each device to a reservation-specific VLAN: if I say I’m Flameeyes staying in room 752 on each of my devices, they all see each other, and my room’s Chromecast can be attached to the same network for me to cast to. This is not particularly secure of course, since one only needs to overhear someone else’s name and room number at reception to be able to connect to that very same VLAN, but it is at least a more user friendly improvement.
I noted above that ideally, if using separate networks per room, you shouldn’t have easily guessable passwords (as in, passwords that are directly derivable from the room number), and at the same time you shouldn’t leave all Chromecasts visible on the same flat network. And the reason for that is that, by default, Chromcast and similar devices trust anyone on their own network.
This means that, as a matter of fact, you could start playing anything on a Chromecast in a different room at any time, wittingly or not. Saying that this is prone to abuse feels like a British understatement: you can go from the benevolent trolling of playing Baby Shark at 10am in your friends’ room to entertain their kid, to the harassment of playing porn or gore in the middle of the night in a random room of the hotel.
This is not particularly new: most hotels have in-room phones that you can freely and independently call from any other room, and I have had to disconnect mine from the room once when a busload of school kids decided to start pranking random rooms. But in that case, besides the non-minor annoyance of being woken up in the middle of the night I didn’t have to deal with shock horror or triggering trauma.
But, if you believe that there can be any technology that cannot be abused by a malicious attacker, have another think after this.
Going back to worries that are closer to home to the average FLOSS/network geek who don’t think so much about abuse, let’s leave the big hotels aside, and let’s think for a moment about small scale hotels (or B&Bs) and restaurants: these often don’t have a guest management system, and I’m aware of a number of them pretty much running their WiFi on a standard router, acquired either at the electronics shop or maybe provided by the ISP, with no hardening to be used for providing access to untrusted devices. I have more than once found the router’s admin password not to have been changed from the default.
In these situations the more worrisome part is if the computers and devices used by the business are not correctly segregated from the guests’. While payment and guest management systems using WiFi (of which there are plenty) are usually installed by MSPs that know to set up separate WiFi networks, I have been in more than one B&B where the “management system” is literally a computer with a shared drive. I don’t trust that security for sure.
Of course, as a techie, I would want to be able to say that we can build a technical solution covering all of the problems, and with my Free Software enthusiast hat, I would love to be able to say that we can build an open source solution that is better than any of the current existing proprietary solutions! But I don’t think I can say that.
Apple could change their ways and default to volunteer fewer information about an user by default. I understand it feels polished to be able to show the icon of the specific model the user is using, but to be able to do so the model itself is broadcasted to the network. But I’m not holding my breath on that happening.
Plus there is always going to be an extremely long tail of devices that you won’t be able to update and fix. The only real solution in my view can be one that makes it harder to set up an insecure network.
The first problem is that, as noted above, the problem with hotels WiFi can only be fully solved with the help of the guest management system. And that industry is not easily disrupted, since doing so would require not just a significant capital investment, but also a lot of necessarily niche knowledge. Interdisciplinary development strikes again.
If you don’t believe me, remember that Google tried disrupting the Passenger Services industry, which is dominated by the effective duopoly of SABRE and Amadeus, and ended up giving up and running away after a single customer.
Obviously, it’s hard for me to judge exactly what is going on in that industry, since I’m not in it, but I can at least look at it as a customer and notice that, in the year 2023, IHG still has a 4-digits PIN, and only a handful of hotels in the Marriott program support MobileKey (and it’s so slow that it’s generally not worth using.)
In particular my feeling is that Starwood, before being acquired by Marriott, was at the forefront of improving the technology powering their business, and while Marriott inherited the vast majority of the improvements, I have not seen much in terms of improvements ever since.
(Necessary disclosure here, I hold stock of Accor Hotel Group. I bought it because it was a handy way to get gold frequent guest status with them, which has since lapsed, but given the losses due to pandemic, I’m holding hoping to a recovery.)
Which is far from surprising: “normal” people don’t choose their hotels based on the technology behind them, but rather on price, location, and amenities. The usual haunt I referred to above for my trips to headquarters? A Holiday Inn Express, one of the most bare bone hotels in the area, but a clean one, at a walkable distance to both the shuttle bus stop and multiple dinner options. WiFi worked, which was obviously neat, but I was probably prioritizing the 24/7 free coffee sludge at reception. (Don’t judge, when traveling intercontinentally I need to keep awake!)
Public WiFi services that don’t need isolated VLANs are likely an easier target for a skunkworks project to address. Unfortunately here you are competing not just with established players, but with business models that, to the average FLOSS developer, would sound sketchy if not unethical.
While I do note that this is a lot more common in the States and UK compared to, say, Italy or Spain, a large number of restaurants and bars contract out their customers WiFi solution to companies that handle it “full service”: the business might or might not have to provide the actual Internet drop, but otherwise the third party handles setting up the hardware, and the portal for registering.
This particular business arrangement tends to be driven by, among other things, the ability of restaurant owners to increase the sign ups to their marketing mailing lists. How often have you found the checkbox to sign up for communications already checked, or markedly similar with the acceptance of the terms of use? There you go. One day I should shed some light on how email addresses are used for remarketing via hashed lists, but that’s for another time.
Technically speaking, in Italy these portals are also meant to confirm your identity, either by tying it verifiably to a phone number, or to an identity document, since anonymous Internet connections are illegal. Which possibly makes me even more worried about the lack of security in those offerings.
So why do I not believe we can do much better with open source tooling? Well, the reason is that I can’t seem to find any stream of work to make it possible to scale this type of deployments with either purely FLOSS or open-core systems.
It looks like the state of the art for this type of work is UniFi, which, while being based around Linux and a number of open source software, has a definitely proprietary management solution. In terms of FLOSS solutions, I hear that OpenWRT is still the best in class.
But OpenWRT has, in my experience, never moved on from the idea of glueing together a number of small C daemons with a bunch of shell scripts, because that’s the way it used to be done back in the days. Even the services they ended up writing ground up (like odhcpd) end up using complicated parsers in C to keep configs in a way that can be parsed and tweaked with shell.
What I feel would be needed for this type of deployments to scale more easily is to either agree on a common interchange schema and format for the various daemons to consume, or build “adapters” that can generate and produce the required formats from a common configuration option.
Pretty much what UniFi does, but with a common, open source, possibly standardized interface. That is not SNMP.
After all, we kind of got this nowadays (for monitoring) with Prometheus, that definitely went further than Munin could have, in terms of providing a clearly defined format for metrics export (although I would love for these metrics to be exported without the need of a separate scraping node per service!)
And, I mean, I kind of wrote that type of software in High School as my graduation project: it was for a specific, proprietary operating system of a D-Link router, but it still achieved the ability to manage the basics of the router with a completely local UI.
But I’m afraid at this point the open source networking gear development has peaked at the PiHole, as I can’t see people who scream louder and louder that IPv4 is “legacy” would care to build something for people who don’t want to care about networking.
