If you think you have all the words filled in properly but nothing is happening, hint: base64(VGhlIGNvcnJlY3QgdHJhbnNsYXRpb24gb2YgdGhlIGFsaWVuIHdvcmQgImN2aXF6dnhxIiBpcyBub3QgIm5ld2hhcnQiLg==), and spoiler: base64(SXQncyAiZXZlcnN0cm9uZyIu). I suspect there may be a bug in the game that it uses the wrong message at one point.
Because if you're on the kind of malicious network that's the reason to use encrypted DNS at all, then your connection attempts on port 853 will probably just get blocked wholesale. DoH is better since it looks the same as all other HTTPS traffic.
And you can still block ad and scam domains with DoH. Either do so with a browser extension, in your hosts file, or with a local resolver that does the filtering and then uses DoH to the upstream for any that it doesn't block.
> And you can still block ad and scam domains with DoH.
How?
There are certain browsers that ignore your DNS settings and talk directly to DoH servers. How could I check what is that the browser requesting through a SSL session?
Do you want me to spoof a cert and put it on a MITM node?
These are my nameservers:
nameserver 10.10.10.65
nameserver 10.10.10.66
If the browser plays along than talking to these is the safest bet for me because it runs AdGuardHome and removes any ad or malicious (these are interchangable terms) content by returning 0.0.0.0 for those queries. I use DoT as uplink so the ISP cannot look into my traffic and I use http->https upgrades for everything.
For me DoH makes it harder to filter the internet.
There are a plethora of ways to control whether the browser uses its own DoH or the system DNS. Some inside the browser itself, some in the machine's OS, and some from the local network.
You can also configure the browser to use your chosen DoH server directly, but this is often as much work as just telling the browser to use the system DNS server and setting that up as DoH anyways.
tl;dr: starting with Firefox 145, instead of there being a shortcut to it on your desktop, it will drop a .exe file there, so that if your desktop gets copied to a new computer, it can automatically reinstall Firefox instead of just being a broken shortcut.
> 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.
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.
- 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.
> 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.
> > Regularly change passwords: Frequent password changes were once common advice, but there is no evidence it reduces crime, and it often leads to weaker passwords and reuse across accounts.
> When I worked as a security professional the breaches were nearly always from someone's password getting leaked in a separate public breach. If those individuals had changed that password the in house breach would have been avoided.
You completely missed the point. The good advice is to not reuse passwords. That alone would have stopped the in house breach.
> Looking closer at the Steam Machine's specs, one will see that the HDMI 2.0 port delivers up to 4K/120Hz and supports HDR, FreeSync, and CEC. Those are all HDMI 2.1 specs — which technically means the Steam PC is HDMI 2.1-compatible. The only reason the new hardware can't boast the official 2.1 classification is that the HDMI Forum will not allow HDMI 2.1 on Linux devices, the OS that powers all Steam hardware.
(emphasis mine)
Microsoft is a member of the HDMI Forum. In a just world, those two things together would be grounds for legal action.
> But today, couldn't we just open up a mount namespace and bind-mount something else to /tmp, like SystemDs private tempdirs?
No, because unless you're already root (in which case you wouldn't have needed the binary with the capability in the first place), you can't make a mount namespace without also making a user namespace, and the counterproductive risk-averse craziness has led to removing unprivileged users' ability to make user namespaces.
It's probably true that there are setuid programs that can be exploited if you run them in a user namespace. You probably need to remove setuid (and setgid) as Plan9 did in order to do this.
reply