One thing worth knowing, if you’ve got sensitive cookies (e.g. a session cookie), but can’t use HSTS yet for whatever reason (maybe you’ve got some legacy content which embeds HTTP resources from a site that doesn’t support HTTPS yet), you can use the secure flag on a cookie to cause it to not be sent on HTTP requests, only HTTPS.
This is all good and correct, but it fails to mention a major other reason why STS is a good idea (and as far as I know one of the reasons it got invented in the first place): It prevents many instances of “SSL Stripping” attacks.
When one visits a site via HTTP first and then gets redirected to HTTPS then an attacker can intercept this connection, prevent the redirect and instead serve a malicious version of a page over HTTP. HSTS preloading completely prevents this attack and normal HSTS reduces it to the very first connection to a site.
As usual, an excellent post from Julia!
One thing worth knowing, if you’ve got sensitive cookies (e.g. a session cookie), but can’t use HSTS yet for whatever reason (maybe you’ve got some legacy content which embeds HTTP resources from a site that doesn’t support HTTPS yet), you can use the
secureflag on a cookie to cause it to not be sent on HTTP requests, only HTTPS.This is all good and correct, but it fails to mention a major other reason why STS is a good idea (and as far as I know one of the reasons it got invented in the first place): It prevents many instances of “SSL Stripping” attacks.
When one visits a site via HTTP first and then gets redirected to HTTPS then an attacker can intercept this connection, prevent the redirect and instead serve a malicious version of a page over HTTP. HSTS preloading completely prevents this attack and normal HSTS reduces it to the very first connection to a site.
I just ran into this myself, though it was an accidental self-attack.