Recently, a certificate authority (CA) named Diginotar mistakenly issued valid wildcard SSL certificates for some major websites such as Google, Mozilla, Yahoo, WordPress and the Tor Project. Security experts and application vendors considered this a serious threat to the essential web of trust that the Internet rests upon, and have moved to invalidate Diginotar-issued certificates in their software products.
Many of our clients operate e-commerce applications, and for them, purchasing an SSL certificate is an essential part of doing business online. However, it seems to me that some clients and readers may not fully understand what an SSL Certificate is or why they’re needed. This blog post will hopefully help to explain that.
What is SSL?
The Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are protocols that allow two parties to communicate over a network without any other parties listening to or tampering with that conversation. These protocols are part of a much larger field of computer science known as cryptography.
Let’s say that Bob is doing some online shopping at Alice’s e-commerce store, mirrorsbyalice.com, and finds a product he wants to purchase. Bob needs to send Alice his credit card information privately so that nobody but Alice gets it. Alice, being quite tech savvy, knows that there are two primary ways this can be done:
- Symmetric (conventional) cryptography in which Bob and Alice share a secret key that can be used to encrypt or decrypt the credit card data.
- Public key (asymmetric) cryptography in which there are two keys, one public and one private. The public key can be used to encrypt the data and only the private key can be used to decrypt it.
Conventional cryptography suffers from a major problem in this scenario. How do Bob and Alice exchange the secret key securely? Well this is the same problem they were trying to solve in the first place with the credit card data! Alice reasons that the only viable method to use for e-commerce is public key cryptography. So Alice generates a private/public key pair and sends Bob the public key so he can use it to encrypt his credit card data.
But wait! Bob is no dunce. How does he know that the public key he receives was sent by the real Alice? This is where certificates come into play.
SSL Certificates
An SSL certificate associates a public key with some sort of identifying information for the party (Subject) that sent it. Certificates are issued and signed by a Certificate Authority (CA). Technically, anybody can issue and sign a certificate. Alice could even act as her own CA and generate something called a self-signed certificate. Although self-signed certificates accomplish the goal of ensuring that the conversation between Bob and Alice is encrypted, Bob still has no way of ensuring that he’s talking to The Real Alice™, and therefore they are not good to use in e-commerce transactions. If Alice wants to assure her shoppers that the certificate really came from her, then she needs to purchase one from a trusted third-party CA.
Certificate Authorities and Certificate Chains
The Internet is built on a web of trust. Each certificate requires the issuer to verify and assure the identity of the certificate subject. As mentioned, this is usually done by a trusted third-party CA. However, the question naturally arises, who verifies and assures the identity of the issuer (CA)? The answer is that there is no one central authority. A number of companies over the course of time have established themselves as Root-Level Certificate Authorities. These companies, such as Thawte andVeriSign, have self-signed certificates and most applications and operating systems are pre-configured to trust them. CAs can also sign each others certificates, effectively delegating authority to another CA. The hierarchy of certificates leading back to a Root-Level CA is known as a Certificate Chain.
Hopefully now you can appreciate the gravity and consequences of the story that opened this post. If one of those trusted CAs gets compromised and issues a valid certificate for a well-known organization, then anyone who has one of those certificates can pretend to be that organization and intercept private communications.
Certificate Types and Certificate Signing Requests (CSR)
Alice realizes that she needs to get a certificate issued by a trusted CA in order for Bob to feel secure in sending her his credit card information. After some research, she realizes she needs to make a few decisions first. Specifically, she needs to decide what kind of SSL certificate to get, and how she wants to be identified in that certificate.
Although CAs come up with all kinds of names for their SSL offerings, they generally fall into different categories based on the level of identity verification or the number of domains (Common Names) they certify:
By Validation
|
Description
|
|---|---|
Domain Validated (DV) SSL
|
The CA checks only that the applicant owns the domain in question.
|
Organizationally Validated (OV) SSL
|
The CA verifies that the applicant is a legitimate business by examining business credentials and physical address.
|
Extended Validation SSL
|
The CA performs an extensive verification and background check on the applicant. Turns the address bar in browsers green.
|
By Common Name
|
Description
|
Standard
|
This is the standard, good for one domain name.
|
Wildcard
|
Valid for *.example.com. Which includes any subdomain (www.example.com, mail.example.com) but NOT the parent domain (example.com)
|
UCC/Multi-domain
|
Allows for multiple names in a single certificate (www.example.com and example.com and someotherdomain.com)
|
Alice decides to purchase a standard, domain-validated certificate for www.mirrorsbyalice.com. She first generates her private/public key pair on the server that hosts her website. While keeping the private key secret, she then generates a special message called a Certificate Signing Request (CSR) which contains information identifying her business and the public key she just created. She sends the CSR along with any other proofs of identity required to the Certificate Authority. If approved, the CA will send back a certificate that has been digitally signed with the private key of the CA.
Bob’s Browser
With certificate in hand, Alice installs it on her web server and configures her e-commerce application to use it for checkouts. Bob can now click on the checkout button on the website. His web browser will change the communication protocol from HTTP to HTTPS, indicating that it is now communicating with Alice’s website over the Secure Sockets Layer. Since Alice is using a certificate issued by a CA that Bob’s browser trusts, the location bar in his web browser changes to Blue and a little lock appears. Bob now feels much safer about sending his credit card and other personal information to Alice.
Conclusion
SSL/TLS protocols can be used any time a message needs to be sent privately over a network, not just for web browsing. The same technology is used by email servers, FTP servers, and several other internetworking services. As you can see, trust is an integral part of the operation of the Internet, and breaches and misuses of that trust can have far reaching implications. With regard to the Diginotar incident mentioned at the top, many major software vendors have removed this CA from their list of trusted authorities. As an end user, if you see a security update for your browser come through anytime soon, make sure you act on it.
Posts
No comments:
Post a Comment