Not just plain old http

Filed Under: Cryptography, Data loss, Privacy

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, we redirect you to 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)

, , , , , , ,

You might like

One Response to Not just plain old http

  1. CyberResearchUK · 1020 days ago

    Interesting article apart from that it needs to be updated as it would appear that the padlock symbol has now been removed from Internet Explorer 9. It uses a green block of text of the website name instead. This means that you can no longer rely on the padlock symbol to show that a connection to a site is secure.

    I'm currently writing an easy to understand plain English description of HTTPs on my blog found at :

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog