Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice to avoid public Wi-Fi is mostly out of date

eff.org

Post reply on HN
Print view View original

81–90 of 117 posts

Re: Advice to avoid public Wi-Fi is mostly out of date

#81

Post by saurik »

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload.

Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or figure out what movie someone is watching on Netflix based on the MPEG fragments or guess what article someone is reading on Wikipedia based on the pattern of requested media files. Note that these are each practical attacks that people have implemented; I have also seen a strong argument for a type ahead search attack based on the sequence of search response sets but I don't know if it has been implemented and it feels harder to pull off reliably.

Re: Advice to avoid public Wi-Fi is mostly out of date

#82

Post by maltalex »

Even if HTTPS is deployed, and even if the client actually verifies the certificate, untrusted networks are still risky.

There are many attacks against HTTPSs itself (e.g. DROWN [0]), bugs (like the Windows 10 crypto bug [1] from just a couple of weeks ago), irresponsible CAs (e.g. symantec [2]), and hacked CAs (e.g. DigiNotar [3]).

Are things better than they were before Let's Encrypt? Sure. But is the advice against public Wi-Fi out of date? I don't think so.

[0]: https://en.wikipedia.org/wiki/DROWN_attack [1]: https://techcrunch.com/2020/01/14/microsoft-critical-certifi... [2]: https://wiki.mozilla.org/CA:Symantec_Issues [3]: https://en.wikipedia.org/wiki/DigiNotar

Re: Advice to avoid public Wi-Fi is mostly out of date

#83

Post by sp332 »

saurik wrote: post #81

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload. Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or f…

It's only a little more data than an passive attacker would have with encrypted wifi.

Re: Advice to avoid public Wi-Fi is mostly out of date

#84

Post by kelnos »

saurik wrote: post #81

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload. Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or f…

Sure, and if you're under a repressive regime or have reason to think that someone is targeting you, you should probably still avoid public WiFi (and take a bunch of other countermeasures as well). But for the majority of people, who just care that their banking info isn't compromised (etc.), public WiFi is fine.

Re: Advice to avoid public Wi-Fi is mostly out of date

#85

Post by jancsika »

saurik wrote: post #81

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload. Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or f…

Hm... is there some kind of transit quantization plugin for a VPN like Wireguard? Like maybe data is sent in blocks of small, medium, large, or none.

Re: Advice to avoid public Wi-Fi is mostly out of date

#86

Post by saurik »

sp332 wrote: post #83
saurik wrote: post #81

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload. Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or f…

It's only a little more data than an passive attacker would have with encrypted wifi.

That's an interesting point, but because browsers decided not to use HTTP/1.1 pipelining and encrypted SNI is still only an optional thing in TLS 1.3, the clean signal you get from the separate connections, each of which is tied to a hostname, makes these attacks extremely cheap and "practical" in a way that isn't quite as true when you are dealing with commingled data from all of the user's simultaneous connections, many of which might be to the same host; like, seeing "the user requested 32 map tiles with these individual sizes" is very different from "the user requested a bunch of map tiles--maybe 32ish--and they total in size to this amount... that or they are watching a YouTube video". This article might be a lot more valid once the web has upgraded to HTTP/2, particularly if it manages to adopt encrypted SNI.

Re: Advice to avoid public Wi-Fi is mostly out of date

#87

Post by saurik »

jancsika wrote: post #85
saurik wrote: post #81

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload. Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or f…

Hm... is there some kind of transit quantization plugin for a VPN like Wireguard? Like maybe data is sent in blocks of small, medium, large, or none.

I haven't integrated support for this yet, as I am still working out how I want to best handle the return path, but I definitely am going to be getting this feature into Orchid in the near future.

Re: Advice to avoid public Wi-Fi is mostly out of date

#88

Post by saurik »

kelnos wrote: post #84
saurik wrote: post #81

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload. Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or f…

Sure, and if you're under a repressive regime or have reason to think that someone is targeting you, you should probably still avoid public WiFi (and take a bunch of other countermeasures as well). But for the majority of people, who just care that their banking info isn't compromised (etc.), public WiFi is fine.

And if that is what the article said, I wouldn't be annoyed; but it went out of its way to claim that people wouldn't know what pages you were visiting, and that's a naive misinterpretation of what encryption is buying you.

Re: Advice to avoid public Wi-Fi is mostly out of date

#89

Post by fkfaduc »

Filligree wrote: post #64
skrebbel wrote: post #46

Earlier quoted context omitted.

> Unless there’s an attack on cert providers or someone adds a cert to your device. How does HSTS help with that?

HSTS has a certificate pinning extension, but base HSTS wouldn't.

Isn't certificate pinning deprecated for regular web traffic?

Re: Advice to avoid public Wi-Fi is mostly out of date

#90

Post by tialaramex »

alias_neo wrote: post #78
knute wrote: post #11

Earlier quoted context omitted.

In my experience, the OS _does_ handle that automatically. If the app isn't verifying it, it's because they went out of their way to disable certificate validation. Which is alarming.

It's not the same as pinning though. The device trusts that a cert was signed by _any_ CA on your phone, not necessarily the one that really issued the one you expect. So, if my company installed a CA on my phone that they issued in-house, and MiTM my traffic, they can spoof certs and most software will accept it. To be really safe, you should pin the certificate to ensure that your code only trusts a specific certif…

Pinning is a serious step, there's a lot of opportunity for a foot gun. You absolutely need to decide up front what the intended behaviour for your app is when the pin is invalid. Don't say "That will never happen" because it will happen. Maybe the client is happy that their app simply does not work if the pin condition isn't satisfied. A bank might feel that way for example. But if it's a surprise I guarantee they aren't going to be happy and that means you did a bad job.

Building your own PKI is always potentially the safest option, and in practice it will usually be the least safe and most unreliable. The main attraction of your own PKI should not be the safety/ security you likely won't actually achieve in practice but other conveniences. For example your PKI can issue a 20 year cert. Maybe it shouldn't, but it can and that might work better for you than certificates which expire and introduce exciting last minute changes.

Post reply on HN