Almost 20 years ago, the first publicly trusted certification authorities (CAs) began generating their root keys and root certificates, which represented the public trust of the first Internet root CAs.

Slowly, these root certificates were provided to operating system and browser vendors to be embedded in their software. Embedding indicated that the software vendor trusted the CA to issue publicly trusted certificates.

The CAs were relatively conservative. They developed certificate polices and certification practice statements. They created sophisticated enrollment and verification practices. They publicly disclosed their policies. And to show compliance, they had their CAs audited on an annual basis.

The certificates they issued were primarily for server authentication to a domain name. The verification practice would associate the server’s public key to the name of the organization and to the domain name which would identify the server on the Internet. This is now called organization validation (OV). The CAs also issued certificates to secure email, to sign code and to perform time-stamping functions.

Around 2002, verification became a little more aggressive. This was the time that domain name validation (DV) started. With DV, there was no check of organization identification, nor what organization controlled the domain name. DV showed that the certificate requester controlled the domain name. Verification and issuance of DV certificates could be done automatically, which decreased enrollment time and cost.

In 2005, the SSL industry wanted to mitigate phishing attacks on domains with a large user base. It was feared that an attacker could attack the DV process and get a certificate for large domains. The CA/Browser Forum was developed and extended validation (EV) guidelines were created. These guidelines could be used to verify certificates for enterprises and with the EV certificate, many browsers would show a green EV indicator and display the enterprise name in the browser chrome.

The CA/Browser Forum continued to develop guidelines and has issued SSL Baseline Requirements, EV Code Signing certificate guidelines and network and certificate system security requirements. The Forum is currently working on Code Signing Baseline Requirements.

In order to support secure communications, browsers and servers have to communicate over a secure protocol. Netscape led the way by developing Secure Sockets Layer (SSL). SSL 1.0 was prepared and then quickly updated to SSL 2.0 in 1995 with a follow-on of SSL 3.0 in 1996. The protocol was then re-defined by the IETF as Transport Layer Security (TLS) with TLS 1.0 released in 1999. TLS has been a very strong and effective protocol with TLS 1.1 released in 2006 and TLS 1.2 released in 2008. TLS 1.3 is in development and may be released in 2015.

SSL communications is done with an exchange of a symmetric key. The key is protected by the web server’s asymmetric private key. 20 years ago, private keys were 512-bit RSA and the certificates were signed using MD5 hashing algorithm. With Moore’s Law, computing has increased and therefore brute force attacks are much easier. To mitigate such attacks, the RSA key lengths have increased to 1024-bit, then 2048-bit and the hashing algorithm has moved to SHA-1, and now SHA-2.

For many years, attacks on Internet secure communications were quite limited. The first big attack was not on SSL, but on code signing when VeriSign issued two code signing certificates to an individual claiming to be a Microsoft employee. Attacks against CAs have been quite limited, but in 2011 attackers struck Comodo, DigiNotar, StartSSL and GlobalSign. In fact, DigiNotar was so badly compromised, it ended in bankruptcy.

SSL/TLS protocol attacks have been limited. But over the last five years, security researchers have found many vulnerabilities with many fun names such as BEASTCRIME, Lucky Thirteen, Heartbleed, POODLE and most recently FREAK. The mitigation to these attacks has been for the server administrators to update software, change configurations and change supported cipher suites.

Due to attack tools and privacy concerns, the push is now to move to Always-On SSL or HTTPS Now. Attack tools such as SSLstrip and Firesheep were developed to support SSL high-jacking. The result was that large websites deployed SSL, so that once it was on it stayed on. In doing so, the sessions could not be high-jacked. In other cases, server administrators would not deploy SSL as they did not ask the browser users for any confidential information. The issue is that just going to the site is private as no one should be able to determine what sites the users are interested in. SSL on all sites would mitigate this detection.

Always-On SSL can be both supported by the browser and the server. For instance, there is a browser plug-in called HTTPS Everywhere. This plug-in will help the browser go the HTTPS version of a web page. From the server side they can use HTTP Strict Transport Security (HSTS). With HSTS, a header is provided from the server to the browser stating that this site should only be viewed over HTTPS. In the case that the site is presented without HTTPS, then a user warning would occur.

Always-On SSL means that all websites should be protected with SSL for the most security and privacy. In doing so, the server administrators need to consider the SSL best practices and the leading SSL technology. SSL best practices encourage administrators to not use self-signed certificates, configure their DNS properly and avoid issues such as cross-site scripting. The leading technology approach recommends EV certificates, HSTS, OCSP Stapling and Perfect Forward Secrecy.

The good and bad news about website protection is that any CA can issue a certificate for any domain. This is good as it allow website owners to choose their CA or many CAs. The bad news is, it is hard to know who the authorized CA is. There have been many approaches to address this issue. The industry is currently moving ahead with Certification Authority Authorization (CAA) and Certificate Transparency.

With CAA, the domain owner can state who their authorized CA is by populating a CAA record in DNS. The record could authorize none, one or many CAs. When a CA is about to issue a certificate, they just need to verify if they are authorized through a DNS check. The result could limit the risks where an attacker goes to an unauthorized CA to get a certificate.

Certificate Transparency allows the certificates to be monitored after they are issued. With Certificate Transparency, the CAs must record certificates in public logs. When the certificate is issued, it will contain timestamps for each public log where it has been recorded. The browsers can check the certificate and could provide messages or warnings. Services can also monitor the logs and advise domain owners when a certificate was issued with their domain.

From Always-On SSL to CAA and Certificate Transparency, the industry is constantly evolving to meet the increasing security needs of companies worldwide. For years, PKI has proven to be a remarkably flexible and robust technology. In order to combat tomorrow’s ever more sophisticated cyber criminals, we will undoubtedly see even more powerful solutions, including key lengths of 3072 and 4096-bit. More likely, we may see certificates moving to elliptic curve cryptography (ECC) keys and at some point we’ll be migrating to SHA-3.