How https: should work

November 19, 2006

I just got yet another prompt about certificate issues on the occasion of visiting yet another website (I think because it had a self-signed certificate, but who can tell with Firefox's dialog about it?). And all this reminded me of how badly implemented SSL is in web browsers.

There are three actual good things that can be done with SSL: encrypting the conversation, stopping man in the middle attacks, and certifying that the website is in some sense trustworthy. The web SSL experience is so bad because right from the start, browsers tried to roll this all into one blob that's strongly biased towards the last thing.

Here's how it should work:

  • always use the website's SSL certificate to encrypt the connection. Whatever else is going on, you're no worse off than if you were not using SSL.

  • only turn the address bar yellow, lock the little padlock, and so on if the certificate is fully signed and valid. (In fact, make a slightly bigger deal of it than browsers do today, to make it clearer to users.)

  • to guard against man in the middle attacks, insist that the certificate either be the same certificate that you saw the last time you visited or that it be fully signed and valid. Be especially insistent about this if you saw a fully signed and valid certificate last time.

    You can't insist that it always be the same certificate; certificates expire, and people can start out with self-signed certificates and later upgrade to 'official' ones. (For similar reasons, you can't insist that the new cert be signed by the same root organization as the old one.)

I think that this would actually provide better protection against man in the middle attacks than the current approach does. The problem today is that by making SSL certificate warnings relatively routine the current approach teaches users to just click OK and go on, while at the same time failing to detect or draw attention to the genuinely dangerous cases.

These changes are unlikely to happen, because the browser SSL world is by and large in the twin grasps of the people who demand mathematically perfect security and the people who make a great deal of money from getting websites to buy signed SSL certificates. The latter have no interest in making non-signed SSL certificates more useful, and the former can point out all of the ways that this approach could fail (never mind that it would probably vastly increase the amount of encrypted HTTP in actual use).

(Yes, yes, by now it's too late; no one is going to switch from http: to https: with self-signed certificates until a large majority of the browsers in the field no longer give (scary) warnings about it, which means that if Firefox, IE, Safari, and Opera all made the change right now we might see significant sites thinking about it in, oh, 2008. I can still dream, and besides, I run bleeding edge CVS snapshot versions of Firefox, so I'd win right away.)

Comments on this page:

From at 2006-11-19 13:28:18:

The same gangs are trying again, though sadly with the same old broken model. This time they're calling it "Extended Validation".

It's going to fail the same way as the current CA/scary-dialog game. The Extended Validation guys are still all about capping the CA liability, meaning the new special color address bars are going to just be the same old game, with no greater assurance. Rinse, lather, repeat.

Ian Grigg says more about the drivers, and does so much better than I possibly could:

Written on 19 November 2006.
« Weekly spam summary on November 18th, 2006
A DiskSuite annoyance: metastat »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Nov 19 13:16:22 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.