Monday, November 15, 2010

Why the web has not switched to SSL-only yet?

With the session-sidejacking issue highlighted once more by Firesheep, a many people have asked me why more websites, or at least the major players (Google, Facebook, Amazon, etc.) have not enabled SSL by default for all communication. Indeed, encryption is the only way to ensure that user sessions cannot be easily sniffed on a open wireless network.

This sounds easy - just add an s after http in the URL! It's not actually that easy. Here are some of the challenges.

Server overhead

The obvious issue is that encrypting all HTTP sessions requires additional resources on the sever-side. I've seen numbers showing 10% to 20% CPU overhead for SSL. Having to add 10% more servers is a big deal when you're dealing with thousands of them like Facebook and Google. However, the overhead can actually be much higher on specialized severs, which efficiently serve static content (such as images) directly from memory (think memcached). In this case, the processing power required is easily multiplied by a factor of 10. Of course the SSL encryption can be offloaded to a proxy or other external hardware, but you have to add the cost of managing a more complex topology as well as buying the new hardware.

Increased latency

SSL also has a perceived performance issue for the client (i.e. the browser). For  each new session,  SSL encryption must be set up between the client and server. This means a few more packets must be sent back and force before the actual HTTP data is received. This happens for each page load, and also for each domain.
1 HTTPS transaction: 4 SSL handshake packets, 6 data apckets

A typical  Facebook page (like the News Feed) contains HTML elements (images, CSS, JavaScript) from more than 10 domains.  This means the full SSL handshake is done over 10 times on each page. This in turn makes pages load more slowly. The problem is amplified if the user's connection has high latency, as it would on a cell phone.

4 of the 10+ domains used on a Facebook page

Challenge for CDNs

All the major websites use a Content Delivery Network (CDN) to deliver static content quickly to their users. Some have their own (Facebook, Google), but others use third parties such as Akamai.

The same website can be served from hundreds of CDN servers based on their geographical location, and each CDN server can handle several hundred websites. Most website owners don't want users to see content being downloaded from, so they use an alias. For example, could point to

Each CDN therefore serves different content based on the Host header received ( for example). This creates a problem. The SSL handshake is done first,  then the HTTP data is sent. That means the SSL server must send an SSL certificate to each client without first seeing the host. In brief, the SSL server sends a certificate based on the destination IP address, not based on the HTTP hostname.

The second fact to keep in mind is that an SSL certificate is valid for one domain only.  If a user goes to, the certificate has to be signed for, not or

SSL certificate for

For example, is served entirely through Akamai. So what happens when you use ? You get a warning, because the Akamai CDN server sends a certificate valid for itself (, not for

Wrong SSL certificate issued for instead of

Wildcard certificates are not enough 

You don't need to use a CDN to have troubles serving the right certificate for a given hostname. Most sites can be reached with and without www: and brings you to the same site. When a site wants to handle several sub-domains (,,, etc.) easily, it can buy a wildcard certificate. This certificate is valid not just for one domain, but for all sub-domains: * Unfortunately, this wildcard certificate is not valid for (no sub-domain). For that, a separate certificate is required. This is again a challenge if the same IP address servers both and

Dropbox has this exact issue. Access to delivers a warning to he user:

Dropbox's wildcard SSL certificate is not valid for

Mixed HTTP/HTTPS: the chicken & the egg problem

Yet another issue - HTTPS pages must contain external object from HTTPS URLs only. You cannot match HTTP and HTTPS on a secure page, otherwise users receive a warning message. Websites however rely on a significant amount of content from external sites: Googole/Comscore Analytics, Google/Twitter/Facebook connect, ads, etc.

Google Adsense, for example, cannot be used on a secure site. All sites which rely on this advertising network to make some money need to forget about HTTPS and about protecting their users!

Each website needs to make sure that all their partners, sometimes much bigger than they are, fully support HTTPS before they switch to it.

Warning about external HTTP objects on a secure page

Warning are scary!

It is not easy for a site to switch to SSL for all content. One mistake, and users will receive a warning. And they're scary! Internet Explorer 8 explicitly suggests that the user not to enter a site with an SSL certificate error.

Scary warning on Internet Explorer

Websites really don't want to scare away potential visitors!

But it is possible

Moving from HTTP to HTTPS is easier said than done. This must be carefully planned. All cases have to be thought through to avoid warning messages. Despite that fact, all of the challenges discussed in this post do have technical sotuions.

This can be done. Google has already moved Gmail to HTTPS by default, but they have not done the same for their other services...

-- Julien


Patrick said...

You can use subjectAltName to defined multiple hostnames for the certificate. This can get around some of the issues you mentioned if you know all your virtual hostnames in advance.

scottt732 said...

Client-side caching can also be a nightmare. Browsers vary in behavior with caching content that was transmitted over an SSL encrypted channel, even if the web server explicitly ask them to. I think Firefox will cache it in memory, but never to disk. IE's behavior has changed over the years. In some cases, any kind of static content (images, stylesheets) will be re-requested with every subsequent page request. Coupled with the 'don't mix SSL and non-SSL content on a page unless you like annoying security warnings' problem, this could cause major headaches for css, js, and traffic-heavy sites like Facebook, while Google probably gets a pass on account of their minimalist design.

Mario said...

Most importantly, because it costs money. All else is secondary.

Julien Sobrier said...

@Mario SSL certificates are cheap. But making changes to the infrastructure to support all cases might be expensive

Julien Sobrier said...

@Patrick Right, all the issues I mention have a technical solution.

For those interested in seeing a certificate with subjectAltName, check out Their certificate is valid for * and

RapidSSL said...

This is nice sharing and i like your post. It's very help full and interesting post. Thanks for sharing and keep it up.

Mike said...

Re "Server Overhead". This is a common argument and no longer true.

"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."

Mike said...

Re "Increased latency". There is an increase but it's not *that* much. Google are working on something called "False Start" to try and reduce the number of roundtrips when negotiating SSL which should hopefully reduce the latency:

Xorlev said...

HTTP hostnames are also not an issue anymore if you look at TLS server name extensions (SNI). Most modern browsers support them. OpenSSL has it native since ~0.9.6 if I recall. IIS supports them, Apache, and soon LiteSpeed and likely plenty of others. It really is becoming much easier without the need for subjectAltName certs. SNI also means SSL-based virtual hosting.

Anonymous said...

Many times I get the following, what is the problem:
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: file:///C:/Documents%20and%20Settings/Oded/Application%20Data/Mozilla/Firefox/Profiles/pnw3asjy.default/extensions/

Julien Sobrier said...

This comes from the BlackSheep extension. There might be too much HTTP traffic to check for the plugin. In version 1.5, you can start/stop it manually.

SSL Certificates said...

Keep the faith, my Internet friend. You are a first-class writer and deserve to be heard.

Kamagra said...

hey buddy,this is one of the best posts that I’ve ever seen; you may include some more ideas in the same theme. I’m still waiting for some interesting thoughts from your side in your next post

EV SSL said...

Well now the day come that you had waiting for. Web has switched to https protocol now. All the major sites now uses SSL Certificate. So now people can be relaxed working with web.

Julien Sobrier said...

@EV SSL I actually don't agree that major web sites have made much progress. I will post a follow up on this post this week.

QuickSSL Premium said...

SSL Really Help to e commerce website by providing high level of data security.

rapidssl wildcard said...

SSL certificate is now mandatory aspect to all Ecommerce platform those are being accepting payments online using user's sensitive information. SSL certificate should have all the web site which will surely create secure online shopping and web surfing environment.

- Thanks Have Nice Day!

Solvent Extraction Process said...

I have enjoyed reading this kind of article. Very informative and knowledgeable one. I will share it to my friends and add this website to my bookmark lists! Thanks for sharing. Great Websites!