The Entire Web Should Use SSL All the Time

The entire web should be using SSL (secure socket layer) all the time. SSL causes resources on a web server to be encrypted on the server and decrypted on the web browser. This means that intermediary parties cannot view the information as it moves between the web server and the browser. They can get at the meta data, but not the content. Why is this important? For unencrypted traffic:

1. For dynamic content, it can be read.
2. All content can be manipulated.

If you have web based mail and it does not use SSL, then a party can essentially tap the connection between your computer and the server and read your email. I'm not pointing fingers, but one example would be the NSA.

All content can be manipulated. There have been cases where ISPs (Internet Service Providers) have grabbed the HTML (HyperText Markup Language), and injected ads into the content being delivered. Programs downloaded from the web site can be intercepted and malware injected. I don't want anyone messing with the content that I deliver from my server.

There are three reasons why people do not use SSL on their web servers:

1. It doesn't compress. A web server can automatically perform compression on text before sending it across the wire to the browser, where it can be uncompressed.
2. It requires a separate IP (Internet Protocol) address for each web site.
3. It costs money for the certificates for the site.

Compression of text is just not that big a deal. Unless you are moving a lot of text and your bandwidth is tight, you just aren't going to see huge gains using compression. As an example, let's suppose that you have 10000 (~10K) characters on a web page. That's a pretty big page; most are considerably smaller than that. Let's suppose that you can compress that at the maximum amount and get 85% compression. So you have to move only 1.5K characters across the wire. Big win, right? Saved 8.5K or 85% of the bandwidth of the page!

However most web pages like that might have three 20K graphics on them. Graphics don't compress, because they are already compressed. JPEG, GIF, and PNG, and all video and audio files are already compressed. Compressing things that are already compressed produces essentially no gain, and in some cases is even bigger than when you started. So if you have three 20K graphics on the page, compression has only reduced the size of your page from 70K to 61.5K, so only a 12% gain.

A little technical sidebar on reducing the size of your page. In most cases, if you want to reduce your bandwidth, don't worry about text...worry about graphics.

1. Reduce the number number of graphics on your site. Remove that extra graphic on the page.
2. Reduce the size of the graphics, particularly if you have a large graphic that you are shrinking through the HTML. If you have a picture that is 1024x768 and you use HTML to reduce it to be 200 pixels wide, you are moving a lot of bytes you don't need to move. Scale the image down to the size you are actually using.
3. Increase the compression of lossy graphics. JPEGs use lossy compression.You can re-save the image with higher compression. It will reduce the image quality, but the human eye is just not that sensitive to image quality. You have to compress quite a bit before the effect becomes really noticeable.

All of this applies to video and audio, as well.

The second issue is IP Addresses. When you use SSL, it essentially requires port 443 on the web server to be dedicated to just that one web site. Many web servers serve up multiple web sites on the same IP address. For example, I have one IP address serving 17 web sites on unencrypted port 80. The way it does that is that when a web browser talks to a web server, it puts a line called host into the HTTP (HyperText Transfer Protocol) header saying which domain it wants to talk to. When the web server gets that request, it then routes it to the appropriate web site. All well and good on unencrypted web sites.

But if the content is using SSL, then it can't serve up multiple web sites from the same IP address. When the server gets the HTTP packet, it is encrypted. The host line is in the encrypted packet. But the certificate necessary to unencrypt the packet is a part of the web site. The server doesn't know which web site to go to until the packet is unencrypted, but can't unencrypt the packet until it knows which certificate to use. It's a chicken and egg problem. Since there can be only one web site for SSL, the server just sends the content to that web site and everything works.

Web browsers normally ask for SSL on port 443. Moving things to other ports can work, but not in the general case. Configuration of firewalls frequently block ports other than port 80 and 443.

So the normal way of handling it is give each SSL web site a different IP address. Which would be great if there were an infinite amount of them. Unfortunately, at least under IPv4 (Internet Protocol version 4), there aren't. There are exactly 4,294,967,296, and some of those are for special purposes and can't be used. Virtually all of the 4 billion IP addresses are taken. There just aren't enough IP addresses for every web site to be on its own IP address.

The solution is IPv6. IPv6 changes the number of IP addresses to be 340,282,366,920,938,463,463,374,607,431,768,211,456. That should be enough to hold us for a while. Except IPv6 has been very slow to be adopted. There are a bunch of hardware and software changes that have to be made throughout the Internet for it to work. When IPv6 gets here, there really is no excuse not to have SSL on every web site. I expect it to take about another 10 years before there is a wide adoption, though.

The cost for site SSL certificates deserves its own rant...I'll do that one later.

Sites where you can get an IPv4 address should be on SSL wherever possible.