5 ms·

I wonder how effective HTTPS is against MITM attacks. When I type www.somedomain.com into my browser, it goes to http://www.somedomain.com http://www.somedomain

by TekMol 10y ago

I wonder how effective HTTPS is against MITM attacks. When I type www.somedomain.com into my browser, it goes to http://www.somedomain.com http://www.somedomain.com. If the page then redirects to https://www.somedomain.com https://www.somedomain.com it is too late already. A MITM attacker could intercept my initial request and then proxy everything afterwards. So he would get all the data in clear text. Somebody could probably put an app onto a phone that offers a wifi hotspot and then MITMs everything. By walking around with that phone he would probably capture all kinds of "private" communication all the time. And none of us would know. When I am in an airport and see a hotspot "Free Airport Wifi" I always suspect it is such an app in reality. I mean, everybody can call their hotspot "Free Airport Wifi".

mnx 10y ago
Such an app exists. https://f-droid.org/repository/browse/?fdcategory=Development&fdid=org.csploit.android&fdpage=2 https://f-droid.org/repository/browse/?fdcategory=Developmen...
pfg 10y ago
That's why preloaded HSTS exists - basically a list of domains included in browser binaries that those browser will only ever visit via HTTPS.
- chronial 10y ago
  And it's also why https everywhere is important. If your bank/shop/confidential whatever website isn't accessed via https, you should leave immediately. Once https is close to 100%, browsers could display a warning: "You seem to be entering confidential information on a non-https website. This is probably wrong". (Ironically, IE used to ship with exactly that warning years ago, but they were way too much ahead of their time)
  - pfg 10y ago
    That's a good point, and exactly what Chrome is planning on doing[1]. Firefox has a similar feature for HTTP-only sites using password fields (I think it's currently enabled in Firefox Developer Edition). [1]: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
    - byuu 10y ago
      > Firefox has a similar feature for HTTP-only sites using password fields Man, people really don't think these things through, do they? The end result of making that enabled by default would be that sites start using plaintext for their password fields. Try detecting <input name='password'> and sites start changing it to <input name='p4ssw0rd'> to get around it. Throw warnings on any POST submission and watch sites start using GET for passwords. You can't force people into good practices. You need to make the HTTPS portion so easy that they have to go out of their way to undermine security. Let's Encrypt was a good first start. Now we need at least one competitor to them for free certificates to push innovation forward. And we need Apache and nginx to auto-negotiate TLS certificates and OCSP stapling with zero configuration changes. The default config should opt-in to this, and you'll have to manually disable it. Caddy was a good step there, but nobody uses Caddy. They use Apache, nginx, or IIS.
- TekMol 10y ago
  Wouldn't it be easier to make the browser use https by default? And then if a domain does norespond to a https request ask the user "There seems to be no secure way to communicate with www.somedomain.com - want to switch to insecure?".
  - Edmond 10y ago
    Probably won't sit well with website owners. If you attempt to connect over TLS when it isn't supported, there is a performance impact, basically you have to attempt one failed connection for every http request, do that for every request on a page and performance becomes a big problem. You'll also be going against specs, HTTP should go to port 80( which typically isn't secure.), a browser unilaterally deciding to go against a legitimate user wish is bad form.
    - marcosdumay 10y ago
      Hum... If I explicitly type "http://example.com" http://example.com", then by all means, go to the plaintext site. But everybody just types "example.com" and expects the browser to go to the site - this one should favor the TLS version, not the plaintext one. Besides, now that most sites run on https, making the http-only ones slower would be a good thing.
      - Edmond 10y ago
        I think the current approach of allowing site owners to decide how they're going to support TLS is the right approach, browsers taking it upon themselves to enforce it is a bad idea. Some additional reasons why it is a bad idea have already been mentioned by other folks. When it comes to security, TLS is crucial to the security infrastructure of the internet as a whole; however most of the current security problems on the internet don't actually involve TLS vulnerabilities, even though those tend to make a lot of news in the technology press. The bar for exploiting TLS vulnerabilities generally requires setting up a legitimate seeming entity and injecting yourself into the internet traffic routing infrastructure, it is very much possibly (and indeed easy for state actors) but it is a much higher bar for common cyber criminals.
cbr 10y ago
There are two fixes for this: * Pages can send the Strict-Transport-Security header to tell the client that future visits to them should be HTTPS-only * Pages that send that header can also ask to be included in a list that ships with the browser to handle the first-time visitor case: https://hstspreload.appspot.com/ https://hstspreload.appspot.com/
- byuu 10y ago
  This can also be dangerous. If Globalsign starts sending bad OCSP data again, or your browser vendor blacklists your CA due to bad behavior from the CA (no fault of your own), you'll end up with a site that now can't be accessed at all. Not even to display to the user, "sorry, we're having some technical issues, please check back later", with all the login stuff disabled (and the site using secure cookies by default anyway, so they won't leak in HTTP mode.) It is really difficult for the average user to clear HSTS/HPKP data. You can't just clear your history, you have to go to about:permissions or chrome://net-internals#hsts to do that. Maybe that's the experience you want. But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Public key pinning is even more dangerous. Not the least of which because there are no longer two free providers of SSL certificates for your backup cert. This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. The domain could have a new TXT record of "TLS=Always" that you could flip on or off as needed. The TTL on that could be 3600 seconds instead of 4+ days for a bad OCSP response, or the suggested (by SSL Labs) 6+ months for an HSTS response.
  - pfg 10y ago
    > But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Are you making the argument that a business would want the ability to turn off HTTPS enforcement temporarily in case something like the GlobalSign thing happens? Because I think that's a terrible idea. They should just switch to a different CA, or get the CA to sign a certificate that's not impacted by that issue (which I believe GlobalSign offered). Even excluding Let's Encrypt, the price tag for that is < $10 and it's done in a matter of minutes (and only getting better with ACME). Since we're talking about businesses here, better yet: Have a backup certificate from a different CA ready. This is really no different than all the other things you'll need to do to run a reliable service (like have more than one web server). It's not like one CA screwing up means your domain is dead until they've resolved the issue. Same thing goes for HPKP, since a backup pin is required. Your argument is also not specific to HSTS/HPKP - you're basically saying that HTTPS in general is dangerous for a business because of this. If your site offers HTTPS without HSTS and without redirecting to HTTPS by default, you'd still have users who bookmark HTTPS links, or search engines indexing those links and all of those would also fail, with no way for you to fix it other than switching CAs. > This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. I don't want to get into yet another DNSSEC discussion (that's what we have @tptacek for, anyway), but I don't see a huge difference here. Switching CAs can be done in less time than the TTL you're suggesting. Practically speaking, if you want to factor in "time to find a new CA" or something like that, I'd argue that most people won't run their own DNSSEC infrastructure and rather use something like Cloudflare, so the same "time to find a new <foo>" principle would apply here if they've messed up in a way that takes a long time to resolve.
sgentle 10y ago
If it helps, the attack you're describing is called sslstrip and was presented by Moxie Marlinspike at Black Hat in 2009: https://www.youtube.com/watch?v=MFol6IMbZ7Y https://www.youtube.com/watch?v=MFol6IMbZ7Y (code here: https://moxie.org/software/sslstrip/ https://moxie.org/software/sslstrip/) As others have mentioned, the current best defence against this is HSTS (and, in particular, HSTS preloading). I think the best explanation of it is here: https://www.chromium.org/hsts/ https://www.chromium.org/hsts/

by TekMol 10y ago

mnx 10y ago

Such an app exists. https://f-droid.org/repository/browse/?fdcategory=Development&fdid=org.csploit.android&fdpage=2 https://f-droid.org/repository/browse/?fdcategory=Developmen...

pfg 10y ago

That's why preloaded HSTS exists - basically a list of domains included in browser binaries that those browser will only ever visit via HTTPS.

chronial 10y ago
And it's also why https everywhere is important. If your bank/shop/confidential whatever website isn't accessed via https, you should leave immediately. Once https is close to 100%, browsers could display a warning: "You seem to be entering confidential information on a non-https website. This is probably wrong". (Ironically, IE used to ship with exactly that warning years ago, but they were way too much ahead of their time)
- pfg 10y ago
  That's a good point, and exactly what Chrome is planning on doing[1]. Firefox has a similar feature for HTTP-only sites using password fields (I think it's currently enabled in Firefox Developer Edition). [1]: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
  - byuu 10y ago
    > Firefox has a similar feature for HTTP-only sites using password fields Man, people really don't think these things through, do they? The end result of making that enabled by default would be that sites start using plaintext for their password fields. Try detecting <input name='password'> and sites start changing it to <input name='p4ssw0rd'> to get around it. Throw warnings on any POST submission and watch sites start using GET for passwords. You can't force people into good practices. You need to make the HTTPS portion so easy that they have to go out of their way to undermine security. Let's Encrypt was a good first start. Now we need at least one competitor to them for free certificates to push innovation forward. And we need Apache and nginx to auto-negotiate TLS certificates and OCSP stapling with zero configuration changes. The default config should opt-in to this, and you'll have to manually disable it. Caddy was a good step there, but nobody uses Caddy. They use Apache, nginx, or IIS.
TekMol 10y ago
Wouldn't it be easier to make the browser use https by default? And then if a domain does norespond to a https request ask the user "There seems to be no secure way to communicate with www.somedomain.com - want to switch to insecure?".
- Edmond 10y ago
  Probably won't sit well with website owners. If you attempt to connect over TLS when it isn't supported, there is a performance impact, basically you have to attempt one failed connection for every http request, do that for every request on a page and performance becomes a big problem. You'll also be going against specs, HTTP should go to port 80( which typically isn't secure.), a browser unilaterally deciding to go against a legitimate user wish is bad form.
  - marcosdumay 10y ago
    Hum... If I explicitly type "http://example.com" http://example.com", then by all means, go to the plaintext site. But everybody just types "example.com" and expects the browser to go to the site - this one should favor the TLS version, not the plaintext one. Besides, now that most sites run on https, making the http-only ones slower would be a good thing.
    - Edmond 10y ago
      I think the current approach of allowing site owners to decide how they're going to support TLS is the right approach, browsers taking it upon themselves to enforce it is a bad idea. Some additional reasons why it is a bad idea have already been mentioned by other folks. When it comes to security, TLS is crucial to the security infrastructure of the internet as a whole; however most of the current security problems on the internet don't actually involve TLS vulnerabilities, even though those tend to make a lot of news in the technology press. The bar for exploiting TLS vulnerabilities generally requires setting up a legitimate seeming entity and injecting yourself into the internet traffic routing infrastructure, it is very much possibly (and indeed easy for state actors) but it is a much higher bar for common cyber criminals.

cbr 10y ago

There are two fixes for this: * Pages can send the Strict-Transport-Security header to tell the client that future visits to them should be HTTPS-only * Pages that send that header can also ask to be included in a list that ships with the browser to handle the first-time visitor case: https://hstspreload.appspot.com/ https://hstspreload.appspot.com/

byuu 10y ago
This can also be dangerous. If Globalsign starts sending bad OCSP data again, or your browser vendor blacklists your CA due to bad behavior from the CA (no fault of your own), you'll end up with a site that now can't be accessed at all. Not even to display to the user, "sorry, we're having some technical issues, please check back later", with all the login stuff disabled (and the site using secure cookies by default anyway, so they won't leak in HTTP mode.) It is really difficult for the average user to clear HSTS/HPKP data. You can't just clear your history, you have to go to about:permissions or chrome://net-internals#hsts to do that. Maybe that's the experience you want. But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Public key pinning is even more dangerous. Not the least of which because there are no longer two free providers of SSL certificates for your backup cert. This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. The domain could have a new TXT record of "TLS=Always" that you could flip on or off as needed. The TTL on that could be 3600 seconds instead of 4+ days for a bad OCSP response, or the suggested (by SSL Labs) 6+ months for an HSTS response.
- pfg 10y ago
  > But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Are you making the argument that a business would want the ability to turn off HTTPS enforcement temporarily in case something like the GlobalSign thing happens? Because I think that's a terrible idea. They should just switch to a different CA, or get the CA to sign a certificate that's not impacted by that issue (which I believe GlobalSign offered). Even excluding Let's Encrypt, the price tag for that is < $10 and it's done in a matter of minutes (and only getting better with ACME). Since we're talking about businesses here, better yet: Have a backup certificate from a different CA ready. This is really no different than all the other things you'll need to do to run a reliable service (like have more than one web server). It's not like one CA screwing up means your domain is dead until they've resolved the issue. Same thing goes for HPKP, since a backup pin is required. Your argument is also not specific to HSTS/HPKP - you're basically saying that HTTPS in general is dangerous for a business because of this. If your site offers HTTPS without HSTS and without redirecting to HTTPS by default, you'd still have users who bookmark HTTPS links, or search engines indexing those links and all of those would also fail, with no way for you to fix it other than switching CAs. > This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. I don't want to get into yet another DNSSEC discussion (that's what we have @tptacek for, anyway), but I don't see a huge difference here. Switching CAs can be done in less time than the TTL you're suggesting. Practically speaking, if you want to factor in "time to find a new CA" or something like that, I'd argue that most people won't run their own DNSSEC infrastructure and rather use something like Cloudflare, so the same "time to find a new <foo>" principle would apply here if they've messed up in a way that takes a long time to resolve.

sgentle 10y ago

If it helps, the attack you're describing is called sslstrip and was presented by Moxie Marlinspike at Black Hat in 2009: https://www.youtube.com/watch?v=MFol6IMbZ7Y https://www.youtube.com/watch?v=MFol6IMbZ7Y (code here: https://moxie.org/software/sslstrip/ https://moxie.org/software/sslstrip/) As others have mentioned, the current best defence against this is HSTS (and, in particular, HSTS preloading). I think the best explanation of it is here: https://www.chromium.org/hsts/ https://www.chromium.org/hsts/