Is Your Site HSTS Enabled?
blog.nvisium.com
Is Your Site HSTS Enabled?
1–10 of 31 posts
Re: Is Your Site HSTS Enabled?
#2Sadly 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 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.
Re: Is Your Site HSTS Enabled?
#3Sadly 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 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.
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:// 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.
Re: Is Your Site HSTS Enabled?
#4Is 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.
Re: Is Your Site HSTS Enabled?
#5Is 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.
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/tr...
[1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
Re: Is Your Site HSTS Enabled?
#6You 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..
Re: Is Your Site HSTS Enabled?
#7You 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..
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.
Re: Is Your Site HSTS Enabled?
#8Yes! 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!
Re: Is Your Site HSTS Enabled?
#9HSTS 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.
Re: Is Your Site HSTS Enabled?
#10HSTS 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 insp…
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.