Akamai Edge 2014 continues today with the second day of Akamai University and API Boot camp. To coincide with this, I’m running three security lessons that are part of an upcoming video series. This is the final installment, and was written by Meg Grady-Troia.
SSL Certificate Security and Trust
The Internet is built on a foundation of trust, from machine to machine, extended across the entire surface of the globe. Trust is shared across the Internet in many ways, the SSL certificate hierarchy is only one, albeit a pervasive one. The SSL certificate system was designed so that trusted parties can have private communications over the public Internet. SSL certificates are a critical piece of the Internet’s trust architecture, and many protocols exist to support secure certificate handling.
What is a Certificate?
A certificate is the container for four pieces of information your web browser (or operating system) needs to make a secure connection to the server hosting the website you wish to visit.
Those four pieces are:
1. An “Issued To:” field that specifies the full name and address of the entity that owns the domain you’re visiting (including the IP address & domain name you’re visiting, and the brick & mortar contact for the owning entity).
2. A validity period: The time period (start date and end date) for which that certificate should be considered valid.
3. An “Issued From:” field that contains the signature of a Certificate Authority, that acts like a notary public would on a legal document: a third party witness.
4. A public key: The shareable half of the keypair that will be used by the server to initiate the encryption of data that flows between the website and your browser.
Your browser-client uses the “issued to” data to check that it has connected to the domain it expected. It uses the certificate authority and expiry to verify that it trusts the domain. It uses the public key from the certificate to continue the SSL handshake that will allow all further communication between you and the website to be encrypted.
How do Certificates Work?
Think of SSL certificates as the Internet-equivalent of the diploma granted to a student when they graduate from a school: it may hold value with people who know the recipient but not the school, and it may hold value with people who know the reputation of the school, but not the recipient. The value of the diploma is not a trust currency itself, simply an indication of an existing authenticated relationship.
There are a lot of certificate authorities in the world, and they may be operated by governments, companies, or even individuals (and they range in credibility just like colleges, from diploma mills to prestigious institutions) . This is possible because CAs are initially self-signing: they simply appoint themselves as trustworthy third parties. The value of a CA’s imprimatur depends on its reputation — both past behavior with other certificates, and its relationships with certificate holders and web browser developers — which is how their signatures gain value.
A single web domain — say, www.akamai.com — may have any number of certificates associated with it, and there are many kinds of special certificates online to account for specific use cases.
Some of the most common are:
Multi-Domain (including Subject Alternative Names (SAN) & Wildcard) Certificates: These certificates cover multiple hostnames, subdomains, or IP addresses, and allow end-users like you to be redirected to the same application from multiple hostnames.
Validated (including Extended Validation (EV), Organization Validation (OV), and Domain Validation (DV)) Certificates: These certificates require the signing CA to perform some additional identity validation after their standard process, either for an individual, an organization, or a domain. EV Certificates do not offer additional security for your particular session on a website, but they are often considered to be of higher trustworthiness.
When you initiate a private exchange with a web application — for example, your bank’s portal so that you can check your latest statement — your browser-client will request an encrypted session and the server you’re connecting to will respond by presenting its certificate back to your browser to authenticate itself & initialize the negotiations required during the SSL handshake. Your web browser compares that certificate to its certificate store — a list of CAs that the developers of your web browser considered trustworthy — to make sure that the certificate is both signed by a trusted CA and still valid.
Certificates have a longer shelf life than a carton of milk, but because the Internet is a dynamic place, the stated period of validity on a Certificate may end up being a longer period than the certified entity wishes to continue to use it. Certificates can easily become erroneous or compromised for any number of reasons, including when an entity’s contact information changes, or after a successful attack against that entity. You wouldn’t want your front door’s lock to open to both the key from the old lock that was compromised and the key from the new lock, right?
Because of that possibility, the certificate check performed by your browser-client may also include a status call to see if that specific certificate has been revoked — that is, been deemed invalid by the CA or owning entity. While there are several ways to check if a certificate has been revoked, all of them take extra time & effort during the SSL handshake. Not every browser or operating system — particular older or slow ones — will perform any kind of certificate revocation check.
How do Certificates Facilitate Trust Relationships?
Once you and your browser have decided to trust the presented certificate, your browser-client may continue the SSL handshake by providing a public key for the server to use (while your browser will use the public key embedded in the certificate) while they negotiate additional settings for your private session. While a certificate will always contain the same 4 critical pieces of information, newer browser-clients allow for additional controls during the session negotiation process, including ephemeral keys, advanced hash and compression functions, and other security developments. This process of certificate check, key exchange, and session negotiation, in a direct reference to the ways we demonstrate trust in real life, is called an SSL handshake.
How does Akamai Handle SSL Certificates?
Akamai has relationships with several Certificate Authorities, and will use one of its preferred CAs to sign customer certificates if a customer does not request a specific CA when they have Akamai provision a SSL Certificate for them. These preferred CAs are widely-used CAs that are generally recognized by major browsers and operating systems.
Akamai generates the keypairs for all of its customers’ SSL certificates for traffic flowing over Akamai networks, using their designated information and preferred cipher suites and algorithms, so that only the public key ever has to leave the protections of Akamai’s networks. By not sending private keys across the Internet from customer to Akamai, we help to ensure the many needed layers of protections around the SSL Certificate’s private key that may be able to decrypt end-user session data.
Akamai has a relationship with some CAs allowing us to sign certificates for them as an Intermediary CA. In these cases, the chain of trust is extended by additional links, with both the originating — or root — certificate authority granting an intermediary the right to sign certificates on their behalf. This process of tiered certificate authorities signing successive certificates, all of which are presented to the browser-client as a bundle, is often called chaining, just like linking daisies together into a chain.
How are SSL Certificates Vulnerable?
Certificates have a number of protections around them, including file types, cipher suites and algorithms, key usage, procurement and handling procedures, unique identifiers, and other data that are all part of a commonly-accepted standard that help both humans and machines protect, identify, and properly use SSL certificates. That common standard is called X.509, and it is used by common SSL software such as OpenSSL, and in lower-stack operations like TLS.
It’s a common adage in Information Security that complexity in a system increases its risk of accidents, and the certificate hierarchy is byzantine, indeed. There are all sorts of ways that SSL Certificates, the private keys affiliated with SSL Certificates, and your private sessions can still be compromised.
Many organizations on the Internet — including Akamai — are considering a number of possibilities to fortify the SSL certificate structure. Some of the possibilities aim to make the current certificate process more transparent, while others couple the certificate process to other areas of trusted computing, like DNS registries. Each of these potential revisions presents some gains and some losses for end-users and certified entities. Newer browsers and operating systems may support additional controls around the encryption for your session on a website, and updated versions of the X.509 standard and TLS support newer models of authentication and certificate protections.
Every party in the certificate hierarchy is responsible for some aspects of the chain’s security. All of the certificate process I’ve just explained gets conveyed to you, the end user, by the small lock that shows up in your browser’s navigator bar when you’re browsing a website via HTTPS. That lock icon is the simplest symbol of the SSL Certificate trust chain there is, including all the vulnerable infelicities of the system and all of the hope we hold for private communications over the public Internet.0