Concerned about recent PAN-OS and other firewall/VPN CVEs? Take advantage of Zscaler’s special offer today

Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Security Research

The Web Has Still Not Switched To SSL-only

August 11, 2011 - 4 min read
In November 2010, the release of Firesheep highlighted the dangerous consequences of not using secure HTTPS transactions. Following this, I provided some of the reasons why the web has not switched to SSL-only yet. There have been some improvements since, notably Google+, which works only over HTTPS, and from Twitter.

But those are very small steps. A lot more needs to be done.

SSL by default

One trend involves offering HTTPS as a new option. Facebook and Twitter took this path. Unfortunately, the option is usually disabled by default. Half of the users do not understand what this option does and the other half is not aware of the new feature well hidden in their profile!
HTTPS option under Security settings in Facebook

HTTPS should be enabled by default, perhaps with the option of disabling it for the very few users having problems with it.


While Facebook has fixed the 2 bugs I mentioned in the earlier post - SSL: the sites which don't want to protect their users, it is practically impossible to use HTTPS on Facebook. The problem arises from the fact that the use of SSL breaks most of the applications I've tried on the platform. I used to get error messages, now users are warned that they need to switch to HTTP. They have to logout, and login again, to get HTTPS back.
Most Facebook Apps cannot be used with HTTPS
HTTPS cannot be used for popular applications like CityVille from Zynga. I doubt many users will take the hassle to logout/login constantly to switch back to SSL.

Insecure cookies

I've seen HTTPS implemented incorrectly on many sites, including Facebook. The main purpose of HTTPS is to hide the user cookies, so that tools like Firesheep cannot be used to hijack a user session. That means the HTTPS cookie should never be sent over HTTP. There are two ways to achieve this:
  1. Use the secure keyword when sending a cookie with Set-Cookie. This mean the cookie can be sent by the client only over HTTPS
  2. Use a different sub-domain that support HTTPS only (like and restrict the cookie to this sub-domain
Otherwise, when the user connects to the website over HTTP the user session is vulnerable. Unfortunately, Facebook uses the exact same cookie over HTTP and HTTPS, without securing it. If you type "" in your address bar, you will send your cookie in clear text, even if you are then redirected to and simply visiting a site that uses a Facebook widget, a Like button for example, leaks your user session in plain-text, even if you check the "Secure (HTTPS)" option in your profile. Nowadays, it is a challenge to not visit a website that does not contain any element from Facebook...
My Facebook cookie leaked on a random web site (Like widget)

In the end, it does not really matter whether you use HTTPS or not for Facebook. Your Facebook cookie will be leaked when visiting other websites anyway.


Google did the right thing with Google+. The website works with HTTPS only and there is no way to use HTTP. User cookies cannot be sent in clear text.

You can also use their search engine over HTTPS, unlike Bing, which does not offer a secure alternative.

But Google still has some work to do on the rest of their current web applications. For example, the Google Personal Home Page cannot be accessed over HTTPS (users get redirected to HTTP) and Adsense, the major adverting network, does not support HTTPS, which leads to a Mixed HTTP/HTTPS warning for sites would would like to use SSL.


The situation is even worse in the mobile space. Most of the applications used on smartphones and tablets need to contact a web server to function: to retrieve advertising (Admob/Adsense Mobile), to get data from a web service, etc. But there is no way for the user to know whether sensitive information is sent over HTTP or HTTPS. There is no UI element equivalent to the lock shown in browsers and no visibility into the URLs. Researchers have illustrated that mobile developers cannot be trusted to secure communications, as all too often, they send user credentials in plain text.

While some websites have taken a few steps to protect the users, there is still a great deal to do. HTTPS should be enabled by default on all new web sites requiring user authentication. HTTPS should not just be required for login, it should also be required for all requests sent with a cookie.

-- Julien
form submtited
Thank you for reading

Was this post useful?

dots pattern

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.