HTTPS Should Not Be A Trust System

June 16, 2006 General

One thing about the intarweb that continues to frustrate me is SSL for HTTP. Somewhere along the line, someone decided that the ability to use HTTP through an encrypted stream was a good idea, and I couldn’t agree more. But what I disagree with is that the use of HTTPS by a web site should be used to imply that the website is trustworthy. The idea of an encrypted HTTP transport has been marred by merging it with the idea of “certificates” - that is, to let your users take advantage of HTTPS, you need to obtain a certificate from one of a few companies (VeriSign, for example). If you shell out for a certificate, everything is hunky-dory. If you fail to do so, any user who tries to access your website through an encrypted stream is presented with a message from their user-agent that informs them that your website is not certified, and therefore exists only to steal your identity, install deadly viruses on your computer, and eat your children while you’re sleeping.

Why? Why does this trust/mistrust scheme, which is only determined by who is willing to pay a thousand bucks for a certificate and NOT by how trustworthy a site actually is, have to be incorporated into the idea of HTTPS? Why can’t trust be handled separately? I think issuing certificates is a great idea, but why should my users be denied the use of encrypted data transport (or at least frightened away from my site for trying) simply because I’m not willing to shell out for a certificate? I’m not collecting any personal information or credit cards. I just want to protect users from getting their passwords intercepted by men-in-the-middle.

The worst part is that it’s far too late to correct the problem. Users are so accustomed to assuming that any site with “https://” in front of it is trustworthy unless they’re told otherwise. If the certification was suddenly separated, identity thiefs would have a field day. Sigh.

So yeah. The hell with that.

1 comment