this post was submitted on 06 Oct 2024
725 points (91.0% liked)
Technology
58550 readers
4432 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What is he talking about, public WiFi can easily poison and monitor your DNS requests (most people don't know or use encrypted DNS), and there's still tons of non-https traffic leaks all over the place that are plain text. Even if encrypted, there's still deep packet inspection. VPNs can mitigate DPI techniques and shift the trust from an easily snoopable public WiFi to the VPN's more trustworthy exit servers.
This guy really needs to elaborate on what he's trying to say when the cyber security field very much disagrees with this stance. I'm not a huge fan of Proton, but they aren't doing anything wrong here. You should use it for public Wi-Fi.
Yup. You can grab any unencrypted data passed between the user's browser and a server literally out of thin air when they're connected to an open access point. You sit happily at the Starbucks with your laptop, sniffing them WiFi packets and grabbing things off of them.
Oh and you have no idea what the myriad of apps you're using are connecting to and whether that endpoint is encrypted. Do not underestimate the ability of firms to produce software at the absolute lowest cost with corners and walls missing.
If I was someone who was to make money off of scamming people, one thing I'd have tried to do is to rig portable sniffers at public locations with large foot traffic and open WiFi like train stations, airports, etc. Throw em around then filter for interesting stuff. Oh here's some personal info. Oh there's a session token for some app. Let me see what else I can get from that app for that person.
Just FYI https://shop.hak5.org/products/wifi-pineapple. There are ready-made devices that can do basically what you are describing!
Oh nice. Just gotta dress em up like Unifi or Aruba then stick em up on the ceiling.
Yep, my partner gave one for my birthday, it's basically plug-and-play. It can automatically harvest credentials, spoof captive portals, etc. I bet that in most places nobody would question something like this hanging on the ceiling indeed.
Also, any unlatched, unfirewalled vulnerabilities you have are immediately available to anyone on that local WiFi network. One thing VPNs may do is cause you to ignore requests from systems on the local network, which helps.
That's an interesting one. I know it depends on configuration, but in the run-of-the-mill case, does connecting through VPN stop local services to listen on local IPs? I know our corpo VPN kills local LAN access but I'm curious what the default for OpenVPN/Wireguard might be.
We need a switch like Firefox has that disallows anything non-HTTPS, but from the phone level. Companies like Apple and Google could also eventually warn apps that they're going to make it the default setting.
Apps don't use the system browser to connect to REST endpoints. Neither do they use the OS. Apps typically use a statically linked library. There are use cases for HTTP-only connections so it's unlikely that those libraries would mess with forcing or even warning its users that they've used HTTP instead of HTTPS. Point is Google and Apple can do little in this regard. Unless they scan apps' source code which could be possible to some extent but still difficult because URLs are often written in pieces.
Sure, I didn't say they use the system browser - I said the opposite. I'm saying the OS should be able to block non-HTTPS connections. If you have control of the OS you can control what protocols are used by apps, unless I'm missing something.
What cases are there for non-HTTPS? I can't think of any. It's 2024. All communication should be encrypted.
The OS interfaces provided to apps (generally POSIX) have no idea what HTTP is. They're much lower level than that. If an OS is to control what protocols are used by apps, it has to offer some functionality that does HTTP for the apps and apps have to use it. Unfortunately the only way to force that would be to disable the general OS interfaces so that apps can't just use existing libraries that use those. If you did that your OS would become useless in other ways that rely on the basic interfaces.
The other way the OS could do anything about it is to inspect network traffic going over its network interfaces. That would be a significantly different can of worms and it's not free in terms of processing power and therefore battery. Then you'd have the screams of privacy people that Android or iOS is looking at all network traffic.
So all in all, the OS isn't very well suited to police application level protocols like HTTP. At least not on devices whose primary purpose isn't network traffic related.
Dpi only works if they install a cert on your phone. Else they can't crack it (in real time) or you would receive HTTPS errors
You dont need to examine the contents of http traffic to do what many services call DPI.
you can still read unencrypted traffic, like most DNS. Or even without that, you can frequently tell from the endpoint IP who someone is talking to, and what types of applications from port numbers used. Etc.
If you're torrenting, for example, that's pretty easy to see.
Still not DPI. Regardless of what other manufacturers or devs call it.
At best it's a network monitor. Literally pihole can give you most of those stats as well.
Yeah, while it is true, lots of VPN companies are grifts just buying VPS's and installing OpenVPN, this "Cyber security expert" puts far too much faith in HTTPS and probably never seen a lecture from the Black Hat conference
Not defending Robert Graham because I'm also eyebrow raising his statement. And while you may be 100% correct that he never actually stayed to listen to a lecture, he absolutely spoke at a lot of them since 2000.
https://infocondb.org/presenter/robert-graham
My bad for judging without checking 😔
Many VPNs using OpenVPN is...fine.
The value adding is the VPN infrastructure they're providing. You can't just install the standard OpenVPN client and expect it to DO anything without some kind of service.
True on the HTTPS thing.
How is DPI a problem if it's encrypted? That would only work if the attacker had installed their CA cert on your client machine, right?
I’m doing DPI on my own network and I can still view TLS certificate fingerprints and some metadata that provides a good educated guess as to what a traffic flow contains. It certainly better that it’s encrypted, but there is a little information that leaks in metadata. I think that’s what was meant.
True, but this is generally not useful information to anyone. They can see you're visiting bank.com, but they still can't see your bank details.
It might be useful if they're trying to target you for phishing, but a targeted attack is extremely unlikely.
Also, any wireless equipment from the past 15 years or so supports client isolation.
Client isolation doesn't help. That is just the access point not routing traffic between connected devices. The problem with WiFi is it is a radio signal. Everybody in range can receive 100% of all communication on that network. Just by being in range the attacker can do passive sniffing. No wiretap needed like with cabled networks.
WiFi is encryoed if it uses a password. So any public WiFi without a password can be sniffed by literally every device in range (no need to connect to the WiFi for sniffing). On public WiFi with a password, the radio signal is encrypted but everybody knows the encryption key. So everybody connected to the WiFi can still sniff the traffic of everybody else.
That encryption is only on the WiFi level, so encrypted radio signals, not on the actually traffic level (like TLS/HTTPS etc).
I think it might be confusion between inspecting plaintext metadata like SNI vs actually inspecting encrypted contents (e.g. HTTPS content, headers, etc.).
Yeah, deep packet inspection really doesn't work without breaking https security via man in the middling everything.
I'm not even an expert in this stuff, but with a tool I found online I demonstrated that it was easy to snoop people's passwords on my school's wifi networks back in the day. It took minutes.
That must’ve been quite a while ago