3 ms·

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

by pfg 10y ago

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.

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

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