The curious case of the Raspberry Pi in the network closet (2019)

I used to live in an apartment that was within high gain antenna range of the local McDonalds Free WiFi. I had a antenna/wifi adaptor set up in promiscuous mode to listen to all traffic on their network, looking for MAC addresses that connected for a while, then stopped connecting. It'd then switch to that MAC address and BitTorrent until the 500MB daily cap per device ran out, then go back to monitoring mode looking for someone else who'd agreed to the captive portal T&Cs had their MAC address whitelisted and then left. I think I got pretty much all of Game Of Thrones that way...

For a little while, I was monitoring my own home network, and one thing I tried was running map against any reconnection of a known/allowed MAC address, to try and confirm it at least looked like the same device. A RaspberryPi connecting using the MAC address of a phone or a MacBook stood out like a sore thumb. That never turned out useful enough for me to bother wrapping it up into a project I kept running or would have shared.

Of course, but there should at least be a mention of the fact that you need to tune the fail-closed parameters to take your availability into consideration. I appreciate that the various attacks would have to be done "pretty quick" according to the FAQ but the definition of "pretty quick" is necessarily countered by what kind of guarantees you can make about your availability (of the server(s) and the client), and this isn't mentioned. If a 30 second network failure causes the server to refuse keys to the client from that point on, but you can't guarantee that level of network availability (taking into account things like replacement of network switches and other types of maintenance), the definition of "pretty quick" may be too quick. It's a very direct and explicit tradeoff between security and availability and that concept is absent from the intro/FAQ. As a mental exercise, consider how you'd answer the FAQ "So I should set my timeouts super low for better security?"

Again, I'm not trying to be a picky ass, and I think the project is cool. I just think this is a topic that non-security-folks don't necessarily think about automatically, and this is the opportunity to make them think about it. The entire doc sounds like "faster timeout == better" and it would be very unfortunate for someone to configure and deploy this based on that understanding.

PS your other responses to my nitpicks were great, and somehow I missed the entry about stealing the client key being possible but having to be done very quickly. Thumbs up. I'm curious about what you mean by saying you aren't using "x509 keys" though. You must be generating a self-signed x509 cert containing the client's pubkey in order to do TLS. The packaging of the key itself isn't really relevant, is it? The "cert validation" on either side doesn't really care much about the contents of the cert other than the pubkey encoded therein, but you still do actually have to create x509 certs using those keys unless you've completely butchered the TLS stack. Right?

I have something that sends me an occasional email. I haven't needed it in years, but it's not in any of the AWS regions I remember ever using. Nor in the obvious places I might have put it playing around with azure or google cloud or whatever. I'm sure I could find it if I really tried but t only emails me once or twice a year so I just let it be.

And what did the employees do with the information? Leave the building?