Digital certificates were originally designed to help authenticate, provide non-repudiation (as with a signature on a courier receipt, a receiver cannot claim he did not receive a document), and to sometimes ensure integrity and confidentiality for written communication on computer networks. Of course, they became the rage for securing Internet-based transactions.
Today some people take for granted that digital certificates are intrinsic to any Web-based transaction and that the transactions are therefore safe. But are the transactions indeed safe? And what, if anything, can users do to ensure they are safe?
To review: Digital certificates are electronic documents, much like an electronic version of a passport. In fact, they contain very similar boilerplate information about both the owner and the issuer of the certificate. The issuer is, one hopes, a certificate authority, analogous to an issuing country in the case of a passport, which is widely recognized and in whom everybody else has complete confidence.
The digital certificate also contains a secret known -- again, hopefully -- only to the certificate owner and to the issuer. The secret is called a private password. The certificate authority publishes a public key or password for each certificate holder. Both the public and private keys are used together to unlock the secrets otherwise encrypted by one of the keys.
For example, if Bob wants to send a confidential email to Sally so that Sally is the only person in the world who can decrypt Bob’s email (even if Bob erroneously sends the email to thousands of other recipients), then Bob encrypts the email with Bob’s private key and Sally decrypts Bob’s email with Bob’s public key.
Further, if Bob wants to provide Sally with even more assurance of confidentiality, Bob again encrypts the already encrypted email using Sally’s public key. Sally will be the only person in the world who can decrypt the message, as it is encrypted with Sally’s public key. So even if Bob erroneously sends the email to thousands of other recipients and then Bob blunders again and makes Bob’s private key publically available, the second decryption can still only be done by Sally.
Another example: If Bob wanted to send an open email to many people, but needed everybody to be sure that Bob was the sender, Bob would encrypt with his private key, and anybody receiving the email would decrypt and read it with Bob’s public key. Bob must have been the sender, so non-repudiation is provided.
Online vendors use digital certificates in combination with the SSL (Secure Sockets Layer) protocol for their encryption algorithms, in order to protect the validity, integrity, and confidentiality of each transaction. Any visitor to a validly secured online e-transaction site should be able to view the associated digital certificate including details of the hashing algorithm used to protect the transaction. In this case, the validation only goes in one direction; only the transaction site is identifying itself conclusively to any visitor.
Browsers show digital certificate information within a security icon, often at the top of the browser page. For instance, Internet Explorer has a green lock icon, which users can click on for certificate details.
Unfortunately, digital certificates are not immune to security meltdowns.
You’ve probably read about a recent SSL certificate validation problem
stemming from a hashing algorithm. This is not the first problem with SSL. There was a doozy in 2009 and another in 2008. And so on. Each time there is a problem, someone finds a resolution, such as changing a hashing algorithm.
Whether industry uses SSL or TLS (Transport Layer Security), there will undoubtedly continue to be developing security vulnerabilities and remediation for them.
The big issue is how to take reasonable precautions to protect oneself from SSL meltdowns. Here is a simple precautionary SSL check-list:
- Do verify that the URL you are visiting is what you expected and not a similar URL with slashes and asterisks where they don’t belong.
- If in doubt, phone the vendor’s headquarters office or site.
- Do take the time to verify the digital certificate on a Website.
- If in doubt, research the certificate authority.
- Remember that not all portions of a Website are secured with SSL. Users can stray to an unprotected area of a site.
Have a secure week.
— Ron Lepofsky, CISSP, is founder and president of ERE Information Security and Privacy Auditors, an information security audit and compliance company.