Wandering Thoughts archives

A wifi MAC address randomization surprise in a new Android gadget

I recently picked up a new Android-based gadget and discovered, to my unpleasant surprise, that it has what I can best describe as "unusually aggressive" wireless MAC address randomization. The most basic form of MAC randomization is to randomize the MAC address that you use before you're connected to a wireless network, which prevents people from re-identifying your device as you move around. To be more thorough you can then use a different MAC per wireless network (SSID), so that people can't easily associate you across different wireless networks. A really aggressive setting is to use a different random MAC every time you connect again to a known network; this keeps the network from tracking you across time.

(This article gives the example of airport wifi as a time where you might want to use a different random MAC on every connection. In general, any public wifi is probably a good usage case for that. See also this and the Arch wiki.)

This particular Android gadget is even more aggressive than this. Not only does it use a random MAC address, it changes the address on a regular basis and does so even when connected to a wireless network and holding a DHCP lease. In fact I have DHCP logs showing it attempting to preemptively renew a non-expired DHCP lease using a different MAC address than it used to get the lease (this doesn't go well, since as far as the DHCP server is concerned the IP address is taken by someone else). The vendor's support documentation links to this Android 9 developer page on MAC randomization, but that seems to only be talking about stable per-SSID MAC address randomization, not this sort of random and actively changing MAC address.

This aggressive randomization is also potentially pointless, because as part of its DHCP requests the gadget broadcasts a DHCP host name of 'android-<some fixed hex digits>'. If this is unique per device, it's an easy tracking identifier, and even if not it may be more tracking than you'd like. This particular gadget also only talks to wireless networks that you specifically tell it to, and generally those are going to be high-trust ones; aggressive address randomization for your home wireless network seems somewhere between pointless and problematic (if it causes issues like DHCP pool exhaustion as the gadget churns through DHCP leases).

(Sadly this really is a DHCP host name, not a DHCP client identifier. The normal ISC DHCP server can assign static IPs to the latter but not the former.)

As a sysadmin, I hope that this sort of very aggressive MAC address randomization doesn't become common among Android devices. Our departmental wireless network mostly requires stable MAC addresses, and on top of that we only have so many free DHCP leases (although we could expand the pool, since we're using a /16 for the network as a whole). Android devices that change their MAC all the time would give our people a fair amount of heartburn, and there's not much we can do about it without a major change in our wireless architecture (which is unlikely).

(Registering a stable MAC is optional on our wireless network, but if your device doesn't have a registered one, the only thing it's allowed to talk to is our VPN servers. Registered devices can talk to the outside world too.)

PS: This particular gadget uses Android as a substrate; it runs custom software on custom hardware, and the fact that it's running on top of Android is barely mentioned in the documentation and mostly only discoverable through things like network scanning or finding out that it supports USB MTP. At first its use of Android surprised me, but then I realized that Android has become a perfectly respectable embedded OS and there's a wide ecology of people who make Android-capable hardware and peripherals that will connect to it.

(This elaborates on some grumpy Tweets of mine.)

Allowing some Alias directives to override global Redirects in Apache

When I wrote Apache, Let's Encrypt, and site-wide reverse proxies and HTTP redirections, I confidently asserted that there was no way to override a Redirect for just some URLs, so that you could Alias the /.well-known/acme-challenge/ URL path off to somewhere while still redirecting the entire site to somewhere else. It turns out that there is a way of doing this under some circumstances, and these circumstances are useful for common Let's Encrypt configurations.

The magic trick is that if you put your Redirect directive inside a <Directory> directive, it only applies to URLs that resolve to paths inside that directory hierarchy. URLs that resolve to elsewhere, for example because they have been remapped by an Alias, are not affected and are passed through unaffected. This is extremely useful because in common configurations for Let's Encrypt clients, the challenge directory is often mapped to a common outside location in the filesystem, such as /var/run/acme/acme-challenge. So, for a virtual host you can set a DocumentRoot to some suitable spot that's not used for anything else and then wrap the site-wide redirect inside a <Directory> directive for your DocumentRoot, like this:

DocumentRoot /some/stub

<Directory /some/stub>
  Redirect permanent / https://..../
</Directory>

(It seems common to supply the Alias and <Directory> directives for the Let's Encrypt stuff in a general configuration snippet that's applied to all virtual hosts. Doing this globally is one reason to make them all go to a common spot in the filesystem.)

The stub DocumentRoot probably has to exist (and have permissions that allow Apache access), but it doesn't have to have anything useful in it. It's there purely to confine the Redirect away from the Alias.

(I stumbled over this trick somewhere on the Internet, but I can't find where any more.)

PS: I don't think you need to specify any AllowOverride or Options settings in your <Directory>, because they're all surplus if you're not doing anything with the stub directory tree except the Redirect. Our <Directory> sections tend to have these even when the entire site is being proxied or redirected, but that's because we're creatures of habit here.