4 ms·

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 si

by st3fan 15y ago

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-security-has.html http://blog.sidstamm.com/2010/08/http-strict-transport-secur...

tptacek 15y ago
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.
- mike-cardwell 15y ago
  That is not the only problem it solves. You can go to https://news.ycombinator.com/ 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.
  - tptacek 15y ago
    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)
    - mike-cardwell 15y ago
      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.
      - tptacek 15y ago
        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.
        mike-cardwell 15y ago
        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.
        tptacek 15y ago
        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.
        mike-cardwell 15y ago
- st3fan 15y ago
  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.
  - mike-cardwell 15y ago
    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

by st3fan 15y ago

tptacek 15y ago

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.

mike-cardwell 15y ago
That is not the only problem it solves. You can go to https://news.ycombinator.com/ 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.
- tptacek 15y ago
  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)
  - mike-cardwell 15y ago
    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.
    - tptacek 15y ago
      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.
      - mike-cardwell 15y ago
        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.
        tptacek 15y ago
        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.
        mike-cardwell 15y ago
st3fan 15y ago
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.
- mike-cardwell 15y ago
  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