5 ms·

Is Your Site HSTS Enabled?

49 points by gellerb 12y ago

dingaling 12y ago
Sadly not, because I haven't yet understood the interaction of HSTS and old plain-HTTP URLs. What happens when a browser goes to retrieve, say, an image at http://example.com/img223.JPEG http://example.com/img223.JPEG but the server now enforces HSTS and pulls-up TLS? When I've tried this with a subsite the image fails to load, and I haven't yet had time to investigate why. Perhaps I should just draw a line and let the old URLs break.
- azdle 12y ago
  My understanding is that HSTS is purely for the client side. You can still have a server that serves http if you want, but any client that supports HSTS that has visited your domain since you started sending the header will simply add tls to any http:// http:// link that it comes across. So your image link can still be served, but if the client does support HSTS it'll see the header and then make all subsequent requests over TLS.
Nikker 12y ago
Is this a different implementation of Diffie–Hellman? As far as I can tell (and I am likely wrong) there needs to be one successful connection attempt using a secure protocol, in this case HSTS, to detect if the redirect was indeed to the correct site or a MitM attack.
- azdle 12y ago
  HSTS isn't a protocol, it bascailly a flag that tells a browser to only use TLS to connect to a specfic domain. It normally does require one successful connection for the server to tell it, but both chrome [0] and firefox [1] have a list of sites built-in so that even the first time they connect they'd be TLS. [0] https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr... [1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
gnur 12y ago
You almost never want to also include the subdomains, unless you have a wildcard SSL certificate. I made that mistake, couldn't reach any other subdomain of my site because only 1 was protected by ssl. Clearing that HSTS header information is not so easy..
- ivanr 12y ago
  Well, it depends. You shouldn't include subdomains if you have some that do not support HTTPS. That would be an instant self-inflicted denial of service attack. However, for best security, you must include subdomains. Because the cookie specification is very lax, any subdomain can inject cookies into your otherwise protected (with TLS and HSTS) site. This injection, which will be seen as unexpected by developers, might be used as an attack vector. Note that, even if you don't have any subdomains, a MITM -- who controls the wire and thus the DNS -- can always make up arbitrary names and then inject from them. There are other smaller attack vectors that can be abused unless the entire domain name (e.g., example.com) is under HSTS.
digitalsushi 12y ago
Yes! And boy, it's not something you want to just enable without some thought. I enabled it on a site that works without Host: inspection. HTTP gets you site A, and HTTPS gets you site B. (Different hostnames). This is obviously an odd arrangement, but it was working well for our little niche requirement. I enabled HSTS in nginx while I was scrambling to do the heartbleed patch. I enabled all sorts of new age HTTPS options: HSTS, cert stapling, heavier ciphersuites, et cetera. Of course, the HSTS started forcing all my HTTP users on site A over to site B, and I looked quite the fool. (Which is fair, because what I did was foolish and I deserved a little ridicule) It's a neat option and maybe even the base case allows for it, but think about it before you flip it on!
- abarth 12y ago
  I'd recommend starting out with a small max-age value so that any mistaken records will expire quickly. (Disclosure: I'm a co-editor of the HSTS RFC.)
  - gellerb 12y ago
    Yeah. I noticed that paypal.com has a max-age of 4 hours.
    - rhoml 12y ago
      Maybe the first step to avoid issues is to enforce SSL which is easy on any webserver before going HSTS.
      - d0ugie 12y ago
        Is there any downside, when using SSL, in enabling perfect forward secrecy?
        JshWright 12y ago
        Make sure you're using an SSL library that support ECDHE cipher suites... the non EC suites are very slow.
henrikschroder 12y ago
HSTS is a good concept, and all browsers implement it, but there's no way to inspect which domains are flagged with it in your browser. So if you pick one up by mistake when you're testing the feature out in development, it just sticks, and the only way to get rid of it is to clear your entire browser cache or reset it, which is extremely annoying. Browser makers: Please, please, please implement a way for me to inspect and remove individual HSTS "flags" so testing it doesn't become so painful.
- abarth 12y ago
  Chrome lets you see some of the HSTS internals: chrome://net-internals/#hsts There's no list of HSTS hosts because the host names are hashed on disk.
  - henrikschroder 12y ago
    Thanks!
- gellerb 12y ago
  In Safari one can delete ~/Library/Cookies/HSTS.plist
ds9 12y ago
If you are using a site-signed cert and giving intended visitors a corresponding browser cert (being your own CA), and turn on HSTS, I assume the non-bypassable warning page would not be triggered, and the author's reference to "self-signed certs" is an inaccurate shorthand for "site certs the browser doesn't trust a CA for". (If this interpretation is wrong, HSTS would prevent a secure connection in this scenario.) And if your server is rewriting URLs instead of using 301, then clients are not vulnerable to the redirect loophole and HSTS gives no benefit in that respect?
- gellerb 12y ago
  ds9, yes, "site certs the browser doesn't trust a CA for" is more accurate. You can find the exact details of HSTS and self-signed certs in the draft in section 11.3[1]. I've updated the post to hopefully be more clear. [1] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-14#section-11.3 http://tools.ietf.org/html/draft-ietf-websec-strict-transpor...
devx 12y ago
In 2014, everyone who uses https should enable PFS (ECDHE) and HSTS, at the very least.
- eliot_sykes 12y ago
  If you're on shared hosting, is it down to the hosting company to enable Forward Secrecy? Are there any shared hosts doing this yet?
  - gellerb 12y ago
    Elastic Loading Balancing for AWS customers & Heroku allow for perfect forward secrecy and Akamai customers can expect ECDHE in Q3 of this year.
    - eliot_sykes 12y ago
      Is there anything you need to do to enable it on Heroku, other than setup SSL/TLS?
      - gellerb 12y ago
        ssl:endpoint add-on
peterwwillis 12y ago
HSTS should be an implicit browser feature, not a server-side add-on. There should not need to be a server-side flag required to enforce this behavior. If you go to an HTTPS page on a given domain, your browser should always prefer the HTTPS page, even if you try to follow an HTTP page. The reason is, if you were able to reach the page via HTTPS before, you should be able to reach it there again, and HTTP would only expose you to an unencrypted page which is more than likely the same in content. The only downside is that sometimes HTTPS and HTTP URIs serve different resources even though the URI is the same (which I believe should be considered bad behavior by the web server) Requiring admins to enable HSTS puts the onus on web server admins who are motivated to improve security for their users a tiny bit, and only works for admins who have servers that can support HSTS flags. There are many legacy systems which simply can't or won't be changed to support it. Hopefully the above behavior gets put into the HTTP 2.0 standard so admins don't need to go through a checkist of add-on security measures every time they create a new web server instance.
- gellerb 12y ago
  The HTTP 2.0 spec[1] mentions "Implementations of HTTP/2 MUST support TLS 1.2 and it appears Chrome will implement HTTP/2 via TLS only (http://volgarev.me/blog/75094931827 http://volgarev.me/blog/75094931827).
eliot_sykes 12y ago
Good to see the word is spreading about HSTS. EFF started pushing it earlier this month [1], with a perhaps fair claim that it's not widely known about by web developers. As the article shows it's pretty straightforward to setup; if you can add a response header to your app then you'll be able to figure out how to harden your app with HSTS. For my fellow web developers who like to learn by video, I've tried to make an easily digested screencast and a page of sketch notes to help get the word out about HSTS and explain what it protects against [2]. [1] https://www.eff.org/deeplinks/2014/02/websites-hsts https://www.eff.org/deeplinks/2014/02/websites-hsts [2] http://www.webdevbreak.com/episodes/hsts http://www.webdevbreak.com/episodes/hsts
micro-ram 12y ago
These settings are giving me an A+ on SSLLabs.com... # - Apache 2.4 PFS & BEAST attack Safe /etc/apache2/mods-enabled/ssl.conf SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:!RC4:HIGH:!MD5:!aNULL:!EDH SSLHonorCipherOrder on SSLCompression off # - HSTS Apache directive to force SSL (.htaccess or per site in control panel) Header always set Strict-Transport-Security "max-age=15552000" RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]
- fmx 12y ago
  I tried that cipher suite list with Apache 2.2 and got my grade reduced from A to A-: The server does not support Forward Secrecy with the reference browsers. Grade reduced to A- Maybe I need to upgrade to Apache 2.4.
  - micro-ram 12y ago
    Yes, upgrade Apache. These settings are for Apache 2.4
- schneid 12y ago
  Note that you shouldn't send the STS header for http:// http:// responses: http://tools.ietf.org/html/rfc6797#section-7.2 http://tools.ietf.org/html/rfc6797#section-7.2

49 points by gellerb 12y ago

Sadly not, because I haven't yet understood the interaction of HSTS and old plain-HTTP URLs. What happens when a browser goes to retrieve, say, an image at http://example.com/img223.JPEG http://example.com/img223.JPEG but the server now enforces HSTS and pulls-up TLS? When I've tried this with a subsite the image fails to load, and I haven't yet had time to investigate why. Perhaps I should just draw a line and let the old URLs break.

azdle 12y ago
My understanding is that HSTS is purely for the client side. You can still have a server that serves http if you want, but any client that supports HSTS that has visited your domain since you started sending the header will simply add tls to any http:// http:// link that it comes across. So your image link can still be served, but if the client does support HSTS it'll see the header and then make all subsequent requests over TLS.

Nikker 12y ago

Is this a different implementation of Diffie–Hellman? As far as I can tell (and I am likely wrong) there needs to be one successful connection attempt using a secure protocol, in this case HSTS, to detect if the redirect was indeed to the correct site or a MitM attack.

azdle 12y ago
HSTS isn't a protocol, it bascailly a flag that tells a browser to only use TLS to connect to a specfic domain. It normally does require one successful connection for the server to tell it, but both chrome [0] and firefox [1] have a list of sites built-in so that even the first time they connect they'd be TLS. [0] https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr... [1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/ https://blog.mozilla.org/security/2012/11/01/preloading-hsts...

gnur 12y ago

You almost never want to also include the subdomains, unless you have a wildcard SSL certificate. I made that mistake, couldn't reach any other subdomain of my site because only 1 was protected by ssl. Clearing that HSTS header information is not so easy..

ivanr 12y ago
Well, it depends. You shouldn't include subdomains if you have some that do not support HTTPS. That would be an instant self-inflicted denial of service attack. However, for best security, you must include subdomains. Because the cookie specification is very lax, any subdomain can inject cookies into your otherwise protected (with TLS and HSTS) site. This injection, which will be seen as unexpected by developers, might be used as an attack vector. Note that, even if you don't have any subdomains, a MITM -- who controls the wire and thus the DNS -- can always make up arbitrary names and then inject from them. There are other smaller attack vectors that can be abused unless the entire domain name (e.g., example.com) is under HSTS.

digitalsushi 12y ago

Yes! And boy, it's not something you want to just enable without some thought. I enabled it on a site that works without Host: inspection. HTTP gets you site A, and HTTPS gets you site B. (Different hostnames). This is obviously an odd arrangement, but it was working well for our little niche requirement. I enabled HSTS in nginx while I was scrambling to do the heartbleed patch. I enabled all sorts of new age HTTPS options: HSTS, cert stapling, heavier ciphersuites, et cetera. Of course, the HSTS started forcing all my HTTP users on site A over to site B, and I looked quite the fool. (Which is fair, because what I did was foolish and I deserved a little ridicule) It's a neat option and maybe even the base case allows for it, but think about it before you flip it on!

abarth 12y ago
I'd recommend starting out with a small max-age value so that any mistaken records will expire quickly. (Disclosure: I'm a co-editor of the HSTS RFC.)
- gellerb 12y ago
  Yeah. I noticed that paypal.com has a max-age of 4 hours.
  - rhoml 12y ago
    Maybe the first step to avoid issues is to enforce SSL which is easy on any webserver before going HSTS.
    - d0ugie 12y ago
      Is there any downside, when using SSL, in enabling perfect forward secrecy?
      - JshWright 12y ago
        Make sure you're using an SSL library that support ECDHE cipher suites... the non EC suites are very slow.

henrikschroder 12y ago

HSTS is a good concept, and all browsers implement it, but there's no way to inspect which domains are flagged with it in your browser. So if you pick one up by mistake when you're testing the feature out in development, it just sticks, and the only way to get rid of it is to clear your entire browser cache or reset it, which is extremely annoying. Browser makers: Please, please, please implement a way for me to inspect and remove individual HSTS "flags" so testing it doesn't become so painful.

abarth 12y ago
Chrome lets you see some of the HSTS internals: chrome://net-internals/#hsts There's no list of HSTS hosts because the host names are hashed on disk.
- henrikschroder 12y ago
  Thanks!
gellerb 12y ago
In Safari one can delete ~/Library/Cookies/HSTS.plist

ds9 12y ago

If you are using a site-signed cert and giving intended visitors a corresponding browser cert (being your own CA), and turn on HSTS, I assume the non-bypassable warning page would not be triggered, and the author's reference to "self-signed certs" is an inaccurate shorthand for "site certs the browser doesn't trust a CA for". (If this interpretation is wrong, HSTS would prevent a secure connection in this scenario.) And if your server is rewriting URLs instead of using 301, then clients are not vulnerable to the redirect loophole and HSTS gives no benefit in that respect?

gellerb 12y ago
ds9, yes, "site certs the browser doesn't trust a CA for" is more accurate. You can find the exact details of HSTS and self-signed certs in the draft in section 11.3[1]. I've updated the post to hopefully be more clear. [1] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-14#section-11.3 http://tools.ietf.org/html/draft-ietf-websec-strict-transpor...

devx 12y ago

In 2014, everyone who uses https should enable PFS (ECDHE) and HSTS, at the very least.

eliot_sykes 12y ago
If you're on shared hosting, is it down to the hosting company to enable Forward Secrecy? Are there any shared hosts doing this yet?
- gellerb 12y ago
  Elastic Loading Balancing for AWS customers & Heroku allow for perfect forward secrecy and Akamai customers can expect ECDHE in Q3 of this year.
  - eliot_sykes 12y ago
    Is there anything you need to do to enable it on Heroku, other than setup SSL/TLS?
    - gellerb 12y ago
      ssl:endpoint add-on

peterwwillis 12y ago

HSTS should be an implicit browser feature, not a server-side add-on. There should not need to be a server-side flag required to enforce this behavior. If you go to an HTTPS page on a given domain, your browser should always prefer the HTTPS page, even if you try to follow an HTTP page. The reason is, if you were able to reach the page via HTTPS before, you should be able to reach it there again, and HTTP would only expose you to an unencrypted page which is more than likely the same in content. The only downside is that sometimes HTTPS and HTTP URIs serve different resources even though the URI is the same (which I believe should be considered bad behavior by the web server) Requiring admins to enable HSTS puts the onus on web server admins who are motivated to improve security for their users a tiny bit, and only works for admins who have servers that can support HSTS flags. There are many legacy systems which simply can't or won't be changed to support it. Hopefully the above behavior gets put into the HTTP 2.0 standard so admins don't need to go through a checkist of add-on security measures every time they create a new web server instance.

gellerb 12y ago
The HTTP 2.0 spec[1] mentions "Implementations of HTTP/2 MUST support TLS 1.2 and it appears Chrome will implement HTTP/2 via TLS only (http://volgarev.me/blog/75094931827 http://volgarev.me/blog/75094931827).

eliot_sykes 12y ago

Good to see the word is spreading about HSTS. EFF started pushing it earlier this month [1], with a perhaps fair claim that it's not widely known about by web developers. As the article shows it's pretty straightforward to setup; if you can add a response header to your app then you'll be able to figure out how to harden your app with HSTS. For my fellow web developers who like to learn by video, I've tried to make an easily digested screencast and a page of sketch notes to help get the word out about HSTS and explain what it protects against [2]. [1] https://www.eff.org/deeplinks/2014/02/websites-hsts https://www.eff.org/deeplinks/2014/02/websites-hsts [2] http://www.webdevbreak.com/episodes/hsts http://www.webdevbreak.com/episodes/hsts

micro-ram 12y ago

These settings are giving me an A+ on SSLLabs.com... # - Apache 2.4 PFS & BEAST attack Safe /etc/apache2/mods-enabled/ssl.conf SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:!RC4:HIGH:!MD5:!aNULL:!EDH SSLHonorCipherOrder on SSLCompression off # - HSTS Apache directive to force SSL (.htaccess or per site in control panel) Header always set Strict-Transport-Security "max-age=15552000" RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

fmx 12y ago
I tried that cipher suite list with Apache 2.2 and got my grade reduced from A to A-: The server does not support Forward Secrecy with the reference browsers. Grade reduced to A- Maybe I need to upgrade to Apache 2.4.
- micro-ram 12y ago
  Yes, upgrade Apache. These settings are for Apache 2.4
schneid 12y ago
Note that you shouldn't send the STS header for http:// http:// responses: http://tools.ietf.org/html/rfc6797#section-7.2 http://tools.ietf.org/html/rfc6797#section-7.2