Fixing A Hole Where the Rain Gets In… The Era of TLS Everywhere

With my work on SPDY, I often am asked about whether requiring TLS (aka SSL) is a good idea or not.  Since SPDY is supposed to be about low-latency performance, how does something like TLS, which is traditionally thought to be slow, wedge it’s way into the design?

The answer is simple:  users want it.

But how did we get here anyway?
If I told you that I was building a house with no locks, surely you’d ask me to install locks.  Then, if I grumpily installed a lock only on the front door, you’d tell me to go install locks on all the doors.  But this is essentially the web we have today.  When you’re using TLS, nobody can get through your front door.  But when you’re not using TLS, potential attackers can easily see exactly what you’re doing on every website you visit.  How is it that we’ve built a house without locks?

When the web was invented in the early 1990’s, there was little need for locks.  It was about sharing information, not purchasing your new TV or sending your medical information to your doctor.  And because it wasn’t a critical means of communication, would-be eavesdroppers would rather tap your phone than tap your Internet.

Netscape, recognizing the need for security on the web to facilitate e-commerce, invented SSL (the predecessor to TLS).  At that time, SSL was computationally expensive and algorithmically unproven.  Forcing everything to run over SSL then would have been impractical.  Instead, two protocols were used, https for data exchanges which were critically sensitive, and http for everything else.  It worked.

Since that time, the computational overhead of TLS has dropped by orders of magnitude, and the protocol has held up to algorithmic scrutiny.  At the same time, the web has grown massively, evolving from a system designed for sharing of ideas into a system which carries our most sensitive and personal secrets.  But despite that, the security of our communications has not changed much.  Don’t get me wrong – it’s not all bad.  The most critical information exchanged with our banks and online purchases is usually secured by using TLS, which is great.  And on some sites, email is secure too.  But the majority of web traffic is still sent insecurely, using HTTP.

Users have grown accustomed to security problems on the net which are far worse than the lack of protocol security, and the need for protection has been relatively low.  But as our lives move from physical to digital, the desire of hackers, governments, and the otherwise unscrupulous grows massively too.

So, from a user’s perspective, instead of asking the question, why does SPDY require encryption and authentication, a better question would be to ask, why not?

What Does TLS Do?
TLS, which is most commonly used by users when they go to a site using a https:// URL, offers two basic features: server authentication and data encryption.

Server authentication is a mechanism where the client can know that a site is trusted to be who the site claims to be.  For example, when you visit, TLS uses a system of known trust points to validate that this site really is Bank of America, according to a service that your browser has chosen to trust because it complies with a detailed set of specific security practices.  Yeah, it’s complex, but the complexity is hidden from the user.

Data encryption is what prevents others from reading the data that you send over the Internet.

The Argument For Maintained Insecurity
At this point, I think I’ve heard all the arguments against TLS.  Some are valid, and some are not.  But we can overcome all of them.

Invalid Argument #1:  Certificates Are Costly And Too Hard to Deploy
Certificates are a critical element of trust for implementing server authentication within TLS.  Any site wishing to use TLS must get a certificate so that they can prove ownership of a site.  Verifying your identity is a manual, offline, and usually time consuming process.  So typically the companies offering these service charge fees to do so.

The cost of a certificate used to be really high – even over $1000.  But these days, certificates can be surprisingly cheap, sometimes less than $10 (or even for free).   At this cost, it is insignificant.

Despite the low cost, maintaining a certificate on a website is difficult. Server administrators must take precautions to protect their identity, and getting the right keys and certificates to the right servers is time consuming.

But in the end, this is not an argument for the user.  This is an argument for a website that wants to save a relatively small amount of money.  User security is more important than that.

Invalid Argument #2:  It’s Just a Youtube Video, We Don’t Need To Secure It
Some content is so public, that many people believe that it doesn’t need to be secured, and this is partially true.  For example, I really don’t care if someone sees the traffic I sent to Facebook today, because I’m posting that data publicly on the web already.  It’s obvious.

But the problem is that when we offer two modes of communication, one secure and one not secure, we punt the problem to the user:  “Do I need to send this securely?”  Even if the user did know the answer to that question, and most users don’t, what one user may consider public information may be very sensitive to another.  The only way to solve the problem for everyone is to always send data securely so that users don’t need to disambiguate.

Invalid Argument #3: Schools and Families Can’t Filter With TLS
Earlier this year, Google enabled a new feature, Encrypted Web Search.  This feature didn’t force all communications to use TLS, it simply allowed the users to choose it if they wanted to.  Unfortunately, this feature rollout was matched with cries from schools that they could no longer enforce content filtering for their students, which they are required to do by law.

Side note:  Its ironic that Google is often criticized by our governments for not being sensitive enough about privacy.  However in this case, when Google rolled out a feature to enhance privacy, that same government complained that Google is preventing censorship of our children.  But, that’s politics! 🙂

Seriously, schools have a legitimate need here.  They want to protect children from adult material, and they have bought solutions to this problem from many vendors.  But unfortunately, most of those solutions leverage the fact that the web is insecure to implement the filtering!  If we encrypt the web, these filters no longer work, and that is a problem for schools.  It should be noted as well  that these solutions already break when kids at school use SSL proxies (such as this one, or this one, or this one).  But the filters don’t have to be perfect, so these problems are overlooked.  The filtering vendors are in a constant arms race with services which attempt to circumvent the filters.

I really do sympathize with schools, and nobody wants to levy a costly solution on our already cash strapped schools.  But filtering can be solved even in the presence of encryption; it is just a little harder. Many solutions exist, and we need to move the filtering to be certificate aware.

It doesn’t make sense to sacrifice the security of the entire web so that we can continue to enable cheap filtering in schools today.

Invalid Argument #4:  Debugging The Web Is More Difficult
A natural consequence of security is that you can’t read the communications between the clients and servers easily.  For web developers, this can make it more difficult to find bugs.  Yes, it’s true.  Debugging is still possible, it is just harder.  But developer laziness is not a good reason to keep the internet insecure.

Invalid Argument #5: Political Backlash
Some governments are pretty adamant about their need to filter the net, and they aggressively  filter using complicated techniques.  If the web attempts to move to an all-encrypted protocol, these governments may decide to ban the protocol altogether.  Yeah, I guess that is true.  At some point, the citizens might want to revolt. I’m lucky I don’t live there, but that’s not a good reason why other countries can’t choose privacy.

Invalid Argument #6:  Existing Servers At Capacity Will Break
Some websites today are already running their servers at full capacity.  If we add security to the protocol, which requires even 1% more server resources, these sites could get slow.

While this is probably a true statement, it’s really not the user’s problem.  I don’t see this as a compelling reason to not improve the security of the web.

Invalid Argument #7: Features of Transparent Proxies
Because the web is insecure today, it is possible for network operators to install transparent proxies which inspect the insecure traffic and change it.  Sometimes these proxies do good things, like scan for viruses and malware.  But other times, these proxies do bad things, such as turn off compression.

From experience, we know that there are a lot of problems with transparent proxies.  And these proxies are generally considered to be an obstacle for protocol evolution on the internet.  For instance, HTTP’s pipelining is currently disabled in all browsers largely because proxies make it impossible to deploy.

Enabling security on the web does not prevent the anti-virus and anti-malware “good” proxies.  It just means they have to be explicit.  But turning on security does prevent the proxies which intentionally or inadvertently break the protocol.


Ok – so that is the list of what I consider invalid arguments.  But there are a couple of valid arguments too.


Valid Argument #1: TLS is Too Slow!
It’s true.  TLS is too slow.  This is in part because TLS is used so rarely that nobody has bothered to optimize it, and in part because it is difficult to change.  The net result is that secure communications are slower than insecure communications.  This will probably always be true, but doesn’t mean we can’t solve the problem enough to make it insignificant.

To understand the problem, we need to recognize there are 4 parts to TLS performance:
  a) The round-trip-times of the TLS authentication handshake
  b) The CPU cost of the PKI operations during the handshake
  c) The additional CPU to encrypt data being transferred
  d) The additional bandwidth due to TLS record overhead

a) The additional round-trips of TLS are real and need to be addressed.  Today, the first connection to a site requires 2 round-trips for server authentication, and subsequent connections require 1 round-trip.  Adam Langley has proposed a protocol change which reduces these to 0 round-trips (more details here).  So for the sites you visit regularly, TLS will no longer incur any extra round trips.

b) The cost of PKI operations these days is super cheap.  While these complex math computations took hundreds of milliseconds in the mid-1990’s, faster processor speeds make them take nanoseconds today. With optional hardware offloading, this is just not a problem.

c) Many people assume that bulk-data encryption is expensive.  This is not true; the most common bulk encryption used with TLS today is the RC-4 cipher.   RC-4 is extremely cheap computationally, and we’ve measured it has no additional latency costs when compared to the NULL cipher.  Other encryption algorithms can have small costs (such as AES), but they’re still quite fast and you don’t have to use them.

d) We’ve measured SSL using ~3% more bandwidth than non-SSL. That is a relatively low overhead number, but it does add a non-trivial amount of latency.  For a 320KB web page, 3% more data can add 30-80ms to the web page load time.  Fortunately, bandwidth speeds continue to rise, and because of this, we don’t see the 3% overhead as excessive.

Overall, we believe (b) and (c) are non problems.  We believe we can solve most of (a), and that (d) is an acceptable cost, mitigated by bandwidth improvements over time.

Valid Argument #2: Caching Servers Don’t Work With TLS
One of the most complicated parts of web communications today is communicating with proxy servers.  Proxies have many purposes, but one of them is to cache content closer to the client to reduce latency. For example, if two users in Australia are both communicating to the same server in London, it reduces latency for the second user if he can use a cached copy of the content that the first user already downloaded.  Unfortunately, when all traffic is private, the proxy servers don’t know what data is being sent, and so they can’t cache it for other users.  This can make the user’s bandwidth costs go up and also increase his page load times.

But the use of proxy servers over the past few years has eased as the age of the Content-Delivery-Network has grown.  Content Delivery Networks (CDNs) are a mechanism where websites can distribute content to a server which is proximal to the user regardless of whether the user has set up a proxy or not.  CDN usage today is extremely common and growing.  Almost all of the top-100 websites use CDNs to offer performance which is even better than proxy servers.  Speculatively, we could guess that in the future all content will be delivered through CDNs as more and more sites move to hosted cloud computing platforms which will have the infrastructure of a CDN.

Given the use of CDNs and the decentralized use of proxy servers, it is hard to quantify the benefit of proxy servers today.  We know that the majority of Internet users do not use caching proxies at all.  But we also know that for some users they are very useful.  And if we move to all secure communications, those users will no longer have caching proxies.  I don’t have a good answer for this problem, except to say that I don’t think it is a huge problem, and that it is mitigated by CDNs. But I confess I lack data as well.

Changing protocols is not something we do very often.  TCP/IP are over 30 years old, despite attempts to replace them.  As such, the opportunity to improve network security does not come up often, and is not one to be overlooked.  SPDY is a unique opportunity to improve not just HTTP, but also the fundamental underpinnings of how we communicate.

From the user’s perspective, the only argument against TLS is performance, which we believe we are actively solving.  The other arguments don’t help the users – they help server and IT administrators.  As we look to build the next generation Internet protocols, should we be looking out for the user or the administrator? SPDY wants to make sure the user is safe and in control.

It would be easier to make SPDY successful without TLS.  Biting off security in addition to performance is a huge task that almost seems counter productive.  But, lack of security is such a gaping hole in today’s Internet infrastructure, that we just don’t feel it can be overlooked.  If security does prove to be an insurmountable task, we can always fall back to the same-old-same-old insecure plan.  That is easy.  But pushing things forward?  When will we ever get that opportunity again? Maybe never.

It is sad that network traffic today is insecure.  It will be absolutely tragic if network traffic in the year 2020 is still insecure.

14 thoughts on “Fixing A Hole Where the Rain Gets In… The Era of TLS Everywhere

  • Pingback:Tweets that mention Mike’s Lookout » Blog Archive » Fixing A Hole Where the Rain Gets In… The Era of TLS Everywhere --

  • July 21, 2010 at 11:56 am

    There’s one gotcha to SSL that I don’t see here addressed that has always been quite troubling to me.

    Because all communication between site and server is encrypted, Apache (for instance) doesn’t know which host the request is for until after decrypting, which requires the SSL certificate.

    So, an SSL certificate has to be bound to a site (in Apache) by IP address, not by host, so that Apache knows which cert to use to decrypt the response.

    This means that if you run multiple sites on the same server, you have to have a different IP address for each site you want to SSL encrypt.

    The uglier/more complex alternative is to bind your SSL certs to different ports on the same IP. But then users see different ports in their URL’s which is ugly. So you can get more complex by running a proxy in front of your apache server that transparently re-routes different requests. And it gets messier from there.

    Will IPv6 solve this by giving us all millions of available IP’s? Only if hosting providers give us that many IP’s. I run my servers at a co-location and I only get 32 IPs. I have well over that many sites that I could theoretically protect with SSL.

    I don’t know the security implications, but it seems to me that browsers could allow the hostname of the request to be unencrypted, so that web servers could know which of several SSL certs bound on an IP/port to choose. But that’d be a fundamental change not only in browsers but in web server software.

  • July 21, 2010 at 12:28 pm

    I would ++ your Valid Argument #1 when it comes to mobile. We (Hobsons) track our web traffic using a Coradiant appliance. When you drill down to sessions based on browser type, the “SSL Handshake” times start stretching out on Androids, iPhones, BlackBerrys etc… You are almost guaranteed triple digit latency using 3G and with all the back and forth you mentioned, it has a huge impact. LTE is promising low latency but 0 round trips would be great!

    That being said, most of our traffic is forced to SSL and that’s not going to change. Security > performance in this case.

  • July 21, 2010 at 1:41 pm

    @mike- i’d not heard of SNI before. But I’d wager this is why:

    Unsupported operating systems, browsers, and libraries
    The following combinations do not support SNI:

    Konqueror/KDE in any version
    Internet Explorer (any version) on Windows XP
    Google Chrome on Windows XP
    Safari on Windows XP

    Practically no support in Windows XP is still basically a non-starter for such a critical feature.

  • July 21, 2010 at 2:13 pm

    @Kyle: This may not work given the domains you use, but a wildcard cert (* may help out. I host hundreds of unique FQDNs on one IP with no problem.

  • July 21, 2010 at 2:14 pm

    Kyle – For existing use of SNI, you are right. For what I’m proposing, however, we’re already talking about much more aggressive changes to TLS including NPN, FalseStart, and SnapStart. So picking up SNI is the easy “already done” part 🙂

    BTW – Chrome on WinXP does support SNI now (it used to rely on the Microsoft SChannel libraries, which didn’t support SNI, but now uses NSS, which does support SNI)

  • August 10, 2010 at 5:56 pm

    I really like where you’re going with this but I think you’re underestimating the political challenges here.

    By separating TLS from SPDY (or at least make it optional) you avoid having to solve the political issues to see SPDY succeed.

    I would LOVE TLS (with ephemeral keys) to be deployed everyone but realistically China and the US will do whatever it takes to derail this if TLS is required.

    I hope I’m wrong though.

    This comment is now a diamond!

  • August 25, 2010 at 12:07 pm

    Thanks for the link to Schneier’s article; but Schneier didn’t say that TLS won’t help with privacy.

    Schneier is talking about a different problem – that of data security. If someone is trying to find information about you, Roman Shterenzon, then they will go about it in a certain way, and you’re right TLS probably isn’t the weakest link.

    But I’m talking about privacy breaches of security that are so common today simply because you didn’t even try to protect yourself: Go to Starbucks, turn on your computer, and everyone else in the room can see everything you do…. unless you use TLS. If you use TLS, the burden of the attacker is much much higher.

  • September 28, 2010 at 10:40 am

    I think it is a little disappointing that you simply accept the cost of a TLS certificate as a fact of life, a trivial thing. Underlying that attitude, and much of your statements about proxies, is the attitude that only the big, high-volume professional sites matter.

    For all the little hobby sites, personal web-sites, the entire long-tail of small stuff that is a big part of what makes the web so fantastic, the additional cost (both in terms of money and administrative overhead) of a TLS certificate is far from trivial.

    Of course, the whole scam of charging money for a cert is just that – a scam. Your domain registrar should give you an unlimited number of certs for your domain and all sub-domains as part of your registration, and tools to revoke and manage them. This should be included in the price of a domain. After all, all the cert really does is verify that you are the owner of the domain, and ultimately the only person that knows that is the person that sold it to you. The fact that this isn’t standard practice today probably boils down to a combination of inertia and greed.

    You should get your well connected coworkers to see about leaning on a registrar or two to fix this. 🙂

  • Pingback:Mike’s Lookout » Blog Archive » Firesheep, SPDY, and you

  • November 14, 2010 at 5:57 pm

    On the issue of money and SSL, have a look at

    Also SNI is not a problem in Chrome on Windows XP, they still use the same library from Microsoft which is part of Windows XP, but they added code to it so it will still work.

    Or they only use the certificate store of Windows and just use the Network Security Services library from Mozilla like they do on Linux.

    Whatever, in Chrome it works (Firefox and Opera both don’t use the Windows library/certificate store).

    So it is ‘just’ Safari and IE6, IE7 and IE8 on Windows XP and IE5, IE5.5 and IE6 on Windows 2000, which don’t support it.

    Also on it isn’t possible to use it with IIS on Windows 2000, Windows 2003 and IIS on Windows 2008 does support it, but their is no GUI.

    I don’t know what the status is of Chrome on the Mac, I think I read a really old comment somewhere that SNI wasn’t supported on the Mac. We do know Safari works on the Mac.

  • June 10, 2011 at 2:30 am

    I want to use SPDY over a satellite link. It would be really great if SPDY came with an option to turn off TLS encryption as this increases the packet length.


Leave a Reply

Your email address will not be published. Required fields are marked *