Living with HTTPS
imperialviolet.org
Living with HTTPS
1–10 of 132 posts
Re: Living with HTTPS
#2Moxie published a tool called SSLstrip http://www.thoughtcrime.org/software/sslstrip/ here's a simple video demonstration https://www.youtube.com/watch?v=PmtkJKHFX5Q
Re: Living with HTTPS
#3For users, HTTPS Everywhere is a must: https://www.eff.org/https-everywhere
Also, by using DuckDuckGo [1] over HTTPS you get the same ruleset in HTTPS Everywhere [2] even if you don't have the extension installed.
[2] http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-imple...
Re: Living with HTTPS
#4This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped to startups, down to the order in which he gives the advice:
* Enable HSTS
* Don't link to HTTP:// javascript resources from HTTPS pages
* Set the secure flag on cookies
Very few of the sites we test enable HSTS. But it's easy to do; it's just an extra header you set.
The only quibble I might have is the fatalism he has about mixed-security Javascript links. I'd go further than he does: when you source Javascript from a third party, you have leased your users security out to that third party. Don't like the way that sounds? Doesn't matter: it's a fact. Companies should radically scale back the number of third parties that they allow to "bug" their pages.
Re: Living with HTTPS
#5The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers?
In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.
Re: Living with HTTPS
#6> There's a second collarary to this: attackers can set your HTTPS cookies too.
If your app uses session ID cookies, then another implication of this is that attackers can set a user's session ID to a value they know, wait for the user to log in, and then use the session ID to hijack the logged-in session. To prevent this make sure you regenerate session IDs when logging a user in. (This isn't the only reason to regenerate session IDs on log in but it's a very compelling one.)
Re: Living with HTTPS
#7The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers? In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.
No, that's not how STS works. Once the header is set, a MITM can't simply clear the header; the purpose of STS is to tell the browser to remember that the site is HTTPS-only.
You are, obviously, vulnerable on first contact to a site, in that an attacker can prevent you from ever seeing the STS header. The point of STS is that attackers don't generally get to intercept your first contact with a site.
Adam Langley, by the way, is one of Google's Chrome SSL/TLS/HTTPS people.
Re: Living with HTTPS
#8The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers? In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.
The STS header has an expiration date on it.
Let's assume you have it set to 1 year. If user A visits the site in March, receives the header, uses the site for a while.
In May, the site/user's DNS/whatever is hijacked. Users are sent to a dummy site, which does not set the header. The dummy site is over HTTP.
The next day, the user tries to go to the site. Because it is not over HTTPS, the browser refuses to load the page, even though the header is no longer sent.
Re: Living with HTTPS
#9> There's a second collarary to this: attackers can set your HTTPS cookies too. If your app uses session ID cookies, then another implication of this is that attackers can set a user's session ID to a value they know, wait for the user to log in, and then use the session ID to hijack the logged-in session. To prevent this make sure you regenerate session IDs when logging a user in. (This isn't the only reason to rege…
This is called "Session Fixation". Most modern frameworks prevent it, which is a reason to use your framework's session functionality rather than re-inventing it.
Session fixation used to be a common problem. There were lots of J2EE applications which were not only fix-able, but which would allow an attacker to fix a session ID with a carefully crafted GET URL. It's much rarer now.
Re: Living with HTTPS
#10The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers? In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.
No, that's not how STS works. Once the header is set, a MITM can't simply clear the header; the purpose of STS is to tell the browser to remember that the site is HTTPS-only. You are, obviously, vulnerable on first contact to a site, in that an attacker can prevent you from ever seeing the STS header. The point of STS is that attackers don't generally get to intercept your first contact with a site. Adam Langley, by…
If you're in an oppressive country (say Syria), for example, is it a bad assumption that you're always being MITM'd, and unless you leave the country (not likely) EVERY first contact you make is already compromised? It's a tough chicken and egg problem.