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.
Related Q&A from Michael Cobb
Expert Michael Cobb explains how an HTTP referer header affects user privacy and outlines changes that can be made to ensure sensitive data is not ...continue reading
Expert Michael Cobb explains the difference between the REESSE3+ and IDEA block ciphers and explores when each is applicable in an enterprise setting.continue reading
While cookies are critical to delivering personalized Web content, they are a privacy concern. Learn how adding Bloom filters to cookies can help ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.