Not just plain old http

Yesterday, I heard a radio interview about on-line security. Unsurprisingly, the discussion got around to encryption, SSL and https. Inevitably, the interviewer asked, “What should we look for to make sure that a secure web page really is using https and not just plain old http?”

This turns out to be a really tricky question to answer on the radio.

Sure, you need to “look for the padlock.” But how do you explain where to look? A padlock in the browser’s content window confers no trust at all, since it is merely an image submitted by the web page you are visiting. The https padlock must be displayed in the browser’s so-called chrome – the pixels which make up the browser’s own user interface components. (When I say chrome, I don’t mean Google’s work-in-progress browser. Google cheekily chose to name its browser after Mozilla’s now widely-used terminology.)

Correctly-implemented browsers go to great lengths to ensure that external content – including HTML, scripts, images, videos and other embedded objects – cannot control the chrome. Only the browser’s own code should be able to affect the appearance of the user interface itself. So only the padlock displayed in the chrome can be trusted.

Sadly, however, even when you have explained how to differentiate between content and chrome, https is still not just a matter of looking for the padlock. This is because of a pet peeve of mine –the tendency of many websites to request secure login credentials from a plain old http page, like this example from Brazil:

Many airlines, car rental companies, banks and other on-line merchants do this. You are encouraged to enter username and password details, to click the relevant button, and to assume that the form will be submitted via an https connection. (On IE7, hovering over a form button sometimes reveals the URL which the form will use. On Firefox 3.5, it does not, unless you use the FormFox plugin.)

I really wish that websites with secure login forms would take to you a secure page first – allowing you to “look for the padlock” at your leisure and, if you wish, to examine the offered SSL certificate before entering any personal details.

Of course, doing it this way isn’t as convenient. And just because you fill in a form on a web page which was served using https doesn’t guarantee that the form submission will use https. (On Firefox 3.5, there is the handy option to “warn when you leave an encrypted page for one which is unencrypted”, which actively helps to avoid such situations.)

Nevertheless, I think it is useful to separate cleanly the encrypted parts of a website from the unencrypted parts. If nothing else, it ensures that all login pages are hosted at secure URLs which can be navigated to directly, so that you never need to enter personal details on a form served up in an insecure, and thus padlock-free, page.

We separate secure and insecure pages for Sophos product downloads: if you visit http://www.sophos.com/support/updates/, we redirect you to https://secure.sophos.com/support/updates/ before we ask you to login or to register for a MySophos account.

I greatly prefer websites which work this way. What do you think?

Logins to secure web pages should begin from…(polling)