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

91–100 of 117 posts

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

#91

Post by RKearney »

lxgr wrote: post #66
RKearney wrote: post #58

Earlier quoted context omitted.

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.

As far as I understand, this is no longer possible on modern iOS versions at least, except if the app developers explicitly disable that validation.

You can pin your certificate in your app bundle such that your app only allows certificates you specify or ones signed by CA's you specify. That clearly isn't the case here. Normal iOS operation will verify the certificate chains up to a trusted root certificate and it is indeed possible to load your own trusted root CAs on to a device for purposes of MITM. Again, some apps may pin their own certificates, but that clearly wasn't happening in this example.

I deal with this virtually every day.

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

#92

Post by duxup »

dkarras wrote: post #52
Amorymeltzer wrote: post #48

> 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 specif…

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 los…

I feel like asking the site to take something down ... is effectively caring about who sees it. Otherwise you wouldn't do that.

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

#93

Post by reaperducer »

air7 wrote: post #53

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 (rightfull…

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.

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

#94

Post by tialaramex »

dastx wrote: post #31
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.

Not necessarily, there are plenty of applications that use their own trusted root CAs and thus technically the app is validating it. Most popular example being Firefox. Often libraries have options to specify trusted root CAs as well as options to disable validation per host and/or globally. I've never come across any library that would have any of these options enabled by default. With that said, apps like banks sho…

Historically it was very common to default disable or entirely omit essential checks. CWE-297 https://cwe.mitre.org/data/definitions/297.html is about this common mistake. The happy path is invariably well tested and doesn't show this, unhappy paths often use garbage self-signed certs which fail non-host based checks and so those behave as expected too. Testing usually misses the host mismatch check.

OpenSSL for years only provided some fairly hairy code if you actually wanted to do dnsName matching, which you absolutely should do. What that means is, lots of software was written (say, 10+ years ago) in which OpenSSL is checking that your peer has a "real" certificate but it doesn't care which one. A certificate for we-are.literally-thieves.example ? Cool, that's issued by a trusted CA and so it's fine. Oh you thought you were connecting to my-real-bank.example? You didn't ask me to check the name on the certificate and I don't bother providing a sensible API to do so anyway.

Here's their actual documentation:

> Versions prior to 1.0.2 did not perform hostname validation. Version 1.0.2 and up contain support for hostname validation, but they still require the user to call a few functions to set it up.

Modern (1.1 onward) releases of OpenSSL provide a sane API which checks names you give it, so if you tell OpenSSL to connect to my-real-bank.example it realises you don't think certificates for other names are OK. But the old ones didn't do that and the ones 10+ years ago expected you to grok PKIX (the Internet's agreed way of coercing the X.509 standard intended for the X.500 series Directory into a way to certify things on the Internet) or else give up.

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

#95

Post by eximius »

GlitchMr wrote: post #7

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

Specifically preload or HSTS?

Because HSTS gets you most of the protection you need while being able to recover if something goes horribly wrong.

Set your HSTS timeout to greater than the gap between user visits and it does prevent active MitM.

You're only unprotected for first time visits being actively intercepted or particularly long gaps where HSTS can expire (both of which are hard targets).

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

#96

Post by tialaramex »

logicallee wrote: post #67

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

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.

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

#98

Post by tialaramex »

schoen wrote: post #73
seeekr wrote: post #50

Earlier quoted context omitted.

What you're asking for already exists. The certbot package already takes care of that [1]. No need to develop anything extra for nginx. [1] https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx

The Certbot team would like to see an official nginx integration at some point because it would be easier and more reliable. Certbot's integration relies on parsing nginx configuration files but the nginx configuration file grammar isn't formally specified and there are surely divergences between nginx's interpretation and Certbot's interpretation. (The last one I worked on, which I don't think we resolved, is that n…

A more neutral stance might be for software to explicitly offer ACME integration rather than Let's Encrypt specifically, after all part of the rationale for Let's Encrypt is to be a huge practical demonstration that ACME can be a success for the public Internet.

e.g. a config setting get-certs-from: ACME-ENDPOINT-URL rather than a binary "Use Let's Encrypt" feature.

Thanks for your work, which is much more important than our enthusiasm.

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

#99

Post by alias_neo »

tialaramex wrote: post #90
alias_neo wrote: post #78

Earlier quoted context omitted.

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 a…

Yes, I agree with all of the above.

We specialise in this sort of thing at my work, I'm not suggesting anyone does this without first understanding the risks you mention above as well as the long term commitment required.

But done right, it is the most secure approach.

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

#100

Post by 3xblah »

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

Post reply on HN