Privacy: Making SSL faster, and why Do Not Track is NOT using it
by Peter
In my last post: Privacy: What “Do Not Track” really needs to make it enforceable (and verifiable) – HTTPS I finished up asking what would could be done to speed up encryption and SSL.
Before we answer the question lets chat a moment about what SSL or TLS (Transaction Layer Security) is. Here’s the definition from Wikipedia: link
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using asymmetric cryptography for key exchange, symmetric encryption for privacy, and message authentication codes for message integrity.
There are 3 critical elements to SSL/TLS which i’ve highlighted in bold above
-
Key Exchange -
Key Encryption -
Message Authentication
In lay terms it boils down to a method to exchange the “keys”, a way to encrypt the message to ensure privacy, and finally a way to deliver the message that ensures integrity. So when you want to buy something on the Web everyone uses SSL/TLS to ensure that the message remains private, and that the integrity of the message between the buyer and the seller remains intact.
The other advantage of using SSL/TLS is the fact that it’s standards based approach that all current caching and Web servers are intimately familiar with. Any caching server that sees a browser request for a Web page that starts with HTTPS immediately “gets out of the way” and essentially allows the browser and the Web server to communicate in a Peer-To-Peer fashion. No more dropped headers, no more corrupted messages, you know whose there.
So why isn’t the Do Not Track standard using SSL/TLS to ensure the integrity of the “tracking header” that is delivered to the Web server? Well there’s a number of reason.
- It’s processor intensive
- There are over ½ a billion Web servers out there that would have to change from HTTP to full time HTTPS (Source)
For example let’s take Google’s Mobile home page and see how it performs in both regular HTTP mode vs. HTTPS mode.
The delta between the two tests is about 1500k in page size, and let’s call it ½ a second in extra tim. It doesn’t sound like much (Google’s got some very fast servers) however when you multiple that by a billion search requests a day, the number of seconds becomes hours of lost time. Using the general rule of thumb that ½ a second is worth about a billion dollars a year to Google in revenue you get the idea very quickly that switching to SSL is not something to do lightly.
The other thing to remember here is that every element on a Web page that is requested using HTTPS has to be encrypted. That means in the above example that Google encrypted 19 elements vs. NOT encrypting 17 elements. What’s missing here is a way to “encrypt only the elements that count”.
Remember at the end of my last blog post I talked about “field level encryption”. Well lets chat about that for a moment. Let’s say I decide to buy something on Google’s site. Every single element on that page from graphics to the page itself has to be encrypted. That’s a lot of processing power to essentially protect just a few credit card fields. Why has no one had the idea that it makes sense both performance wise, and bandwidth wise, to “only compress the sensitive parts of the transaction?”.
And this is where field level encryption comes in. Right now Do Not Track has no encryption, basically because it’s not really doing anything other than saying “don’t track me”. There’s no way to really know if someone is really tracking you. So what about switching to an SSL session where now I have a Peer-To-Peer connection established with the server, no one can interfere with the DNT header and I can verify that it was me connecting to the server. Well now all of a sudden compliance becomes doable.
The absence of encryption and SSL/TLS in the current Do Not Track header spec speaks volumes as to what is really going on here. It’s basically an unenforceable standard, which if you think about it makes a lot of sense to the people who care the most about knowing more about you.
Posted in: #Choice, #mobile, Privacy, User Experience