13 ms·

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

206 points by DiabloD3 7y ago

resoluteteeth 7y ago
Passive interception is less of an issue because so many sites are using tls, but in the case of a mitm attack isn't https stripping still a problem unless the site is using hsts?
- kevinsimper 7y ago
  You would have to trust a root certificates from your mitm attacker, so it is not a problem.
  - resoluteteeth 7y ago
    When you first access a site, unless the site is using HSTS you are going to go to an insecure version so a mitm can proxy the request and remove tls or redirect you to another site. This is what is known as "https stripping."
    - zzzcpan 7y ago
      You are talking about "HSTS Preload", HSTS doesn't do anything on first access.
      - acdha 7y ago
        HSTS helps unless you are always on compromised networks or the site uses short TTLs. Even without preloading most people are probably not accessing their bank for the first time ever on a malicious network.
  - iso1631 7y ago
    Block outgoing connections on port 443. MITM anything on port 80 which forwards to the server on port 443. Your browser then loads www.whatever.com as http, even if the server doesn't allow http. HSTS means if you've been to www.whatever.com before you'll be blocked. If you've never been before that doesn't help though. In that fashion, typing www.mybank.com could redirect you to http://www.mybank.com http://www.mybank.com (mitm) then to https://www.mybank.com-login.com/ https://www.mybank.com-login.com/, where you get a green padlock.
  - andreareina 7y ago
    I know someone who got caught out by this. Bank's front page was http, so the attackers mitm'ed that. Ebanking link was swapped out for an https page they controlled, allowing the credentials to be harvested before redirecting to the bank.
- IshKebab 7y ago
  Not really because most sites you visit you've already visited before. HTST preload only helps for the first visit to a site. After that it makes no difference.
kevinsimper 7y ago
The EFF is awesome with Let's Encrypt! It was really a dreadful task to buy and renew certificates, especially as out infrastructure back then wasn't that automated. I think this article is a response to all those ads from VPN companies. They do try to scare people about public WiFi's.
- giancarlostoro 7y ago
  One thing I would love to see in the future is the addition of LetsEncrypt support for major web servers like Nginx and Apache. I think this could go a long way. In the case of Apache it would be one of those "mod" type of packages. Someone feel free to let me know if this is already the case though, I would love to make note of it. Edit: Looks like Apache has one called 'md': https://httpd.apache.org/docs/trunk/mod/mod_md.html https://httpd.apache.org/docs/trunk/mod/mod_md.html Your move Nginx? :)
  - atonse 7y ago
    Really what we need is what Caddy ended up being. Best practices rolled in as defaults. That’s why I use caddy just about everywhere that isn’t a load balancer.
    - deleted 7y ago
      [deleted]
  - zzzcpan 7y ago
    > One thing I would love to see in the future is the addition of LetsEncrypt support for major web servers like Nginx and Apache. I think this could go a long way. This is not as useful as you think. In nginx you only need a couple of extra lines of configuration to let an external program issue and renew certificates independently from nginx, without reloads, etc. Definitely not worth developing a C nginx module that starts a helper process that does that just so that a few people who run nginx on a single server could get their certificates issued with only one line of configuration.
    - 7y ago
mping 7y ago
Err, no it is not safe unless you trust the app you are running to validate the certificate chain. Not so long ago, I found out my bank's app didn't validate the cert and I could happily put a proxy and intercept all calls.
- ben_w 7y ago
  That’s an interesting point. As an app developer, I’d assumed that would be handled automatically by the OS. What’s the best way to test for certificate validity? (In my case I’m interested in iOS, but the same concern must exist on all platforms).
  - VBprogrammer 7y ago
    Unless the libraries you are using are fubar then you normally have to explicitly tell it to ignore certificate chain errors i.e. requests.get(..., verify=False)
  - knute 7y ago
    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.
    - iso1631 7y ago
      What's the odds that the corporate network the developers are on does MITM https interception, and the only way they could get their app to work was to remove certificate validation
      - RKearney 7y ago
        Very slim, as you can still verify the certificate chains up to a trusted root certificate and it’s trivial (and generally part of the enrollment process) to load the companies root CA on your device. We MITM and certificate validation works correctly.
GlitchMr 7y ago
Unfortunately, while HTTPS is very common, this isn't really the case with HSTS Preload, so active MitM attacks are still a threat.
- IshKebab 7y ago
  I wrote a wifi hotspot app for Android that could MitM HTTPS requests as you suggest about 8 years ago. Even back then it didn't work very well because even without HSTS preload, most people aren't visiting new websites for the first time on your free public Wifi.
- moviuro 7y ago
  Even just HSTS is not widely deployed. Here in France for instance: * top 1 banking, top 18 FR https://www.ssllabs.com/ssltest/analyze.html?d=labanquepostale.fr&latest https://www.ssllabs.com/ssltest/analyze.html?d=labanqueposta... no HSTS * top 2 banking, top 20 FR https://www.ssllabs.com/ssltest/analyze.html?d=credit-agricole.fr https://www.ssllabs.com/ssltest/analyze.html?d=credit-agrico... no HSTS * top 1 taxes, top 30 FR https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.gouv.fr https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.go... with CAA, HSTS (not preload), OCSP Must-Staple! (that's a surprise) * top 3 banking, top 45 FR https://www.ssllabs.com/ssltest/analyze.html?d=caisse%2depargne.fr&latest https://www.ssllabs.com/ssltest/analyze.html?d=caisse%2depar... no HSTS Hopefuly, by 2030 banks will have caught up to the 2018 standard for "secure".
- Ajedi32 7y ago
  Yep. Not only is HTTPS stripping still a problem, but active attackers can do all sorts of other nasty things as well, like force the user's browser to initiate plaintext HTTP requests to non-HSTS sites and then use that to steal cookies from third party domains, or achieve persistent XSS by poisoning the user's browser cache. See https://samy.pl/poisontap/ https://samy.pl/poisontap/ for a great example of that attack in action.
- skrebbel 7y ago
  refresh my understanding, if i manually type "https" into the address bar, then i can't be MitM'ed through lack of HSTS, right?
tsukurimashou 7y ago
Don't most of public Wifi (airports especially) have their own CA to MiTM SSL connections just like most companies do to inspect HTTPS traffic?
- iso1631 7y ago
  No, because that will simply fail. I did see it once on a train in the UK, but that's the only time I've seen https MITM.
- fulafel 7y ago
  This only works if your mitm ca is preinstalled in the client device.
- Maximus9000 7y ago
  > airports especially Indeed, lets not forget what the Snowden leaks said about airports: https://www.cbc.ca/news/politics/csec-used-airport-wi-fi-to-track-canadian-travellers-edward-snowden-documents-1.2517881 https://www.cbc.ca/news/politics/csec-used-airport-wi-fi-to-...
- IshKebab 7y ago
  I've never seen this. They usually just block all HTTPS connections and rely on automatic captive portal detection in modern OSes. Occasionally I've had wifi that had a captive HTTP portal but would allow HTTPS through anyway.
- acdha 7y ago
  I haven’t seen that in about 15 years: the experience is horrible and will get tons of complaints.
PaulHoule 7y ago
I remember in 2005 when you could just start up Ethereal, run it for a minute, and get many people's email passwords, email, everything... I think Wi-Fi security is going to be a major FUD talking point for the telecoms as they try to justify high prices, 5G, and the rest of their trip. 5G as it exists now does little to compete with WiFi because (in the millimeter wave form) it doesn't pass through walls. The overwhelming majority of data consumption happens indoors, so it can't make for a revolution in the market unless you get a huge number of antennas and/or cells installed indoors. That's immensely problematic because building managers aren't going to want to have Verizon, AT&T, T-Mobile and maybe someday Dish Network stomp through their buildings, drill holes, do damage, etc. There has been talk of wholesale access networks, which would be a great idea (e.g. a neutral vendor installs indoor infrastructure that gets rented by the carriers...) but the carriers are dead set against it.
- ozim 7y ago
  But 5G is not meant for in house consumption. It is meant for crowded spaces like train stations, supermarkets to offload other bands. Then you get micro cells installed indoors inside of supermarkets. (what I mean by supermarket means mall and all those kind of shopping centers) It is meant also for all kinds of smart sensors in area, but not like home sensors but utilities. We have that with LoRa, but it is really small data amounts, where 5G would be used for sensors that need more data, like smart traffic lights? Then you won't have to connect your old traffic lights to some cable network and they would get good connection capabilities. Right now 4G is not used everywhere, in less dense areas you only get 3G. Of course providers will install base stations for 5G in places where it is economically possible. Places that have 3G now are not getting 5G anytime soon. It is also understandable that 900MHz is better for longer range than 1800MHz.
  - PaulHoule 7y ago
    5G below 6GHz really requires dynamic spectrum sharing with 4G. Once that is standardized, carriers can gradually switch out 4G for 5G with modest but real benefits. I was part of a group that installed some radio gear on the roof of the local mall and I can say that the building manager of the mall was a tough customer. It really helped that he liked our (union) electrician and was certain we wouldn't contribute any leaks to the roof. Carriers used to use the IBEW and CWA and had some standards for the quality of work done. Today carriers tend to use non-union contractors -- some of those people are excellent to OK but some are real idiots that any property owner would want to keep far away. So far as serious IoT goes I think the coverage problems will still dog IoT. With fiber you can get 100% coverage -- it costs money, but there is no site that can't be served. Will cell phones carriers will tell you they cover 98% of POPs, when you investigate it might be more like they cover 89% of POPs. With wireless systems you make a rather large capital investment that rapidly erodes in value to get to that 89% coverage but then the cost explodes from there.
theandrewbailey 7y ago
Even if a WPA2 wifi point has a password, isn't the encryption key shared among all connections? I.e, if an attacker has the wifi password, it nullifies the wifi encryption? I recall that fixing this was one of WPA3's selling points.
- Cogitri 7y ago
  Not exactly, you need more information than just the WiFi password in order to decrypt the traffic: https://superuser.com/questions/156869/can-other-people-on-an-encrypted-wi-fi-ap-see-what-youre-doing https://superuser.com/questions/156869/can-other-people-on-a...
mayniac 7y ago
As other people have mentioned, HTTPS without HSTS still makes MitM a problem. And there are still other attacks possible on public wi-fi networks which don't involve MitM-ing HTTP(s) traffic. MitM DNS traffic and you can do nasty things: https://github.com/infobyte/evilgrade https://github.com/infobyte/evilgrade
Amorymeltzer 7y ago
> So when you visit HTTPS sites, anyone along the communication path... can see their domain names (e.g. wikipedia.org) and when you visit them. 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. I believe this is the reason Turkey blocked the entirety of Wikipedia[0], which was recently lifted[1]. They wanted to block specific pages that revealed negative information (and I believe they did at some point), but when Wikipedia went https only[2] the only avenue was to block the entire domain. 0: https://en.wikipedia.org/wiki/Block_of_Wikipedia_in_Turkey https://en.wikipedia.org/wiki/Block_of_Wikipedia_in_Turkey 1: https://wikimediafoundation.org/news/2020/01/15/access-to-wikipedia-restored-in-turkey-after-more-than-two-and-a-half-years/ https://wikimediafoundation.org/news/2020/01/15/access-to-wi... 2:
- dkarras 7y ago
  Am Turkish, and not really. There is no evidence of Turkey caring about what the individual citizens visit (except in case of a crime investigation etc.) Bans in Turkey works like this: Turkey sees something they don't like on the Internet, Turkey reaches the company / individuals behind it (they can be anywhere in the world) and tells them "take it down or we will block your access to Turkish citizens and you'll lose revenue / traffic". If the site owners comply nothing happens. If site owners refuse for any reason, they block the site so it is not accessible from Turkey. In the older days, they used to do it through DNS but it was easy to circumvent. Now they use other methods so changing your DNS isn't enough, but a VPN works just fine. This was also the case before https wasn't as common BTW. Turkey either didn't have the technical capability to block individual pages (even back then) or they were seeking to punish the site by blocking access in whole. A site like wikipedia values integrity more so they don't take pages down without good reason. But companies seeing Turkish citizens as a revenue source generally comply. If you browse Twitter in Turkey, it is common to see tweets where it just says something like "this tweet is blocked in your country" - Turkey reaches twitter to mark the tweet invisible and that individual tweet goes away. IIRC it also applies to entire profiles - I'm not a frequent twitter user but I remember seeing entire profiles blocked by country.
  - 7y ago
air7 7y ago
I think jumps the gun a little. When sharing a network, there are other attack vectors into people's unhardened laptops except browser MITM. Do you have any unprotected shared folders? Can someone brute force your login via RDP? Can you account for all the listening ports running on your device? A NAT provides strong protection by simply firewalling you from the outside world. It's so common that the focus (rightfully) zoomed in on MITM as that is the only thing "left", but in a shared network, the adversary may reside on the inside nulling that protection. Most users have not taken precautions against this. Oh, and shoulder surfing.
- Kocrachon 7y ago
  Yeah this article is only covering a specific attack vector, to claim that public Wifi is nearly risk free because of HTTPS is a very dangerous statement to make. The risk of public wifi was far from just having your traffic spied on.
- gruez 7y ago
  >Can someone brute force your login via RDP? probably a non-issue since it isn't enabled by default. > Can you account for all the listening ports running on your device? that's what firewall (which are typically default deny for incoming) is for.
- reaperducer 7y ago
  Do you have any unprotected shared folders? It's surprising how many people have unprotected shared folders. And for some reason they very often are full of music. Spend a few days on a hotel's wifi and you can slurp up thousands of other people's MP3's.
JohnFen 7y ago
They're talking exclusively about web browsing, though. There's more to net access than the web. Personally, I just always use a VPN (and a firewall to ensure that no traffic flows except through the VPN). Then I don't have to worry as much.
- EduardoBautista 7y ago
  HTTPS is not limited to web browsing. It's also how the vast majority of desktop apps communicate on with web servers.
logicallee 7y ago
Isn't domain information still in the clear? (What specific domain you're connecting to.)
- tialaramex 7y ago
  The exact hostname is delivered in SNI (serverNameIndication) during connection yes. Figuring out a safe reliable way to encrypt this data is an ongoing work item for the TLS Working Group after TLS 1.3 wrapped up. If you have a recent Firefox (possibly only in Nightlies?) you can see one possible approach work with Cloudflare sites which opted in. You will also need encrypted DNS (DPRIVE e.g. DNS over HTTPS) or it's largely pointless.
gwbas1c 7y ago
I still http-only links on Hacker News regularly.
saurik 7y ago
> 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.
- sp332 7y ago
  It's only a little more data than an passive attacker would have with encrypted wifi.
  - saurik 7y ago
    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.
- kelnos 7y ago
  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.
maltalex 7y ago
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 https://en.wikipedia.org/wiki/DROWN_attack [1]: https://techcrunch.com/2020/01/14/microsoft-critical-certificates-bug/ https://techcrunch.com/2020/01/14/microsoft-critical-certifi... [2]: https://wiki.mozilla.org/CA:Symantec_Issues https://wiki.mozilla.org/CA:Symantec_Issues [3]: https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar
diebeforei485 7y ago
VPN companies have been using the "omg public wifi scary" meme to market their products. I agree with EFF here.
3xblah 7y ago
"So when you visit HTTPS sites, anyone along the communication path - from your ISP to the Internet backbone provider to the site's hosting provider - can see their domain names (e.g. wikipedia.org) and when you visit them." Except wikipedia.org does not require SNI. Most HTTPS sites do not require SNI. Not every client sends SNI by default. OpenSSL's s_client does not. There are others. printf "GET /wiki/MediaWiki HTTP/1.1\r\nHost: en.wikipedia.org\r\nConnection: close\r\n\r\n"|openssl s_client -showcerts -connect mediawiki.org:443 -ign_eof Some sites "require" SNI, but then do not check it against the Host header. A client can send any SNI. The server certificate says *.wikipedia.org. But there are numerous websites sharing the IP addresses for wikipedia.org, not all of them serving Wikipedia content. One example is mediawiki.org. What if a website padded all its pages to be the same size.
badrabbit 7y ago
What is up with these b.s posts about open or public wifi being safe this week? A few days ago there was a twitter thread by a security person at a hotel claimig their open wifi is safe. I won't detail all the many harms you can suffer (or the threats that will readily cause you harm),but let me state just one argument related to eff's silly (and dangerously harmfull ) statement here: 1) when you type in a domain in your navigation bar, your browser attempts to connect to unencrypted http(port 80) 2) if (big if!) The site supports https it will do an http 301 redirect to the https version of the site. 3) An attacker needs to intercept just one such redirect to have an opportunity for credential theft or content injection (downloads,exploits,etc...) 3) your browser does indeed remember these redirects going forward,which is great. 4) Except if you configured your browser to forget all history. Or if you happen to remember a site you visited a while ago (perhaps on a different device) and just typed it in to navigate. Or if you typed in something to search but your browser navigates to it,or many other opportunities for pwnage! 5) you don't care about that? Well attackers are happy to setup a malicious captive portal(captive portal checks are plain http for all browsers I know of) and use that directly or to social engineer installation of an app you "need" to connect (oh,mitmproxy has a nifty captive portal like page you can customize to install a CA cert on the device for TLS interception) I won't even begin to talk about at least half a dozen additional classes of MITM attacks that can be used, even with wpa3 and client isolation! What you have to understand is that vulns that would normally be low severity are amplified in this sort of a network, due to the sheer magnitude of threat exposure. I can't complain about most people being ignorant to good infosec practices(we have to understand+educate) but man this stings! The eff makes one of my favorite extensions HTTPSEverywhere, how can they post this? It takes a long time to educate people about good security practices.
oliwarner 7y ago
This seems like weird advice to give out. Sure, it's not as dangerous as it was... Or is it? All the tools are mature now. Documentation is rife. A seven year old with a Raspberry Pi can set up a hotspot and spike your DNS. This thread contains a litany of security papercuts across the whole stack. DNS, shitty apps, crappy server configs and sites that just don't care. So yeah, it's no 1999. You're probably not getting your FTP password sniffed off a public network these days, but there are still plenty of reasons for me to use 4G or WireGuard instead of trustless networks. Public Wi-Fi will remain firmly on my "list of things to worry about" until I can audit all traffic from my devices.
pvtmert 7y ago
tl:dr; "You would be safe in active war-zone (eg. syria) because you are civillian and do not carry any weapons with you" No, you are not safe at all. Lets assume public wifi requires acceptance of terms and conditions. - Redirects all pages (from your Mac/Ip address) to their server - There is checkbox on the page for ToS/ToC approval and 'Continue' button - Behind the scenes clickjacking/framebusting happens [0] - You get PWNd or monetized. - also being fingerprinted by company. eg: amiunique.org Given conditions, they can inject ads/cookies to track you even after you go away. (eg. at home) [0]: https://blog.innerht.ml/google-yolo/ https://blog.innerht.ml/google-yolo/

206 points by DiabloD3 7y ago

Passive interception is less of an issue because so many sites are using tls, but in the case of a mitm attack isn't https stripping still a problem unless the site is using hsts?

kevinsimper 7y ago
You would have to trust a root certificates from your mitm attacker, so it is not a problem.
- resoluteteeth 7y ago
  When you first access a site, unless the site is using HSTS you are going to go to an insecure version so a mitm can proxy the request and remove tls or redirect you to another site. This is what is known as "https stripping."
  - zzzcpan 7y ago
    You are talking about "HSTS Preload", HSTS doesn't do anything on first access.
    - acdha 7y ago
      HSTS helps unless you are always on compromised networks or the site uses short TTLs. Even without preloading most people are probably not accessing their bank for the first time ever on a malicious network.
- iso1631 7y ago
  Block outgoing connections on port 443. MITM anything on port 80 which forwards to the server on port 443. Your browser then loads www.whatever.com as http, even if the server doesn't allow http. HSTS means if you've been to www.whatever.com before you'll be blocked. If you've never been before that doesn't help though. In that fashion, typing www.mybank.com could redirect you to http://www.mybank.com http://www.mybank.com (mitm) then to https://www.mybank.com-login.com/ https://www.mybank.com-login.com/, where you get a green padlock.
- andreareina 7y ago
  I know someone who got caught out by this. Bank's front page was http, so the attackers mitm'ed that. Ebanking link was swapped out for an https page they controlled, allowing the credentials to be harvested before redirecting to the bank.
IshKebab 7y ago
Not really because most sites you visit you've already visited before. HTST preload only helps for the first visit to a site. After that it makes no difference.

kevinsimper 7y ago

The EFF is awesome with Let's Encrypt! It was really a dreadful task to buy and renew certificates, especially as out infrastructure back then wasn't that automated. I think this article is a response to all those ads from VPN companies. They do try to scare people about public WiFi's.

giancarlostoro 7y ago
One thing I would love to see in the future is the addition of LetsEncrypt support for major web servers like Nginx and Apache. I think this could go a long way. In the case of Apache it would be one of those "mod" type of packages. Someone feel free to let me know if this is already the case though, I would love to make note of it. Edit: Looks like Apache has one called 'md': https://httpd.apache.org/docs/trunk/mod/mod_md.html https://httpd.apache.org/docs/trunk/mod/mod_md.html Your move Nginx? :)
- atonse 7y ago
  Really what we need is what Caddy ended up being. Best practices rolled in as defaults. That’s why I use caddy just about everywhere that isn’t a load balancer.
  - deleted 7y ago
    [deleted]
- zzzcpan 7y ago
  > One thing I would love to see in the future is the addition of LetsEncrypt support for major web servers like Nginx and Apache. I think this could go a long way. This is not as useful as you think. In nginx you only need a couple of extra lines of configuration to let an external program issue and renew certificates independently from nginx, without reloads, etc. Definitely not worth developing a C nginx module that starts a helper process that does that just so that a few people who run nginx on a single server could get their certificates issued with only one line of configuration.
  - 7y ago

mping 7y ago

Err, no it is not safe unless you trust the app you are running to validate the certificate chain. Not so long ago, I found out my bank's app didn't validate the cert and I could happily put a proxy and intercept all calls.

ben_w 7y ago
That’s an interesting point. As an app developer, I’d assumed that would be handled automatically by the OS. What’s the best way to test for certificate validity? (In my case I’m interested in iOS, but the same concern must exist on all platforms).
- VBprogrammer 7y ago
  Unless the libraries you are using are fubar then you normally have to explicitly tell it to ignore certificate chain errors i.e. requests.get(..., verify=False)
- knute 7y ago
  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.
  - iso1631 7y ago
    What's the odds that the corporate network the developers are on does MITM https interception, and the only way they could get their app to work was to remove certificate validation
    - RKearney 7y ago
      Very slim, as you can still verify the certificate chains up to a trusted root certificate and it’s trivial (and generally part of the enrollment process) to load the companies root CA on your device. We MITM and certificate validation works correctly.

GlitchMr 7y ago

Unfortunately, while HTTPS is very common, this isn't really the case with HSTS Preload, so active MitM attacks are still a threat.

IshKebab 7y ago
I wrote a wifi hotspot app for Android that could MitM HTTPS requests as you suggest about 8 years ago. Even back then it didn't work very well because even without HSTS preload, most people aren't visiting new websites for the first time on your free public Wifi.
moviuro 7y ago
Even just HSTS is not widely deployed. Here in France for instance: * top 1 banking, top 18 FR https://www.ssllabs.com/ssltest/analyze.html?d=labanquepostale.fr&latest https://www.ssllabs.com/ssltest/analyze.html?d=labanqueposta... no HSTS * top 2 banking, top 20 FR https://www.ssllabs.com/ssltest/analyze.html?d=credit-agricole.fr https://www.ssllabs.com/ssltest/analyze.html?d=credit-agrico... no HSTS * top 1 taxes, top 30 FR https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.gouv.fr https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.go... with CAA, HSTS (not preload), OCSP Must-Staple! (that's a surprise) * top 3 banking, top 45 FR https://www.ssllabs.com/ssltest/analyze.html?d=caisse%2depargne.fr&latest https://www.ssllabs.com/ssltest/analyze.html?d=caisse%2depar... no HSTS Hopefuly, by 2030 banks will have caught up to the 2018 standard for "secure".
Ajedi32 7y ago
Yep. Not only is HTTPS stripping still a problem, but active attackers can do all sorts of other nasty things as well, like force the user's browser to initiate plaintext HTTP requests to non-HSTS sites and then use that to steal cookies from third party domains, or achieve persistent XSS by poisoning the user's browser cache. See https://samy.pl/poisontap/ https://samy.pl/poisontap/ for a great example of that attack in action.
skrebbel 7y ago
refresh my understanding, if i manually type "https" into the address bar, then i can't be MitM'ed through lack of HSTS, right?

tsukurimashou 7y ago

Don't most of public Wifi (airports especially) have their own CA to MiTM SSL connections just like most companies do to inspect HTTPS traffic?

iso1631 7y ago
No, because that will simply fail. I did see it once on a train in the UK, but that's the only time I've seen https MITM.
fulafel 7y ago
This only works if your mitm ca is preinstalled in the client device.
Maximus9000 7y ago
> airports especially Indeed, lets not forget what the Snowden leaks said about airports: https://www.cbc.ca/news/politics/csec-used-airport-wi-fi-to-track-canadian-travellers-edward-snowden-documents-1.2517881 https://www.cbc.ca/news/politics/csec-used-airport-wi-fi-to-...
IshKebab 7y ago
I've never seen this. They usually just block all HTTPS connections and rely on automatic captive portal detection in modern OSes. Occasionally I've had wifi that had a captive HTTP portal but would allow HTTPS through anyway.
acdha 7y ago
I haven’t seen that in about 15 years: the experience is horrible and will get tons of complaints.

PaulHoule 7y ago

I remember in 2005 when you could just start up Ethereal, run it for a minute, and get many people's email passwords, email, everything... I think Wi-Fi security is going to be a major FUD talking point for the telecoms as they try to justify high prices, 5G, and the rest of their trip. 5G as it exists now does little to compete with WiFi because (in the millimeter wave form) it doesn't pass through walls. The overwhelming majority of data consumption happens indoors, so it can't make for a revolution in the market unless you get a huge number of antennas and/or cells installed indoors. That's immensely problematic because building managers aren't going to want to have Verizon, AT&T, T-Mobile and maybe someday Dish Network stomp through their buildings, drill holes, do damage, etc. There has been talk of wholesale access networks, which would be a great idea (e.g. a neutral vendor installs indoor infrastructure that gets rented by the carriers...) but the carriers are dead set against it.

ozim 7y ago
But 5G is not meant for in house consumption. It is meant for crowded spaces like train stations, supermarkets to offload other bands. Then you get micro cells installed indoors inside of supermarkets. (what I mean by supermarket means mall and all those kind of shopping centers) It is meant also for all kinds of smart sensors in area, but not like home sensors but utilities. We have that with LoRa, but it is really small data amounts, where 5G would be used for sensors that need more data, like smart traffic lights? Then you won't have to connect your old traffic lights to some cable network and they would get good connection capabilities. Right now 4G is not used everywhere, in less dense areas you only get 3G. Of course providers will install base stations for 5G in places where it is economically possible. Places that have 3G now are not getting 5G anytime soon. It is also understandable that 900MHz is better for longer range than 1800MHz.
- PaulHoule 7y ago
  5G below 6GHz really requires dynamic spectrum sharing with 4G. Once that is standardized, carriers can gradually switch out 4G for 5G with modest but real benefits. I was part of a group that installed some radio gear on the roof of the local mall and I can say that the building manager of the mall was a tough customer. It really helped that he liked our (union) electrician and was certain we wouldn't contribute any leaks to the roof. Carriers used to use the IBEW and CWA and had some standards for the quality of work done. Today carriers tend to use non-union contractors -- some of those people are excellent to OK but some are real idiots that any property owner would want to keep far away. So far as serious IoT goes I think the coverage problems will still dog IoT. With fiber you can get 100% coverage -- it costs money, but there is no site that can't be served. Will cell phones carriers will tell you they cover 98% of POPs, when you investigate it might be more like they cover 89% of POPs. With wireless systems you make a rather large capital investment that rapidly erodes in value to get to that 89% coverage but then the cost explodes from there.

theandrewbailey 7y ago

Even if a WPA2 wifi point has a password, isn't the encryption key shared among all connections? I.e, if an attacker has the wifi password, it nullifies the wifi encryption? I recall that fixing this was one of WPA3's selling points.

Cogitri 7y ago
Not exactly, you need more information than just the WiFi password in order to decrypt the traffic: https://superuser.com/questions/156869/can-other-people-on-an-encrypted-wi-fi-ap-see-what-youre-doing https://superuser.com/questions/156869/can-other-people-on-a...

mayniac 7y ago

As other people have mentioned, HTTPS without HSTS still makes MitM a problem. And there are still other attacks possible on public wi-fi networks which don't involve MitM-ing HTTP(s) traffic. MitM DNS traffic and you can do nasty things: https://github.com/infobyte/evilgrade https://github.com/infobyte/evilgrade

Amorymeltzer 7y ago

> So when you visit HTTPS sites, anyone along the communication path... can see their domain names (e.g. wikipedia.org) and when you visit them. 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. I believe this is the reason Turkey blocked the entirety of Wikipedia[0], which was recently lifted[1]. They wanted to block specific pages that revealed negative information (and I believe they did at some point), but when Wikipedia went https only[2] the only avenue was to block the entire domain. 0: https://en.wikipedia.org/wiki/Block_of_Wikipedia_in_Turkey https://en.wikipedia.org/wiki/Block_of_Wikipedia_in_Turkey 1: https://wikimediafoundation.org/news/2020/01/15/access-to-wikipedia-restored-in-turkey-after-more-than-two-and-a-half-years/ https://wikimediafoundation.org/news/2020/01/15/access-to-wi... 2:

dkarras 7y ago
Am Turkish, and not really. There is no evidence of Turkey caring about what the individual citizens visit (except in case of a crime investigation etc.) Bans in Turkey works like this: Turkey sees something they don't like on the Internet, Turkey reaches the company / individuals behind it (they can be anywhere in the world) and tells them "take it down or we will block your access to Turkish citizens and you'll lose revenue / traffic". If the site owners comply nothing happens. If site owners refuse for any reason, they block the site so it is not accessible from Turkey. In the older days, they used to do it through DNS but it was easy to circumvent. Now they use other methods so changing your DNS isn't enough, but a VPN works just fine. This was also the case before https wasn't as common BTW. Turkey either didn't have the technical capability to block individual pages (even back then) or they were seeking to punish the site by blocking access in whole. A site like wikipedia values integrity more so they don't take pages down without good reason. But companies seeing Turkish citizens as a revenue source generally comply. If you browse Twitter in Turkey, it is common to see tweets where it just says something like "this tweet is blocked in your country" - Turkey reaches twitter to mark the tweet invisible and that individual tweet goes away. IIRC it also applies to entire profiles - I'm not a frequent twitter user but I remember seeing entire profiles blocked by country.
- 7y ago

air7 7y ago

I think jumps the gun a little. When sharing a network, there are other attack vectors into people's unhardened laptops except browser MITM. Do you have any unprotected shared folders? Can someone brute force your login via RDP? Can you account for all the listening ports running on your device? A NAT provides strong protection by simply firewalling you from the outside world. It's so common that the focus (rightfully) zoomed in on MITM as that is the only thing "left", but in a shared network, the adversary may reside on the inside nulling that protection. Most users have not taken precautions against this. Oh, and shoulder surfing.

Kocrachon 7y ago
Yeah this article is only covering a specific attack vector, to claim that public Wifi is nearly risk free because of HTTPS is a very dangerous statement to make. The risk of public wifi was far from just having your traffic spied on.
gruez 7y ago
>Can someone brute force your login via RDP? probably a non-issue since it isn't enabled by default. > Can you account for all the listening ports running on your device? that's what firewall (which are typically default deny for incoming) is for.
reaperducer 7y ago
Do you have any unprotected shared folders? It's surprising how many people have unprotected shared folders. And for some reason they very often are full of music. Spend a few days on a hotel's wifi and you can slurp up thousands of other people's MP3's.

JohnFen 7y ago

They're talking exclusively about web browsing, though. There's more to net access than the web. Personally, I just always use a VPN (and a firewall to ensure that no traffic flows except through the VPN). Then I don't have to worry as much.

EduardoBautista 7y ago
HTTPS is not limited to web browsing. It's also how the vast majority of desktop apps communicate on with web servers.

logicallee 7y ago

Isn't domain information still in the clear? (What specific domain you're connecting to.)

tialaramex 7y ago
The exact hostname is delivered in SNI (serverNameIndication) during connection yes. Figuring out a safe reliable way to encrypt this data is an ongoing work item for the TLS Working Group after TLS 1.3 wrapped up. If you have a recent Firefox (possibly only in Nightlies?) you can see one possible approach work with Cloudflare sites which opted in. You will also need encrypted DNS (DPRIVE e.g. DNS over HTTPS) or it's largely pointless.

gwbas1c 7y ago

I still http-only links on Hacker News regularly.

saurik 7y ago

> 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.

sp332 7y ago
It's only a little more data than an passive attacker would have with encrypted wifi.
- saurik 7y ago
  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.
kelnos 7y ago
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.

maltalex 7y ago

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 https://en.wikipedia.org/wiki/DROWN_attack [1]: https://techcrunch.com/2020/01/14/microsoft-critical-certificates-bug/ https://techcrunch.com/2020/01/14/microsoft-critical-certifi... [2]: https://wiki.mozilla.org/CA:Symantec_Issues https://wiki.mozilla.org/CA:Symantec_Issues [3]: https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar

diebeforei485 7y ago

VPN companies have been using the "omg public wifi scary" meme to market their products. I agree with EFF here.

3xblah 7y ago

"So when you visit HTTPS sites, anyone along the communication path - from your ISP to the Internet backbone provider to the site's hosting provider - can see their domain names (e.g. wikipedia.org) and when you visit them." Except wikipedia.org does not require SNI. Most HTTPS sites do not require SNI. Not every client sends SNI by default. OpenSSL's s_client does not. There are others. printf "GET /wiki/MediaWiki HTTP/1.1\r\nHost: en.wikipedia.org\r\nConnection: close\r\n\r\n"|openssl s_client -showcerts -connect mediawiki.org:443 -ign_eof Some sites "require" SNI, but then do not check it against the Host header. A client can send any SNI. The server certificate says *.wikipedia.org. But there are numerous websites sharing the IP addresses for wikipedia.org, not all of them serving Wikipedia content. One example is mediawiki.org. What if a website padded all its pages to be the same size.

badrabbit 7y ago

What is up with these b.s posts about open or public wifi being safe this week? A few days ago there was a twitter thread by a security person at a hotel claimig their open wifi is safe. I won't detail all the many harms you can suffer (or the threats that will readily cause you harm),but let me state just one argument related to eff's silly (and dangerously harmfull ) statement here: 1) when you type in a domain in your navigation bar, your browser attempts to connect to unencrypted http(port 80) 2) if (big if!) The site supports https it will do an http 301 redirect to the https version of the site. 3) An attacker needs to intercept just one such redirect to have an opportunity for credential theft or content injection (downloads,exploits,etc...) 3) your browser does indeed remember these redirects going forward,which is great. 4) Except if you configured your browser to forget all history. Or if you happen to remember a site you visited a while ago (perhaps on a different device) and just typed it in to navigate. Or if you typed in something to search but your browser navigates to it,or many other opportunities for pwnage! 5) you don't care about that? Well attackers are happy to setup a malicious captive portal(captive portal checks are plain http for all browsers I know of) and use that directly or to social engineer installation of an app you "need" to connect (oh,mitmproxy has a nifty captive portal like page you can customize to install a CA cert on the device for TLS interception) I won't even begin to talk about at least half a dozen additional classes of MITM attacks that can be used, even with wpa3 and client isolation! What you have to understand is that vulns that would normally be low severity are amplified in this sort of a network, due to the sheer magnitude of threat exposure. I can't complain about most people being ignorant to good infosec practices(we have to understand+educate) but man this stings! The eff makes one of my favorite extensions HTTPSEverywhere, how can they post this? It takes a long time to educate people about good security practices.

oliwarner 7y ago

This seems like weird advice to give out. Sure, it's not as dangerous as it was... Or is it? All the tools are mature now. Documentation is rife. A seven year old with a Raspberry Pi can set up a hotspot and spike your DNS. This thread contains a litany of security papercuts across the whole stack. DNS, shitty apps, crappy server configs and sites that just don't care. So yeah, it's no 1999. You're probably not getting your FTP password sniffed off a public network these days, but there are still plenty of reasons for me to use 4G or WireGuard instead of trustless networks. Public Wi-Fi will remain firmly on my "list of things to worry about" until I can audit all traffic from my devices.

pvtmert 7y ago

tl:dr; "You would be safe in active war-zone (eg. syria) because you are civillian and do not carry any weapons with you" No, you are not safe at all. Lets assume public wifi requires acceptance of terms and conditions. - Redirects all pages (from your Mac/Ip address) to their server - There is checkbox on the page for ToS/ToC approval and 'Continue' button - Behind the scenes clickjacking/framebusting happens [0] - You get PWNd or monetized. - also being fingerprinted by company. eg: amiunique.org Given conditions, they can inject ads/cookies to track you even after you go away. (eg. at home) [0]: https://blog.innerht.ml/google-yolo/ https://blog.innerht.ml/google-yolo/