Thursday, August 11, 2011

The Web has still not switched to SSL-only

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.

Facebook

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 encrypted.google.com) 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 "facebook.com" in your address bar, you will send your cookie in clear text, even if you are then redirected to https://www.facebook.com/ 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

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.

Mobile

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

3 comments:

Anonymous said...

Using G1 ,your link in here for Ggl's Search Engine. I get
Https://encrypted.google.com but if want to enter to surf secured, i obviously am redirected unnotified(..) towards http://search.google.com/m or thelike.
(Dutch, using T-Mobile.nl a very much MS-directed institution)
Mind MStries tokeep all things open SILENTly. It does not like communicating really open: would show their real face. Except for "business-private" purposes of course.

Anonymous said...

(Trying to leave page after "comment stored"
A real American thing, yes'in' no?'out'?
:-)

Like this sites cursor behaviour,= very stable.
Maybe you can care Blogger's mismanaging of users 'secretword's ? Within http instead of https ? They offer mobile version and wiped my existing 'secretword' on entering, without warning..

janny said...

Web security got a shot in the arm last year when the FireSheep network sniffing tool made it easy for anyone to capture your current session's log-in cookie insecure networks—your local coffeeshop's hotspot or public WiFi at the library. That prompted a number of large sites to begin offering encrypted versions of their services via HTTPS connections.
http://www.pcs4cheap.ca