Dan Kaminsky’s SSL Hell


Here is another segment from Dan Kaminsky’s talk at Toorcon 8. You can download the high quality version here. He discovered approximately 1 in 3 deployed SSL boxes share a private key. This means that you can buy a box off of eBay and read encrypted SSL traffic from any identical box. He has also got a trick for making bank logins more secure.

10 thoughts on “Dan Kaminsky’s SSL Hell

  1. Who is this guy, and why does he think this is a discovery? I’ll do him one better. Just put the entire login form in the , and then redirect the parent when the login completes.

  2. I don’t get the math here perhaps..

    If 90% of the keys were unique, then how can the remaining 10% make up 1/3 of the computer’s he scanned? Or is he just extrapolating the 1/3 figure based on 10% of the billions of the SSL servers out there? (I.e, it’s just a guess)?

  3. Well, tj,

    2/3 of servers have unique keys. Those use ninety percent of the keys that are out there. 1/3 of the machines share the remaining 10% of keys. Quick math says that keys that are not unique are used on average 4.5 times.

    2/3 of servers have 90% of keys. (thus 1/3 has 45% of keys, 1/3 has 45% of key, 1/3 has 10% of keys) The last group reuses keys.

    Am i wrong?

  4. Not paying attention ;-)

    90% of the _keys_ were on unique machines, they make up 33% of the possible machines on the net. The other 10% of keys cover the last 66% of machines.

    i.e. for every 10 keys there are 9 unique machines and 27 machines sharing a key

  5. nocotigo: The reason that just putting the login form in the iframe would be bad is that you would then lose the performance benefit. It would mean that *every page* on your website would build an SSL connection.

    And that’s what he’s trying to avoid. He wants a situation that means you get the ideal situation for:

    1) Performance: never use SSL except when logging in or using the secure areas.
    2) Security: always use SSL when logging in.
    3) Usability: there should be a login form on every page.

    The only way to avoid using SSL when surfing on regular, non-secure pages, and yet to use SSL when logging in from those same pages, is to build the SSL connection only once people have started to log in.

    I’d add to his suggestion, though, that it needs to handle auto-fill-in of forms. Some browsers will automatically fill in the username and password on every page, which again destroys the performance benefit, or, if it doesn’t trigger the onfocus, destroys the security benefit.

    So if the login form got filled in *really fast*, then I think there are two options:

    1) blank it (if you want to force them to manually type it in every time, which I would strongly NOT recommend, since it adds nothing to security, and just alienates users), or

    2) make the onfocus have a bit of a delay in, so it doesn’t start up SSL unless it is being manually filled, and then have an onsubmit that does the same thing as the onfocus if it finds that the iframe has not been made. None of which is difficult.

    So long as this method degrades gracefully for browsers without javascript enabled (which it should), this is the ideal compromise. Unlike just using SSL for every page, it *would* require a “you need javascript to be completely secure” notice, though.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.