Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Your Site HSTS Enabled?

blog.nvisium.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: Is Your Site HSTS Enabled?

#11

Post by abarth »

digitalsushi wrote: post #8

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

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

Re: Is Your Site HSTS Enabled?

#12

Post by henrikschroder »

abarth wrote: post #10
henrikschroder wrote: post #9

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

Thanks!

Re: Is Your Site HSTS Enabled?

#13

Post by ds9 »

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?

Re: Is Your Site HSTS Enabled?

#15

Post by gellerb »

abarth wrote: post #11
digitalsushi wrote: post #8

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

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

Yeah. I noticed that paypal.com has a max-age of 4 hours.

Re: Is Your Site HSTS Enabled?

#16

Post by gellerb »

henrikschroder wrote: post #9

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

In Safari one can delete ~/Library/Cookies/HSTS.plist

Re: Is Your Site HSTS Enabled?

#17

Post by gellerb »

ds9 wrote: post #13

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

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

Re: Is Your Site HSTS Enabled?

#18

Post by rhoml »

gellerb wrote: post #15
abarth wrote: post #11

Earlier quoted context omitted.

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

Yeah. I noticed that paypal.com has a max-age of 4 hours.

Maybe the first step to avoid issues is to enforce SSL which is easy on any webserver before going HSTS.

Re: Is Your Site HSTS Enabled?

#19

Post by d0ugie »

rhoml wrote: post #18
gellerb wrote: post #15

Earlier quoted context omitted.

Yeah. I noticed that paypal.com has a max-age of 4 hours.

Maybe the first step to avoid issues is to enforce SSL which is easy on any webserver before going HSTS.

Is there any downside, when using SSL, in enabling perfect forward secrecy?

Re: Is Your Site HSTS Enabled?

#20

Post by peterwwillis »

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.

Post reply on HN