Hacker News Reader

Comment by st3fan | Hacker News Reader

This is great. It would be even better if HN would use the Strict-Transport-Security header so that browser remember to prefer https instead of http for this site.

See http://blog.sidstamm.com/2010/08/http-strict-transport-secur...

View on HN

If they were taking credit card numbers, STS would be worth the trouble; otherwise, it's not something I'd recommend going out of your way for.

For non- HTTPS- nerds: STS resolves the problem where your first contact with a site is via (insecure) HTTP, and a MITM makes all subsequent contacts lie to you about whether HTTPS is available. Since we've lasted many years without even having HTTPS, I think we can all just look at the address bar carefully instead.

That is not the only problem it solves. You can go to https://news.ycombinator.com/, but if you visit any other non-https website at the same time, somebody can MITM that connection, and inject the following HTML into it:

  <img src="http://news.ycombinator.com/">

That will cause your browser to do a non-https request against news.ycombinator.com (unless STS is implemented), which in this particular case can leak the session cookie, because the session cookie hasn't had the "secure" flag set on it.

I'd say that it is worth going out of your way for. If you're implementing HTTPS, it is only slightly more effort to implement STS as well. And it's definitely worth adding the secure flag to the cookie as well.

Not having the secure flag on a cookie (I didn't look, because I don't care about SSL on HN) is a vulnerability. STS doesn't totally fix that vulnerability.

STS: Nice to have. Most installed browsers don't even support it.

Cookie Secure flag: Must have. Every modern browser supports it to some extent.

You're entitled to your opinion about this stuff, but know that my opinion has been hardened by many many years doing appsec for financial services companies. I would not doc a company for not having STS†, unless I was doing design/best practices review. I would doc anybody for not setting the secure flag on cookies for an HTTPS site.

† (ie: if you ask me to doc stuff like STS and Clickjacking)

Thank you for acknowledging my right to an opinion, although I'm not sure why it was needed. I don't think your credentials put you in a better position to comment on this particular matter, but you're still entitled to your opinion anyway.

It takes very little effort to implement STS, and there are significant tangible benefits from doing so. For this reason alone, I would recommend that all HTTPS sites use it. I acknowledge that using the "secure" flag with cookies provides a bigger benefit though.

Saying "you have a right to your opinion" sounds better than "I'm pretty sure you're just totally wrong about this", doesn't it? :)

HN doesn't have a framebuster either, but you didn't call them out on that. The security nerds we work with are far more likely to call us out for not hyperventilating about clickjacking than about HSTS, which, again, is not widely supported in the field to begin with.

There are actual apparent problems with HN's HTTPS; it will for instance happily do SSLv2 with 40 bit RC4. Let's advocate for those fixes first.

It's more passive-aggressive certainly. The SSL config does need tuning, and frame busters adding. That doesn't make STS any less important.

No modern browser is going to choose such a weak cipher, but because SSLv2 is enabled, a MITM can force it. The same MITM who can abuse the lack of STS.

The equivalence you're drawing between what a MITM can do with STS and what a MITM can do with SSLv2 is an objectively false one.

I think you've gone on tilt on this issue, so, feel free to the last word.

I'd prefer if you could educate me on how I'm wrong? I was referring to the ability of a MITM to attack the initial negotiation with a downgrade attack on SSLv2. Modern browsers aren't susceptible to this unless I'm mistaken?

All modern browsers are susceptible to the other MITM attack I described though. Unless the website uses STS.

EDIT: It's worth noting that anybody using IE7+, FF2+, Opera, Chrome or Safari aren't affected be the weak ciphers, or by the existence of SSLv2, as their browsers will not negotiate a weak SSL connection. They are all affected by the lack of STS though.

No, because IE7+, FF2+, Opera, and Safari don't support HSTS. New Firefox does, and Chrome does.

Good catch. Although, when comparing an issue that affects no modern browser against an issue which affects all modern browsers, the issue which affects all modern browsers is perhaps a little more important.

And when there's a solution that is trivial to implement, and can fix the issue for two existing major modern browsers (probably more to come), it might not be a completely crazy idea to go ahead and implement it.

P.S. Thank you for graciously gifting me the final word

Funny. The 'trouble' is not more than adding a single header:

Strict-Transport-Security: max-age=604800

And that is it. Your browser now prefers to use https for your web site. That was really not that much trouble, was it?

Also, https is not just for banking. I like it when people cannot see what I am doing online. Whether that is online banking, doing a google search or writing a posting on hackernews.

It's worth noting, that if you can, you should include the "includeSubDomains" flag with STS:

  Strict-Transport-Security: max-age=604800, includeSubDomains

The reason for this is, somebody controlling the network could create a fake DNS A record for "foobar.news.ycombinator.com", and then stick this into the html of another unrelated non-https page that you go to:

  <img src="http://foobar.news.ycombinator.com/">

Which then may leak the news.ycombinator.com cookie over http, as the STS would only have applied to news.ycombinator.com and not foobar.news.ycombinator.com

Reply on news.ycombinator.com