Last week at the CodeMash conference, I delivered a session titled HTTPS in 2015:
Securing your websites and services using HTTPS has never been more important, or more complicated. In this talk, a former browser Security Program Manager covers the best practices for using HTTPS today. Topics covered in this session include ciphers and hash algorithms, forward secrecy, handshakes and protocols, and new browser features like HSTS and PKP. Explore how attackers circumvent HTTPS, and what you can do to help protect your visitors and customers safe from snoops and bad guys. Secure all the things!
- SSLLabs' Server Test - Test your server's use of HTTPS
- Ivan Ristić’s excellent Bulletproof SSL and TLS book - Understand HTTPS, attacks, and how to deploy
- The Let's Encrypt Project
The last item is perhaps the most exciting: the EFF’s Let’s Encrypt project is slated to offer free HTTPS certificates starting in the summer of 2015. There’s a great summary of the project in this video presentation by Seth Schoen from late last year.
HSTS and Privacy
I also wanted to take this opportunity to provide some context related to recent press about the “super-cookie attack” against HTTP Strict Transport Security.
In this attack, which I alluded to at the end of my intro to HSTS post last year, a site generates a large set of HSTS rules and uses these to act as a type of “super-cookie” identifier that can be used to uniquely identify a given client. While much of the coverage is of the breathless “Wow, so clever! Browser designers are fools!” form, the reality is that this attack has been well known since the dawn of the HSTS proposals, and it’s even explicitly called out in the Chromium team’s (excellent) Technical Analysis of Client Identification Mechanisms document.
The attack vector forces browsers to make a direct tradeoff between privacy and security—ignoring HSTS decreases security, but respecting it can impact the user’s privacy. Safari’s approach (an undetectable, undeletable super-cookie) is clearly bad, while Chrome’s approach (non-Incognito-set HSTS rules carry over to Incognito mode, while the reverse is not true) more carefully straddles the line.
It’s not yet clear how Internet Explorer 12 will behave, leading to the following design considerations:
- Will IE offer a “pre-load” list of HSTS sites, improving security with no privacy impact?
- Will IE allow InPrivate-set HSTS rules to apply to non-InPrivate mode?
- Will IE allow InPrivate-set HSTS rules to apply to future InPrivate sessions?
- Will IE allow Non-InPrivate-set HSTS rules to apply to InPrivate sessions?
- Will deleting browser history clear all or all non-preload HSTS rules?
Beyond expanding the pre-load lists, I’m hoping that future browsers can use some additional heuristics to balance the privacy/security tradeoff. For instance, browsers could partition header-set HSTS rules by BrowsingPrivacyMode and clear them when the user dumps history, but persist any rules for sites that heuristics suggest are “legitimate” (e.g. the user has created a favorite, directly navigated via the address bar, etc).
One fact is increasingly clear—moving to HTTPS is crucial to helping protect the user’s privacy. In just one example, it’s recently been observed that a popular Mobile ISP is injecting a tracking identifier into all outbound HTTP request’s headers (regardless of privacy mode) and this header is being used to reconstitute cookies that users have manually deleted. Moving to HTTPS helps defeat shenanigans like this.
As a user: Demand HTTPS.
As a site: Deploy HTTPS.
Secure all the things!
MVP, Internet Explorer