Untitled attachment

Notices where this attachment appears

1. Embed this notice
   Mr Penguin (mr_penguin@social.freetalklive.com)'s status on Thursday, 13-Aug-2026 06:07:51 JST Mr Penguin

   "On Monday, passengers aboard Delta flight 591 going from Las Vegas to Atlanta allegedly spoofed the onboard Wi-Fi, raising the attention of federal law enforcement."

   Entertaining comment was made in regards to the spoofing story:

   "This has always been a thing and maybe we need SSL for WiFi. Let's get Let's Encrypt on the case and Apple and Google throwing up big scary "Do you trust this Wifi?" for all non-certified Wifi hotspots and slap on a Certified label."

   The part that is interesting is that you could do this for wifi even if the network were offline. So you would have to ensure your captive portal is pointing to the fullchain.pem file, not just the cert.pem file (or you may otherwise be able to poke holes). Then your local router can issue DNS for the domain. Since the captive portal provides the full chain pem file and the browser has the root certificate you can confirm your accessing the real offline router.

   If you connect to a fake hotspot when asked to login the browser will throw an error about the domain domain ssl certificate not matching for the captive portal. The issue then becomes has the attacker created a fake hotspot and also created a decoy domain for the login (ie att.io instead of att.net or something similar).

   If they have the user could be fooled unless users are made aware that they need to verify the domain is legit that they're logging into. Of course how does one do that?

   I could envision a decentralized Web of Trust for domain names.

   So chain of trust validation works by tracing these signatures: if you trust a user (e.g., Alice), and Alice has signed another user’s key (e.g., Bob), you can infer that Bob’s key is valid.

   You have no chain of trust for att.io, so browser blocks it. You would for att.net.