We all know them: invalid ssl certs. But how bad are they? And what can we do to improve the situation?

Users

Basically the users are a weak link in multiple directions. If we teach users that ssl certs that are bad are OK to accept and continue as if nothing is wrong, we are taking away all their defense against man in the middle attacks.

Equally we allow our users to accept and continue interacting with websites that by providing an invalid certificate actually proofed there is something wrong with them.

We should get to a situation where we can teach our users in awareness sessions to *never* to accept a ssl cert that is apparently bad.

In order to get there, we need to make sure we get good certificates signed by a recognized CA in all our uses of ssl certs such as our websites. One of the things to do is to take care with "temporary" setups and to make sure we are proactive in renewing certificates.

Is your calendar marked to renew your certs?
Do you know when they will expire?

Man in the middle

Man in the middle attacks on ssl enhanced connections are actually prevented by having the certificates and the ability to verify them. The security is for a large part centered in the procedures used by the certificate authorities (CA) you accept to use.

As long as we cannot teach or prevent users from accepting bad certificates, we will always loose this fight. Phishers and the like can work through ssl+strong authentication if we let our users fall prey to man in the middle attacks.

Do you teach your users the hazards of bad certificates?

Self-signed certificates

Self signed certificates, having no recognized CA signing them, aren't by definition bad. They however complicate things: Users should verify the certificate before accepting it. Such verification can be done using a fingerprint and an out of band communication. As this means additional work, one would expect the use of a recognized CA is simpler, still one finds these often.

If you use self-signed certificates, make sure you know how your users will (or will not) deal with it, make sure to setup that out of band verification and make sure that you have the right reason to do this. If you use a PKI infrastructure, make sure all users have your root certificates as needed so they do not get errors.

If you have self-signed certificates, how many times do you get called for verifying the fingerprint(s)?

CA

A certificate authority should have very strict procedures to verify you are who you claim to be before signing your public key. There have been a few problems in the past with reputable companies e.g. signing certificates claiming to belong to a well known software vendor. So these procedures are not foolproof. That's why there are revocation lists, unfortunately many clients neglect to verify those lists.

Not all of the CAs use the same procedures to verify who's certificate they sign, choosing it right is key: you want as many as possible of the others to recognize the CA as bing a good and reputable company with strict rules, but you want them to be flexible enough that -esp. hen they are located in another country- are possible to work with and actually have procedures where you can jump through their hoops.

Do you know what CAs are out there? What the strength of their procedures is?
How was your CA selected ?
Bo you know what CAs are in your browser?

Browser makers

Most of us think of the users as the weakest links, but honestly, the browsers the users use are the weakest link in reality. They simply lack all backbone in preventing the users from hurting themselves.

Doesn't you car make an annoying noise when you do not wear your seatbelt while driving it?

Then why does your browser only need an obscure "next" to proceed on to a website that has a bad cert ? Why not:

• Prevent access to websites with bad ssl certs (the site basically proofed it isn't who it claims to be!), putting the burden of having right certificates with the website owners.
  
• Show a red overlay on every pageload/refresh warning the user the site is not to be trusted
• Not to allow use of forms to send data to a https site that has a bad cert
• Not to load images, scripts, ... from such sites
• ...

And as far as bad certificates go, how about telling the user what is wrong with the certificate in understandable language. While at it, make the text there easy to cut and paste so users can talk with the administrators.

While this might seen hard to sell to consumers, I'm not sure it would be that hard to sell to administrators in a company wanting to step up security a notch or two.

Since browser makers also choose for most of the world what CAs are trusted and what not, how about making that choice a bit more under the control of the administrators of the computer ?  E.g. if you delete a CAs root cert, how about not adding it again at every patch, making the admin redo the thing over and over.

Did you think of the impact of users switching browsers on the list of CAs they trust?

Conclusion

I think we need to eradicate bad certificates on all of our websites. Next, teach our users significant better habits and start by increasingly making those bad habits harder to have in the browsers we let our users use.

--
Swa Frantzen -- NET2S