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

71–80 of 117 posts

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

#71

Post by gruez »

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…

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

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

#72

Post by EduardoBautista »

JohnFen wrote: post #60

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.

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

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

#73

Post by schoen »

seeekr wrote: post #50
giancarlostoro wrote: post #9

Earlier quoted context omitted.

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

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 nginx allows you to use arbitrary character encodings in configuration files, e.g. many Russian users may have comments in KOI8-R rather than UTF-8. I believe this is because nginx doesn't make a consistent attempt to explicitly interpret multibyte characters in all contexts. Certbot, as a Python application, generally does nowadays.)

The most sustainable and reliable long-term approach would be to have Certbot's integrations gradually superseded by supported official Let's Encrypt integrations in applications that terminate TLS.

P.S. Thanks for your enthusiasm for Certbot!

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

#74

Post by dwild »

numpad0 wrote: post #19
swiley wrote: post #14

Earlier quoted context omitted.

While you’re probably not going to be instantly attacked, I still wouldn’t do online banking on a public network.

Every commercial network is a public network in a sense

In a boolean sense sure, but the world is more complex that true or false, and some are more public than others.

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

#75

Post by danShumway »

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…

> But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic)

This is... not entirely wrong, but overly simplified. My impression is that TLS fingerprinting is sometimes-to-often good enough to figure out which exact page of a static website that a user is visiting[0].

That's not to say TLS is useless, or that the fingerprinting isn't hard enough that some adversaries won't just give up, it's just that the protections are more complicated, and it's not quite as simple as just saying, "I have TLS, I'm fine."

[0]: http://rabexc.org/posts/guessing-tls-pages

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

#76

Post by alias_neo »

mping wrote: post #5

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.

A problem I see quite regularly is self-CA is an afterthought, many don't write their software for self-CA and so when people have issues, the top answer is "turn off verification".

Between that, and the number of "important" pieces of software that don't certificate pin, it really rubs me the wrong way.

Many people have no idea that any one of the CAs installed in your browser or device can sign a certificate for any domain and most software won't care.

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

#78

Post by alias_neo »

knute wrote: post #11
ben_w wrote: post #8

Earlier quoted context omitted.

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

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 certificate or specific authority, so, for e.g. it was signed by Let's Encrypt X with fingerprint Y and not, say, Digicert Z with fingerprint A.

If you're writing the backend and frontend, yor could go one step further and embed your own CA in the app and follow secure practice for managing the private key and issuing certificates to your infrastructure.

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

#79

Post by alias_neo »

iso1631 wrote: post #16
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.

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

MitM is pretty difficult if your app is validating, a lot of corps will install their in-house CA on your company issue devices so they can do this. If your software is using certificate pinning they can't even do this.

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

#80

Post by sneak »

mping wrote: post #5

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.

Passive attacks from open wi-fi allowing everyone in 100m range to read your traffic and active MITM are entirely different classes of attacks, with entirely different barriers to entry.
Post reply on HN