Wandering Thoughts archives

How https: should work

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.)

HTML character sets

I started with a simple question that was vaguely orbiting in the back of my mind: are HTML numeric character entities always in Unicode, regardless of the character set of the HTML web page? The answer is yes, and that I was asking a misleading question.

Despite being called 'charset' in HTTP headers and META declarations, what you are declaring is actually the web page's character encoding, not its character set. HTML is specified as always being in the Unicode character set, although the encoding of characters in the document can vary, so numeric character entities are always in Unicode.

(All of this can be found in the W3C spec, which is even relatively clear.)

Browsers display HTML by at least logically converting the incoming web page into Unicode and then figuring out how to render all of the characters. If you do not have Unicode fonts for everything, Firefox will hunt around through the fonts that you do have in various character set encodings, using its charset to Unicode maps in reverse to find one that has the necessary Unicode character. Interesting things happen if the fonts you have do not have all the characters that Firefox expects them to have.

(This is probably not an issue to people who are using stock Firefox builds with relatively stock fonts on modern Unix systems. I use a custom-compiled Firefox with a wacky set of old-school bitmap fonts as my default fonts, so periodically various 'smart quote' characters drop out on me and I get to go on another hunting expedition.)