this post was submitted on 06 Oct 2024
726 points (91.0% liked)

Technology

58550 readers
5546 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. 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
[–] avidamoeba@lemmy.ca 72 points 2 days ago* (last edited 2 days ago) (3 children)

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.

[–] sudneo@lemm.ee 25 points 2 days ago (1 children)

Just FYI https://shop.hak5.org/products/wifi-pineapple. There are ready-made devices that can do basically what you are describing!

[–] avidamoeba@lemmy.ca 7 points 2 days ago* (last edited 2 days ago) (1 children)

Oh nice. Just gotta dress em up like Unifi or Aruba then stick em up on the ceiling.

[–] sudneo@lemm.ee 7 points 2 days ago

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.

[–] ripcord@lemmy.world 6 points 2 days ago (1 children)

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.

[–] avidamoeba@lemmy.ca 3 points 2 days ago

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.

[–] asdfasdfasdf@lemmy.world 8 points 2 days ago* (last edited 2 days ago) (1 children)

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.

[–] avidamoeba@lemmy.ca 7 points 2 days ago (1 children)

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.

[–] asdfasdfasdf@lemmy.world 6 points 2 days ago* (last edited 2 days ago) (1 children)

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.

[–] avidamoeba@lemmy.ca 2 points 2 days ago* (last edited 2 days ago)

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.