I’m always interested in finding ways to leak privacy information out through browsers. For those who aren’t aware of it, there’s a new technology called “Strict Transport Security” or STS for short that pins a browser into using SSL/TLS for all further connections with the site in question. The goal of the tool is to reduce the risk of tools like SSLStrip that downgrade you to using HTTP instead of HTTPS. However, there was a somewhat bad privacy issue that was created as a result of it:
Imagine a scenario where you have one website that a user is interacting with (say an evil advertising empire intent on tracking people for marketing purposes).
On that SSL/TLS enabled website there are a series of iframes. Each iframe leads to different HTTP (not HTTPS servers). The first iframe (call it iframe00) is the “check” to see if the user has been to the site before. It automatically redirects the user to the HTTPS site via 301 redirect. The fact that the user hit the HTTP site at all means they haven’t been there before which brings us to the first use case:
Use case 1) If the user has not been to the evil website before (which can be found out because the user will hit the HTTP version of frame00 before being redirected to the STS enabled SSL/TLS version of that subdomain), a series of iframes will selectively turn STS on and off on each subdomain. Those subdomains will essentially provide one bit of information. Collectively that maps to a user profile in the database. For instance frame01 = STS, frame02 = HTTP, frame03 = STS, frame04 = STS … could map to binary 1011 = decimal 11 or the 11th user to visit the site. The number of iframes required is based on the total number of users that the site believed it would need to track over it’s lifetime or 33 iframes total (which would enable enough bits for the ~1.7bn internet users).
Use case 2) If the user has been to the site before they will not hit the HTTP site on frame00 (the “check” website) and they instead are immediately sent to the STS site, the evil website can begin to calculate who that user corresponds to. By setting every frame to the HTTP sites (not STS enabled SSL/TLS sites) and seeing which ones instead go to the HTTPS site, the evil site can map those bits back to the corresponding user that the site has seen before.
This is one of those unfortunate examples where it’s a good idea that introduces another security flaw. The fix isn’t great though - as it basically helps reduce the effectiveness of STS in the first place, by making it easier for the user to clean out. The whole point of STS is to pin the browser to a secure connection. So either that’s important to do, or it isn’t. If it isn’t, STS shouldn’t exist. If it is, then it shouldn’t be cleaned. Either way, I don’t think STS is going to provide a lot of value without some more thinking. But for now, it’s a good chance for companies to play with a new way of securing their site from man in the middle attacks. Firefox is planning on implementing this soon as well. Overall, I was pretty happy with how Google handled the bug, and fixed it, along with the dozen or so other bugs that were reported to them during the bug hunting contest. Hopefully, Google will continue increase their diligence around privacy issues in their products in the future.