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.
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.
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.
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.
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.
I think it might be confusion between inspecting plaintext metadata like SNI vs actually inspecting encrypted contents (e.g. HTTPS content, headers, etc.).
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
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.
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.
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.
There exist plenty of services on school campuses that send passwords in plaintext. There are services outside of school campuses that do, too. Hell, I’ve been able to bypass 2FA checks by just navigating around them, I don’t know what else to tell you, not everything out there uses the best security practices, so don’t assume that they do.
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.
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.
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.
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.
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.
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.
deleted by creator
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.
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
I mean, yes, I’m in my 40s, but it’s just as effective today.
I’m sorry, but I don’t believe it is. Nearly all traffic is TLS. When this is attacked, you’d get TLS error. Am I missing something?
There exist plenty of services on school campuses that send passwords in plaintext. There are services outside of school campuses that do, too. Hell, I’ve been able to bypass 2FA checks by just navigating around them, I don’t know what else to tell you, not everything out there uses the best security practices, so don’t assume that they do.
I guarantee you it’s not.