Item — HN Reader

Almost every question on the quiz is misleading.

> 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.

3 comments

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 ?

If a device isn't well-configured, then it's unsafe even if it's not on public Wi-Fi. All of the security focus should be on the endpoints themselves.

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.

Based on your quiz results(https://lolwifi.network/quiz/58efbbca-9b4d-4825-adb7-0e98133...) , I notice you acknowledged:

  - 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.

The page after completing the quiz is even worse:

> 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.