Tuesday, April 7, 2009

SSL - Who's To Blame?

There seems to have been quite a bit of discussion on SSL over the past few months. I've contributed my two cents to the discussion with recent posts (Compromising HTTP to HTTPS redirects, SSL is out of control, MD5 Collisions Allow Forged SSL Certificates, Pruning the Browser's Web of Trust).

Now I'd like to tackle a different issue with SSL - who's to blame? And by assigning blame I mean, who should the responsible party be to ensure SSL is handled correctly?

As I thought about different scenarios I decided that there are three main culprits.
  1. The Website
  2. The Browser
  3. The User
The Website
Websites tend to shoulder most of the blame when something goes wrong with SSL. In many cases it is warranted. Any site that is conducting business should get their certificates right. Mismatched domain names, expired certs, mixed SSL and non-SSL content, or non-SSL landing pages are all common mistakes and are unacceptable. These issues point to a poor management of security. And that's the main take-away in my opinion. If site can't handle these basic SSL issues, which are fully visible to all of their users, then what else is going on behind the scenes? I will issue the challenge I issued in a previous post. If you stopped using a site once you encountered any sort of SSL error message - how many sites would you actually be able to use?

The Browser
For some reason the browser has hidden away from criticism in the SSL discussion. I believe they are one of the largest contributors to the problem. Imagine if you approached an elevator and there was a sign saying "Elevator cable may snap, would you like to proceed?". That is what the browser is doing with SSL. And the fact that the browser allows users to continue is partly the reason some many sites have SSL issues. Sites would probably address the SSL issues faster if they knew users couldn't reach the site because the browser blocked an insecure connection.

I expect more from my browser. I'd like my browser to do things securely or not do them. I don't want a semi secure connection. When I connect to a website over HTTPS I want the connection to be rock solid. Don't connect to the site if the cert is bad - no matter what. And don't transfer cookies over HTTP (btw, why is this the site's resposnibility to set the "secure" flag, shouldn't that be the defacto handling by the browser). The list goes on.

The other main concern here, is again, this is only what the browser is telling us. There are plenty of other issues going on behind the scene which we don't know about. Remember the SSL mixed content warning? The browser doesn't say which sites the content is from. Clicking continue to this message could very well result in your cookies going over HTTP - and then its all over.

Lastly, I don't think its realistic to expect the average Internet user to be an expert in SSL, networking and security. I say this because these are the skills which are necessary to effectively evaluate whether or not to click "ok" to the SSL warning messages. In fact, I believe that most every SSL warning message from the browser is expecting an unrealistic amount of knowledge from the user. What good is prompting the user if the question doesn't make any sense? This is why I say the browser should do things securely or not do them at all. If you can't get to your bank's website - then good. It woud be insecure to access it anyway.

The User
The last one to blame in our list is the user. In many cases, no technical controls will stop an uneducated user from doing something stupid. And I agree here. If the user provides their passwords to anyone that asks then their is nothing we can do to stop them. Also, if a user types in "mybank.com" and magically hopes they will end up at the secure site, then they are to blame too. I agree that it would be great if things worked that way, but they don't. You have to actually type https every single time. (see Compromising HTTP to HTTPS redirects)

But if we start to fix the websites and the browsers, then we can create a more realistic level of information which we can expect from our Internet users. But in our current situation, can we really get that upset at the average user? What a mess the websites and browsers have created.

-Michael Coates


  1. Hi Michael,

    Always good to read your blog.
    I agree with you on most points, but even though you are the teacher I have to contend on some others.

    Bear with me, as it's pre-coffee time for me.

    The Website
    Fully agree, anybody doing business over the internet should invest in proper certificates and handle them and SSL correctly.
    A good example is a supplier of mine. They have a content only site at their www.domain.tld and then redirects you to manage.domain.tld which only responds on SSL. (and forces you to login first)

    The Browser
    Browsers have gotten a lot more "in your face" about certificates and default to a "Get me out of here" option in most cases. I guess we could debate details.. I think most browsers are heading in the right direction. Surprisingly Safari get's it wrong with their popup.
    I disagree that a browser should keep you from a site just because the certificate is not right.
    The certificate itself is used purely for authentication and a self signed cert for internal sites can not harm (but the onus is on the user to verify the thumbprint)
    Denying access to unsigned certs would basically force many of use to buy certificates for every (internal) control panel we run.
    The certificate mafia would love that.

    The User
    Agree, the user is the bane of all security

  2. Barry,

    Always great to hear from you...

    I know I'm taking a hard stance on recommending the browser restrict access to the site. But I think that's the only way to get people to start addressing the issue. As I mentioned above, I really get concerned when the browser prompts the user for a security decision.

    Regarding internal sites, you can go ahead and use an internal certificate authority and then push the certificate to the trusted root of the corporate machines. This results in a fully trusted connection and no money to the certificate mafia. Just a little bit of work to gain security from internal attackers (which we know are more common than people think).

    Also, as you pointed out, if you always get untrusted certificate messages for internal sites, would you detect someone performing a MiTM attack? Some diligent people check the cert, but many just click continue. Imagine using ARP poisoning on the internal network combined with WebScarab to watch the SSL traffic.

  3. The reason why the web browser cannot set the cookie to "secure" is simple: it does not know when to do it. On the other hand, the website knows.

    Let us say I want to save some information on the cookies. If it has nothing to do with security at all, how could the browser know not to set it as "secure"? There is no way to do it, that is why it is website's responsibility to set cookies as "secure".

  4. Kai,

    My comment on the browser and the secure flag was more reflecting the fact that the browser defaults to an insecure mode. Why not have the browser always set a cookie to be secure? If the site wants it treated otherwise, then they can specify an "insecure" flag.

    Secure by default, I think that's the way to go.

  5. These are good and compelling observations!

  6. Hi Michael,

    You are right of course that companies should setup their own CA and create their certificates from there.
    It does assume a level of technical / security savy that I've not seen everywhere though.

    Another thing I'm exploring for a (personal) project of mine is to force the use of Client certificates (on top of a password authentication scheme)
    My luck is that my target crowd is more security conscious and also more technical.

    I'll let you know how it goes over ;-)

  7. Nice! Client certificates along with username and passwords creates a nice two factor authentication setup. Its good you are keeping the passwords still since certificates have the downside of never really logging out.

  8. This comment has been removed by the author.

  9. Logouts are enforced by a time-out at which point you'll need to revalidate (IE create a new session) to login again. Yes, passwords are still required as anybody could access the servers through your browser.

    I'm also experimenting with other possibilities like a OTP using an sms / email sent to the address on file.
    Not sure which will be more liked by the users


Note: Only a member of this blog may post a comment.