@SkewedZeppelin I’m currently setting up ufw and on the Arch Wiki, it says that a basic config includes allowing any protocol from 192.168.0.1-192.168.0.255 on LAN. Is this advisable?
Are you really sure every single TCP and UDP connection that your device makes while on public wifi is using an up-to-date protocol with strong transport encryption like HTTPS and every client application is sufficiently checking certificate validity? Technically most of it should be kinda secure, it’s not like you definitely get immediately hacked, but why leave things up for chance?
Just from the top of my head, I guess NTP is trivial to MitM, which an attacker could use to change my system time, which then could lead to further issues, like accepting invalid security certificates. Or, even if not directly security-relevant, apt etc. is generally over HTTP and only integrity is checked. Leaks some data about which programs I might be running. Then of course the most obvious one, DNS53. Spoofing DNS should ideally only lead to connection errors, but maybe I click on the wrong button and accept a bad cert? I always try to be vigilant but it’s better to have more layers of defense than just a single button. And I could go on, XMPP, IRC, whatever, a single program you’re running where some config is not set up for optimal hardened security, and you’re potentially screwed.
Just running a VPN solves almost all of these problems. That doesn’t mean now that you have a VPN you should be less attentive to any potential issues, and defense in depth still makes a ton of sense (post above me lists a lot of good stuff, so I’m not going to repeat that), but chances are if somebody is doing some fishy things with public wifi, they’re going to go for other targets.
ChromeOS and GrapheneOS have authenticated time.
Brace also does this too for Chrony (thanks to GOS).
Still on the fence how to best add that for DivestOS.
Brace handles this too for RPM repos.
Encrypted DNS prevents this.
XMPP has mandated encryption for years, no sane client will downgrade it.
No it doesn’t, it just lets your VPN monitor the same stuff.
You should still address these regardless of provider.
2 Likes
Which is exactly what I also said in my post. Ok let me rephrase that to be a little bit more clear: “running a VPN solves these problems with regards to the public wifi provider”. Why do we pretend like nobody understands how a VPN works? Yes, obviously the VPN provider now technically has the ability to monitor your traffic and change/shape it when technically feasible.
And good for pointing out that there are solutions, I’m not saying there aren’t. I’m just saying that your average desktop PC is going to run lots of different stuff, not everybody out there is always paying 100% attention to every little service’s configuration. I was thinking of some examples to make it clear that it’s not just HTTP vs HTTPS all the time. Good to know that XMPP should generally be safe.
With a VPN provider (or also really it could be a VPN at your home, from your university, work w/e you trust the most or think gives you the best access to the internet) you simply have more opportunity to vet them than every random cafe shop you stop at. I’m not against securing all your services/applications as far as that’s possible, but let’s put it like this: you’re less likely to get mugged strolling through a nice neighborhood. It would still be wise to take precautions and not be careless.
@SkewedZeppelin nice photo, but:
- what it is? (looks like multiple 747’s)
- what this have to do with current topic?