SSL/TLS adoption has received several boosts in the past couple of years. It was almost three years ago that GMail switched its default to SSL, a move soon emulated by other leading email providers, and services such as Facebook and Twitter. Meanwhile the IETF worked to standardize HTTP Strict Transport Security or HSTS, which allows websites to declare that all of their content will use SSL, preempting any attempts to downgrade users to unprotected traffic. In spite of these advances there are still many sites who manage to use SSL incorrectly and jeopardize users.Exhibit A: WordPress, which also happens to be hosting service provider for this blog. WordPress home page contains a login form but is not served over SSL:
One might argue this is acceptable, as long as the password submission itself takes place over SSL. After all, there are two distinct communications with the website for signing in. First the web browser retrieves the login page containing username and password fields. After the user fills in the required information, a second request is made to the website carrying those credentials. Perhaps all is well as long as that second step takes place over SSL? This was in fact the argument advanced by many financial institutions several years ago, when they had the exact same setup with login pages served in the clear.
But that reasoning is flawed. It ignores the possibility of active attacks. Unlike a passive attack where the bad guys are content to merely watch the traffic fly by, an active attacker can also modify it. If the first page was not sent to the browser over SSL, it is susceptible to such tampering. There is no guarantee that what the web browser is displaying the authentic login page that WordPress intended for them to see. For all we know, a miscreant on the network could have modified it with a backdoor which takes a copy of the password, sneaks it away n the background to a server in Russia, before submitting it to the legitimate site to complete the login process as if nothing was wrong.
This is a useful demonstration of how integrity is as important as confidentiality. SSL is often employed to keep sensitive information from prying eyes, on its way from the user to the website or vice verse. But it is equally important to guarantee that content, such as script implementing sensitive application logic, is not modified along the way.
Luckily there are two workarounds for dealing with these websites:
1. Try to load the page over SSL, by editing the address bar to add that all-important letter “S” before the column. (Ideally, book-marking this final URL, to avoid error prone manual URL crafting in the future.) This may not always work, as some websites will redirect their “non-sensitive” pages back to regular HTTP even if they are accessed over SSL. WordPress is an interesting example in this regard. Navigating to https://wordpress.com indeed results in a secure connection. But type https://www.wordpress.com and the site dutifully redirects back to the plain HTTP version subject to man-in-the-middle attack.
Another example is the download location for IronPython, a Python interpreter for Windows. This particular software package is served over HTTP by default. (It also happens to lack any Authenticode signatures–arguably a bigger blunder, since code-signing would have obviated the need for SSL, but that is another story.) Luckily reloading the same page with HTTPS also leads to a download link for the same package over HTTPS.
2. Enter a bogus username and password. Let’s call these the sacrificial credentials. If the login page is indeed working as intended, these will be submitted over SSL and the website will display an error page informing the user that login failed. That page is likely displayed over SSL and now contains another copy of the login form to retry:
Caveat: this behavior is not guaranteed either– websites could choose to redirect the user back to HTTP to render the error page. Fortunately the path of least resistance is to return the error message on the original SSL request. This gives users a fighting chance to inspect the URL and decide if they are on the right page. (After all, in a true attack scenario, the attacker could respond to the bogus credentials with a back-doored error page as well. But at least web browser security indicators such as the address bar will be meaningful when looking at SSL.)
The “right thing” of course is for the site to avoid this vulnerable pattern and display any page containing a login form over SSL. Sites that can afford to serve all of their pages over SSL can go one step further and use HSTS feature to declare that. Because this setting operates at the entire site level, it is not possible to single out specific pages however, ruling out its use for sites who want to keep some content in the clear for capacity reasons.