I submitted a vulnerability to Bugcrowd. Out of Scope. I published on my blog. I pointed out it was actually in scope. They acknowledged they'd made a mistake. I took the post down voluntarily. They followed up with a threat anyway. I told them to fuck off. They offered a payment to make it right. Then silence. very funny.
Hacklore, WiFi thoughts ... If I had to boil it down, I'd say they're thinking like cyber security engineers instead of information security officers and even then all they've done is mask nuanced conversations with foundational advice that has been known for years, well done you've replaced interesting conversations with advice older than the devices in question.
this was the precursor to lowlife.network but I just hadn't gotten round to publishing
What Bob and the signatories fail to recognise is that they're attempting to swap out nuanced advice for foundational advice and they're patting themselves on the back for it, actually. that foundational advice has always been
the nuanced advice is for unsolved problems, so ... if you ask a nuanced question, you'll be ... directed back to foundational security advice ?
I don't think they've thought about it, perhaps Signatories shouldn't play risk-advice cosplay at population levels.
I'd be annoyed if this influenced policy because of who they are and not how dumb the logic is.
CSP Header Analysis: Scans websites for Content Security Policy headers
Domain Extraction: Identifies all external domains trusted by CSP policies
Availability Checking: Uses AWS Route53 to check if trusted domains are available for registration
PublicWWW Research: Discovers how available domains are used across the web (optional)
Bug Bounty Reports: Auto-generates professional security reports
High-Performance Scanning: Beast mode with 1000 DNS concurrency
Resume Capability: Continue interrupted scans with wordlist tracking
Automatic Organisation: Scan results organised into hot/archive folders
Bonus Intelligence
Typosquatting Discovery: DNS enumeration naturally uncovers typosquatted domains that resolve but weren't registered by the target
Identifies potential phishing domains
Reveals trademark infringement
Discovers forgotten test/staging domains
Exposes defensive registrations that need monitoring
Using AWS availability checker has some limitations (not full tld support) but it's 100% cheaper than performing a whois lookup
well, the good news is, that the attacker (should there be one) has to be either on the same flight, or have pesistence (bi-directional entry) into that infrastructure
that's a good edge case for not using a hotspot, but at the same time, i've never been on a flight with 'good' internet, but the main question, what to tell the general population about joining untrusted networks, now, you get thousands of feet in the air, you might think it's a tolerable risk to join sleazyJetFreeWiFi, and I would agree, it's unlikely that it's an evil-twin attack, but coming back to giving population level advice, is this kind of nuance useful ? or just fun
- TLS only protects application-layer data (Q1) - doesn't cover layers 2-6
- Client isolation cannot be verified before joining (Q2)
- ARP spoofing, DNS manipulation, port scanning, certificate solicitation, MAC collection, and traffic analysis are all possible attacks (Q6)
- Personal computers lack defense-in-depth (Q8)
But then concluded: "Public WiFi is safe for everyone" (Q10).
Your HN comment says "there's nothing preventing me from securely using public wifi" - but you haven't explained how. This is the
issue: vague, hand-wavey claims without materialistic explanation(s).
What specific protections are you using?
You acknowledged these malicious behaviours in Q6:
- ARP spoofing
- DNS manipulation
- Port scanning
- Certificate solicitation
- MAC collection
- Traffic analysis
You claim HTTPS makes it safe, but you didn't explain:
- How HTTPS prevents ARP poisoning (it doesn't - this happens at Layer 2)
- How HTTPS prevents port scanning of your device (it doesn't - attackers scan your listening services directly)
- How HTTPS prevents DNS manipulation when 80% of users don't use DoH/DoT
- How HTTPS prevents SNI leakage when ECH adoption is <5%
- What specific mitigations you've deployed against the network service exploitation you acknowledged
TLS operates at layers 5-7. The attacks you listed in Q6 happen at layers 2-4. Your HTTPS traffic is irrelevant to these attacks.
The quiz asked about everyone, not just you:
This isn't about how well you've personally secured your device. It's about whether the general public should be told "public WiFi is safe because HTTPS."
Most people:
- Don't know what services are listening on their network interfaces
- Are running unpatched software (Q8: personal computers lack defense-in-depth)
- Aren't using DoH/DoT
- Aren't aware SNI is unencrypted
- and the rest
If you're going to have a good conversation about this you need to provide better, more specific explanations - not just "HTTPS makes it safe." What exact technical controls are you deploying? What does the average person need to configure to achieve your level of protection?
Without specifics,it's all a bit hand-wavey.
> You claim HTTPS makes it safe, but you didn't explain:
> - How HTTPS prevents ARP poisoning (it doesn't - this happens at Layer 2)
HTTPS doesn't need to prevent ARP poisoning itself, because if you try to MITM my connection with it, HTTPS will prevent that, and if you don't, then ARP spoofing hasn't accomplished anything.
> - How HTTPS prevents port scanning of your device (it doesn't - attackers scan your listening services directly)
Firewalls protect you from that.
> - How HTTPS prevents DNS manipulation when 80% of users don't use DoH/DoT
Exact same answer as for ARP spoofing.
> - How HTTPS prevents SNI leakage when ECH adoption is <5%
SNI leakage happens over the Internet in cleartext even with mobile hotspots. What does this have to do with public Wi-Fi?
> - What specific mitigations you've deployed against the network service exploitation you acknowledged
Which things specifically do you mean by "network service exploitation" that I haven't already covered?
> TLS operates at layers 5-7. The attacks you listed in Q6 happen at layers 2-4. Your HTTPS traffic is irrelevant to these attacks.
See my responses above.
> The quiz asked about everyone, not just you:
> This isn't about how well you've personally secured your device. It's about whether the general public should be told "public WiFi is safe because HTTPS."
Nothing I answered was about my specific devices. Everything I've said is about how mainstream devices work out-of-the-box today.
> Most people:
> - Don't know what services are listening on their network interfaces
Mainstream devices are configured out-of-the-box with deny-by-default firewalls.
> - Are running unpatched software (Q8: personal computers lack defense-in-depth)
Mainstream devices are configured out-of-the-box with automatic updates.
> - Aren't using DoH/DoT
> - Aren't aware SNI is unencrypted
> - and the rest
Again, that happens over the Internet in cleartext even with mobile hotspots. What does this have to do with public Wi-Fi?
> What exact technical controls are you deploying? What does the average person need to configure to achieve your level of protection?
Nothing, assuming usage of a modern mainstream Windows/macOS/Linux/iOS/Android device.
Hey josephcsible, thanks for the reply, i think you can share your answer UUID and we can see all this (I think this is you, https://lolwifi.network/quiz/58efbbca-9b4d-4825-adb7-0e98133...) you've mentioned a well-configured device, the point the site is leading too isn't 'can a well configured device survive on a hostile network' but 'do you think it's reasonable for all devices (old, new, basic, lowered, highered posture) to join an untrusted network?' and if so why ?
are you suggesting that an insecure laptop connected to the owners mobile hotspot is somehow carrying the same level of risk as an insecure laptop connected to an untrusted wireless network Josheph ? ... come on lad.
Why is that so far-fetched? If your laptop is behind on security updates, a malicious website you visit could pwn you through a browser exploit, no matter how you have it connected to the Internet.
I don't think you understand Joseph, the attacks I'm mostley speaking too are happening on the Local network the WiFi, not outbound TLS connections, do you get this ?
Those ones are generally blocked by basic firewalls that have been enabled by default since Windows XP SP2, which is now over 21 years old. And devices running software older than that are in practice cut off from the Internet anyway, since pretty much every website these days has a minimum TLS version requirement of newer than the newest available back then. And my outbound example was meant to show how you would still be vulnerable even going through a mobile hotspot.
Author here. After seeing "TLS makes WiFi safe" repeated endlessly, I built this to walk through a broader thinking distance.
The /quiz version tracks contradictions in responses (surprisingly common, even among technical users). The /conversation format
is for people who just want the technical explanation without the assessment.
Happy to discuss specific scenarios or threat models, but there are some principles that just wont change, do you know what they are ?
