Q

HTTP vs. HTTPS: Is digital SSL certificate cost hurting Web security?

Learn why a digital SSL certificate could be the reason preventing many users from utilizing HTTPS.

What prevents all Web browsing from being conducted over HTTPS instead of HTTP? For example, for Facebook.com, the authentication takes place over HTTPS, and after that the whole session is normal HTTP. Why don't websites just use HTTPS for the whole session?
The reason websites do not encrypt every page is that SSL involves a tradeoff, improved security versus cost and slower response times. In order to deliver a site's webpages over SSL, it needs a digital SLL certificate. A one year VeriSign SSL Certificate with Extended Validation costs $995 a year. That's a lot of money for a corner store that has a static website that's sole purpose is to advertise its existence. Security controls should be adequate and proportionate to the identified risks so providing an SSL connection to this type of website would be completely over the top.

One historical reason why pages from a website with a digital certificate wouldn't be sent over SSL is because

the encryption process slowed down the delivery of the pages. A lot has to happen when using SSL even before you get to the bulk encryption of the data that is being exchanged between the server and client. In the pre-broadband days when pages loaded slowly anyway, Web designers were reluctant to encrypting every page and adding further delays for visitors to their sites. (This is the reason most home pages don't use SSL, as the designer wants you to see it as quickly as possible so you don't lose patience and go somewhere else.) Also, most browsers don't cache documents delivered over SSL, so this would generate a lot of extra Internet traffic and result in pages loading more slowly as they would have to be fetched from the Web server each and every time.

Let's look at your Facebook example. It can certainly afford a digital certificate and it indeed has one, which is used for its sign-in pages. On busy Web servers that do use SSL extensively, such as bank websites, a co-processor board called an SSL accelerator is used to handle the SSL public-key computations. This enables the Web server to offload some of the work involved in delivering pages over SSL, which speeds up their delivery. I'm sure a high-traffic website like Facebook employs some form of SSL accelerator, but it would still be impractical and unnecessary for it to deliver every page over SSL.

To be clear, SSL does not make a website secure. It only provides site authentication and encryption of data sent to and from the website. Knowing who you're communicating with and keeping that communication confidential are essential in order to offer a secure login process, which is why SSL is used by Facebook on its login pages. If the login form is not SSL protected, you can't authenticate the site; even if the form data is sent over SSL, if the login form is not SSL protected, you can't authenticate the site until after you have sent it. So, even though your credentials are encrypted, there's no way to know who you're really giving them to.

An SSL connection provides a way to check that the page you're on is coming from the site you intended to reach. When you see the secure lock symbol, you can check the SSL certificate to see what the organization name is, and who issued the certificate. This gives you a way to check that you're at the right site. This ability to check that the page you're on is coming from the site you intended to reach and know that data can't be read by anyone else is why we use SSL. But that's as far as SSL goes. It has no ability to protect the information once it arrives at the website and no inference can be made as to how securely it is processed and stored by the website and its owners.

This was first published in July 2010

Dig deeper on Network Protocols and Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close