Buyer Beware on SSL Certificates
This post comes from Peter Hesse. Peter knows a thing or two about SSL Certificates. With apologies, Peter submited this a while ago. The recent FireSheep hooplah triggered the SSL thought, which triggered this unrelated post.
by Peter Hesse (@pmhesse)
Earlier this week, a phone call from a friend drove me to write this on twitter:
I then received a few followup messages on twitter, and ended up responding to an SSL vendor by email, which in turn inspired me to write this post.
As background, I have worked in/around/with public key infrastructure (PKI) for nearly my entire professional career. My first software development job was working on a certification authority reference model for NIST in 1996.
So, I know a thing or two about SSL certificates. For example, I know they cost far less to create and maintain than SSL vendors typically charge. There is no additional burden on the issuer between the different levels of certificates: the costs of hardware, hosting, audit, etc. are very similar between the types of certificates (perhaps excluding extended validation or EV certificates).
I can understand charging more based on the speed of issuance of the certificate, and the quality and depth of the validation performed to ensure the requestor works for the organization whose name will appear in the certificate. After all, you can usually only pick two of [faster | cheaper | better]. SSL certificate issuers are free to charge what they think people are willing to pay for certificates rather than trying to relate it to the actual cost of creation and management. That is their right, and it is my right to call them out when I feel the prices are ridiculous.
The "scam" of SSL certificates these days is that the sales representatives are being trained to use fear, uncertainty, and doubt to scare people into buying more expensive certificates than they need. The following is from a friend relaying his exchange with an SSL vendor: Sales rep stated our current certificate is hackable because it can go down to 40bit, explained that this makes us vulnerable. I argued
"I only allow 128-bit at the server", and he said "yes, but since your cert is only 40 bit it can still be compromised; you need a server gated cryptography certificate."
If you know what you are doing (security wise) you will block all weak cryptographic ciphers at your web server. This may prevent older browsers from being able to connect to your site, but will ensure the cryptographic strength is always high. The sales representative was trying to scare my friend into thinking this wouldn't do the trick, which is patently false. The following link gives some good reasons why SGC certificates are a bad idea and don't solve the weak encryption problem. Even the wikipedia entry for SGC calls SGC certificates "obsolete" (and no, I didn't just go edit that entry to say that... as far as you know, anyway *evil-arched-eyebrows*).
The sales representative also continued the discussion to try and convince my friend that one certificate wasn't enough. In discussing his configuration, he revealed he has many back-end servers which all sit behind an SSL-offloading load balancing proxy. The sales representative tried to convince him that he would now need to buy a certificate for each of the back-end servers to afford him the best protection. So instead of needing one or two certificates, my friend was going to need twenty! Yes, I think we all know that defense in depth is important and he should indeed use SSL between his proxy and the back-end servers. Paying $50-$1500 each for browser-trusted SSL certificates on the back end is just a flat-out waste of money.
Self-signed certificates, or certificates generated by an in-house PKI would provide at least the same level of security at a far reduced cost. So, there you have it. Make sure you know what you need before you try to buy an SSL certificate. The sales representatives are willing and able to charge you whatever they can scare you into believing you need.
