Don’t be SSLy!

One of my pet rants is on SSL, or specifically the inappropriate use of SSL on large websites. This is hardly a novel problem, yet even Fortune 500 bank websites continue to make this glaring mistake on their homepages.

A common scenario:

You need to log into your bank / credit card / mortgage company. You go to, and up comes their home page with a typical login panel (“Login:”, “Password:”). The URL is still HTTP but there’s a nice padlock icon next to the “Submit” button, and lots of “Hacker safe” iconography everywhere. Having confidence that the site is truly “safe for hackers”, you enter your information and hit submit. Right?

Wrong, of course.HTTPS (usually SSL or sometimes TLS), is used for two reasons:a) Authentication (of server and occasionally client)b) Encryption (of bi-direction communication)The goal of those is to ensure that, respectively:a) You are really talking to whom you think you areb) The content has not been modified or inspected en-route by a 3rd partyWhich means that if you are interacting with a page that is served over HTTP instead of HTTPS (even if it is your bank’s homepage):a) You don’t know who you are really talking to. It could be your bank, it could be a man-in-the-middle attacker, it could be anyone at all.b) You don’t know if the content has been modified en-route (injected with a malicious payload, or just modified to send your credentials to the attacker’s server rather than the bank’s).In fact, short of inspecting every bit of HTML, CSS and JavaScript that comprises that page (including all the stuff it loads dynamically), you can’t be at all sure of where your credentials are being sent… even if the form destination URL seems legitimate it could be overwritten on the fly by JavaScript at submit time or via redirects.Which means that little padlock icon next to the submit button is worse than useless. In fact, it trains the user to believe that are doing something safe when that is far from the truth. Same for any “hacker proof” iconography. The only icon that matters is the padlock in the browser address bar.So as a developer, what can you do? Simply, ensure the very first communication the user has with your website is secured via HTTPS. If the first interaction with your site is not secure, how can any subsequent interaction be secure? You could try using redirects to HTTPS, but any smart attacker will simply modify those pages on the fly to remove the redirection to HTTPS, and leave the user insecure.Honestly this is simpler advice in theory than practice. For truly sensitive websites like banks, the above approach is the only acceptable design, with the caveat that the user will usually not try the HTTPS:// URL by default. So you will need to redirect all HTTP requests to their HTTPS equivalents. This still opens an attack window during the redirect, but hopefully the user will bookmark the HTTPS homepage afterwards and link to that directly. Some browser URL auto-complete features will now remember the final (redirected-to) URL instead of the initial one, which can also provides a measure of protection.Still, at least you have avoided committing the cardinal sin of serving a login page over HTTP. Or worse yet, FORCING the user to HTTP for the home page login, as some large banking sites still do… those get an “F” (how that can pass a real security audit, I’ll never understand).But outside of banks, healthcare and other very sensitive websites, many websites have largely non-sensitive public content, and then maybe a small online store that has to be secured. At some point the user may have to switch from HTTP to HTTPS. This is a real bummer. All you can do then is to ensure you provide (and redirect to) an all-HTTPS login screen and shopping cart / checkout process. But be aware this is a poor compromise compared to providing the entire session in HTTPS.As an aside, I’ve frequently encountered skepticism and misconceptions of these sorts of man in the middle attacks and associated costs of mitigation:- Man in the middle and similar injection attacks are very difficult to execute and mostly hypotheticalFact is, man in the middle attacks are pretty easy.In a coffee shop, airport, hotel or similar public wireless environment, they are trivial. Its common to see fake AP’s like “Free wireless access”, hoping to lure a poor sucker into associating with a hacker’s access point. At which point its simple to change DNS information, or to inject packets. However, toolkits also exist to inject code via wireless packets even when associated with a valid open access point, making the attack trivial through no fault of the user (other than not insisting on HTTPS). Without HTTPS, no interaction in these public wireless environments is remotely safe.Even when using a home network via ethernet cables or WAP-protected wireless networks, system compromises of ISP infrastructure are relatively routine (especially smaller ISPs that don’t invest as much into security). Attacking DNS servers to reroute banking and financial services requests to the attacker’s servers is a very attractive phishing attack, and impossible to detect without HTTPS.There are a plethora of related network attacks such as ARP and DNS poisoning that can redirect a user to the wrong server.- SSL is expensiveHardware SSL accelerators are pretty inexpensive lately and reduce any performance impact to a negligible amount. Have an all-SSL site decreases the development and testing cost of managing all those HTTP -> HTTPS redirects.

2 Responses to Don’t be SSLy!

  1. Ammar says:

    Do you really recommend to have an all-SSL websites for any website that parts of it involve sensitive data transmissions?[Lucas]: Well, that’s really the problem isn’t it. The quick and dirty answer is: well, there isn’t one. The primary problem is managing the transition from HTTP to HTTPS. In an attack scenario you need to assume that all HTTP content is untrustworthy. So if an attacker has hijacked your content, when you do want to switch from HTTP to HTTPS mid-session, its already too late. But going all-SSL is more than most sites want to bite off, so you end up with a compromise model that has to make that transition.At that point all you can hope for is that the user will look at the browser’s address bar to validate the host and domain in the URL and ensure they are using HTTPS. Needless to say, few users are security savvy enough to do that.

  2. Anonymous says:

    I’m looking at you, ! Get your act together.