"But HTTPS encrypts everything" – A WiFi security conversation
lolwifi.network
lolwifi.network
> Does TLS protect all protocols from layer 2 to layer 7, prior to using something that enjoys TLS?
The right answer is "no", but this unnecessarily scares people, since everything important that needs to be protected still is.
> How do you verify that client isolation is enabled on an Untrusted (Public) WiFi network before joining?
You can't, but that's not something you need to verify or worry about.
> Where do you draw your confidence from that an Untrusted (Public) WiFi network is suitably configured, managed and secure before joining it?
This makes it sound like you need such confidence, when in fact, it's only the endpoints (your device, and whatever server you're connecting to) that need to be suitably configured, managed and secure. If they are, the network could be actively hostile and you're no worse off than if you were just offline.
> On an Untrusted (Public) WiFi network without client isolation, can one client directly attack another client's device?
If such attacks are cause for concern, then the real reason is the vulnerability on your device that it's exploiting, not the network not being isolated.
> Can the average user detect if their device is being attacked on an Untrusted (Public) WiFi network?
The average user can't detect that under any circumstances, but this question unfairly makes it sound like there's some characteristic of public WiFi that makes them not able to detect it.
> Select all attacks that can occur on Untrusted (Public) WiFi:
> ARP spoofing
Harmless due to TLS.
> DNS manipulation
Ditto.
> Port scanning of your device
If you have dangerous ports open on your device, that's a "your device" problem, not a "public WiFi" problem.
> Certificate solicitation via captive portal
Is this a made-up term? I can find zero references to certificate solicitation attacks.
> MAC address collection
Modern devices randomize their MAC address for each new network they connect to.
> Traffic timing and volume analysis
That's a thing you can do, but how is it an "attack"?
> Certificate pinning can prevent Attacker-in-the-Middle (AITM) attacks for TLS/HTTPS connections. Does certificate pinning protect your device's protocols and services that do not use certificate pinning?
Regular CA verification already prevents MITM attacks. The only thing certificate pinning does is make it harder for you to legitimately inspect your own apps' traffic.
> Do most personal computers have the same security controls as corporate managed devices (hardened OS builds, EDR, MDM, DLP, defense in depth)?
DLP, etc. is security against the user, so it's a good thing that personal devices don't have such things.
> What percentage of Untrusted (Public) WiFi networks do you estimate undergo regular security audits and penetration testing?
Again, it doesn't matter, since a well-configured device would be fine even on an actively malicious network.
- 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.> - 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.
> Technical Knowledge 9/8
> Consistency 1/5
> Risk Awareness 0/10
> Contradictions Identified:
> You acknowledged TLS does not protect the join phase, yet cite TLS as your primary safety reasoning
Not a contradiction. It doesn't matter that the join phase isn't protected.
> You acknowledged personal computers lack the defense in depth of corporate devices, yet advise the general public that Untrusted (Public) WiFi is safe for their personal devices
Not a contradiction, because the "defense in depth" of corporate devices isn't why public WiFi is safe for them.
> You demonstrated strong understanding of technical risks, yet advise the general public that Untrusted (Public) WiFi is safe
> Cognitive Biases Detected:
> Your responses reveal patterns of reasoning that may interfere with objective risk assessment:
Not everyone who disagrees with you is cognitively biased.
> Expertise Bias high
> You demonstrate strong technical understanding of the risks, yet advise the general public it's safe. This suggests you may be projecting your own technical capability onto others who lack your knowledge and tools to protect themselves.
No, it's because modern devices are secure against these kinds of attacks out of the box.
> Sunken Cost Fallacy high
> You understand the technical risks yet continue using public WiFi regularly and recommend it to others. This pattern suggests 'I've been doing it this way for years, so it must be okay' reasoning rather than objective risk assessment.
No, it's okay for the technical reasons I explain in the rest of this post.
> TLS Scope Misunderstanding high
> You correctly acknowledged that TLS does not protect the join phase or lower-layer attacks, yet you cite TLS as making public WiFi safe. This indicates a fundamental disconnect between your technical knowledge and your safety reasoning.
No, it's because attacks on those layers won't harm users, because everything important where they could be harmed is on the higher layers that TLS does protect.
> Assessment Capability Disconnect high
> You acknowledged that you cannot assess a network's security configuration before joining it, yet you advise the general public it's safe. How can something be 'safe' if you cannot assess whether it's configured securely?
Because it's safe for my device no matter how it's configured, since my device doesn't need to trust it to use it.
> Understanding the Tensions
> When technical knowledge and public advice diverge, it may reflect underlying tensions between competing priorities. These are common conflicts that many security professionals navigate:
> Technical Understanding vs. Professional Identity
> The Tension: You understand the technical risks, but acknowledging them publicly might undermine your professional reputation based on historical commitments to the perceived status quo of "WiFi is fine."
> May contribute to: Expertise Bias, Sunken Cost Fallacy
No, it's that you're way overblowing the technical risks. When a bunch of experts who understand the technical risks say it's okay, maybe you should step back and consider that you might be wrong, instead of throwing a list of cognitive biases at everyone who disagrees with you.
> Objective Risk Assessment vs. Personal Convenience
> The Tension: Balancing security assessment with practical convenience and personal usage patterns.
> May contribute to: Convenience Over Security, Optimism Bias
None of the quiz answers had anything to do with convenience.
> Enterprise Security Standards vs. Public Advice
> The Tension: Navigating different risk tolerances between corporate managed devices and consumer devices without enterprise controls.
> May contribute to: False Equivalence, Contradictory Risk Tolerance
As I said earlier, the enterprise controls aren't necessary for public WiFi to be safe.
> Evidence-Based Reasoning vs. Absence of Visible Harm
> The Tension: Assessing risks when direct evidence is limited and passive surveillance is undetectable.
> May contribute to: Availability Bias, Assessment Capability Disconnect
So since there's no evidence for your position, we should just assume you're right?
> Defense in Depth Philosophy vs. "TLS Solves Everything"
> The Tension: Weighing the scope of TLS protection against comprehensive network-layer security concerns.
> May contribute to: TLS Scope Misunderstanding
TLS doesn't protect literally everything, but it protects everything that's actually important for users to be able to use public networks safely.
> Resolution
> These biases resolve when you align your advice with your technical knowledge. The simplest consistent position:
Again, people disagreeing with you is not a bias!
> "If you can use a mobile hotspot, it's safer than public WiFi."
> This advice:
> Matches what corporations require for managed devices
Plenty of corporations don't require this.
> Acknowledges join-phase risks that TLS cannot mitigate
But these aren't actually problems.
> Doesn't require users to assess network security they cannot verify
Public Wi-Fi already doesn't, as I explained earlier.
> Provides a practical alternative that's readily available
Mobile hotspots are very expensive compared to public Wi-Fi.
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
gg
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.