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

31–40 of 117 posts

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

#31

Post by dastx »

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.

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 should still not be putting trust into the OS or anything else. Certificate pinning is a good and should be utilised, especially for sensitive systems such as banks' apps.

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

#32

Post by giancarlostoro »

zzzcpan wrote: post #25
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/…

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

Oh I hadn't known this, I know the configs for Nginx are rather powerful, but didn't realize they were this good. Maybe alternatively somebody could make a web UI to make managing this sort of thing for Nginx simple. Most neckbeards will rage about that, but they don't have to use it.

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

#33

Post by Ajedi32 »

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.

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/ for a great example of that attack in action.

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

#34

Post by mason55 »

giancarlostoro wrote: post #9
kevinsimper wrote: post #3

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.

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

If you’re running nginx on Nix you can do it with just a couple config settings

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

#35

Post by andreareina »

kevinsimper wrote: post #4
resoluteteeth wrote: post #2

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?

You would have to trust a root certificates from your mitm attacker, so it is not a problem.

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.

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

#36

Post by Goz3rr »

zzzcpan wrote: post #25
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/…

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

You still need to reload nginx for it to start using the new certificates. But you're right about issuing/renewing certificates. I have a small snippet like this in all my server blocks:

  location ^~ /.well-known/acme-challenge/ {
    allow all;
    default_type "text/plain";
    root /var/www/letsencrypt;
  }
And to issue a cert (and automatically renew in the future) all I need is:

  acme.sh --issue -w /var/www/letsencrypt/ -d example.com --reloadcmd "service nginx reload"
Although recently I've been using the Cloudflare DNS option also offered by acme.sh instead of webroot mode. It doesn't make any difference in my issue workflow because the domains are already on CF DNS anyways, but it's required for wildcard certs.

I definitely agree in not seeing added the value of a nginx module over my current solution.

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

#38

Post by billyhoffman »

swiley wrote: post #14
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.

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

Honest question... why not?

Modern banks use HTTPS throughout. The banks I use all have HSTS and use preloading so no hijacking to a non-HTTPS site. I use a password manager so if somehow I do get hijacked and get sent to a phishing site, and even if that phishing site is using a Lets Encrypt cert to prevent the “Not Secure” banner in a modern browser, my password manager isn’t going to recognize the domain so it would not let me attempt to log in even if I wanted to.

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

#39

Post by zzzcpan »

Goz3rr wrote: post #36
zzzcpan wrote: post #25

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

You still need to reload nginx for it to start using the new certificates. But you're right about issuing/renewing certificates. I have a small snippet like this in all my server blocks: location ^~ /.well-known/acme-challenge/ { allow all; default_type "text/plain"; root /var/www/letsencrypt; } And to issue a cert (and automatically renew in the future) all I need is: acme.sh --issue -w /var/www/letsencrypt/ -d exam…

Since version 1.16 certificates can be dynamic, no need for reload.

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

#40

Post by jeremy_wiebe »

ben_w wrote: post #8
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.

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

With apps there’s two levels of validation that you can do, and only one is done by the OS.

The most common, and automatic, is the verification of the chain of trust. On iOS this happens automatically if you use the standard network APIs against an HTTPS URL.

You can take it a step further and avoid MITM attacks where the middle party is able to mint trusted certs by doing something called certificate pinning. This is a manual verification that the certificate used by the server you’re connecting to has certain properties that you know match your API server’s.

Post reply on HN