Understanding the Public Key Infrastructure behind SSL secured websites

Synopsis: Public Key Infrastructure (PKI) has recently been the focus of several important discussions within the information security community due to high profile breaches, innovations in web application frameworks, and future developments within the information security industry. This article will outline the role of commercial Certificate Authorities (CAs) in providing PKI services for SSL secured websites, the PKI trust model that uses CAs, issues facing CAs, and future developments which are being developed to address the challenges facing public PKI.

Introduction:

Public Key Infrastructure (PKI) technology, which makes use of public key cryptography, is designed to solve the fundamental problem of permitting two parties (people, devices, websites, applications etc.) that have no existing relationship to trust each other for exchanging sensitive information. PKI attempts to solve this problem by defining a way for these parties to use a trusted third party to vouch for each other's identities. This concept is basically the same approach used by people in many common business transactions. For example, when a hiring manager is looking for a new hire, they frequently will ask current employees for references. In this case, the hiring manager trusts the employee as a trusted third party. If the employee can vouch for a friend who is eligible for the position, the hiring manager can make assumptions based on what the current employee has told him. Similarly, the friend can make assumptions about the company and the position since he/she can trust his friend to vouch for the company.

For readers who are interested in the technical details on how PKI technology works and these relationships are established, see reference 1 at the end of the article).

On the public Internet, PKI is most commonly used by website operators to assure visitors to their website that the website is trustworthy (safe to do business with), authentic (that the website is in fact owned/operated by the person/company who claims to own the site) and to provide key material to the SSL layer which permits traffic to/from the website and the end user to be exchanged in private (through encryption) and authenticated (through data authentication).

This article will focus exclusively on the use of PKI for SSL certificates used on the public Internet.

Since end users who are visiting a website for the first time have little to no information that they can use to validate a website, they rely on the services of a Certificate Authority (CA). A CA is an organization which acts as a trusted third party for SSL certificates that are issued to website operators. A CA attains the trusted third party status by passing a set of rigorous audit standards which are placed on them by Internet browser vendors such as Mozilla, Apple, Microsoft, Opera etc. A browser vendor embeds a copy of the CA's root certificate directly into the browser software. Thus, browser vendor is acting as an agent for the end user in deciding whether or not to trust a particular CA. Once the browser has made the decision to trust a CA, that CA is thus inherently trusted by end users of that particular browser. As one final check, browsers can use information in both the website's certificate and the CA's certificate to verify that the certificate has not been revoked by the CA.

At this point, when end users visit a website that has a certificate which is issued by a trusted CA embedded in their browser, the browser will provide some visual indication to the user that the website is trustworthy. At this point, the end user is presumably in a position to conduct business with the website.

Establishing Trust in the PKI Model:

As described above, there are 3 basic points at which trust decisions are made in the public PKI structure: browser vendors trust commercial CAs for inclusion in their software, CAs vouch for the identity of commercial SSL websites, and end users select and use browser software that they deem trustworthy.

Trusting Commercial CAs:
Browser vendors and the commercial CA market have generally agreed to a set of audit standards which outline a set of security practices that commercial CAs must implement and follow during the course of issuing certificates to website operators. Currently, the prevalent standard is the WebTrust Program for Certificate Authorities (reference 2). In short, the practices focus on ensuring that the CA properly protects key material associated with root certificates, sufficiently implements safeguards to prevent fraudulent issuance of certificates, and performs due diligence in a) ensuring that a website owner is authorized to request a certificate for his/her website and b) ensuring that the website owner is in fact who he/she claims to be. Development of audit standards and technical, legal and other related matters for commercial CAs occurs within an organization called the CA Browser Forum (CABForum). Both commercial CAs and browser vendors actively participate in the CABForum to ensure that standards are developed in a fair, balanced fashion and that broad consensus is reached among participants. Individual browser vendors have independent processes used to manage the inclusion of CA root certificates within their software which, as noted above, is almost always contingent upon successful completion of a WebTrust audit.

Trusting Website Operators:
The task of validating the ownership of a particular website and validating the identity of the organization operating that website falls on the CA. For validating the ownership of a website, CAs commonly validate that a person that is submitting a request for a SSL certificate for a given website is authorized to do so by consulting information contained with DNS records for a website. Since the public DNS requires that globally visible websites are properly registered with ICANN (which requires valid contact information such as name, phone number, business addresses and other information be kept in the registry), CAs can use the information contained within the ICANN registry for a website to validate that the certificate requestor is permitted to request the certificate, usually by contacting the person/organization listed within the ICANN registry entry for the website. SSL certificates which are only validated using information in the DNS records are known as domain validated certificates.

CAs can also perform additional verification steps such as actually verifying that the organization submitting a certificate request is permitted to do business, has a valid business license, physical address etc. Certificates that are granted to such organizations after passing the additional verification steps are called extended validation certificates.

Trusting Web Browsers:
The final and perhaps most important trust decision in the public PKI model is the end user's decision of which web browser to choose for visiting SSL secured websites. Since web browsers contain the list of public CAs which the browser deems trustworthy, the end user by selecting to use a particular browser implicitly trusts all public CAs which that browser trusts. Due to efforts by the CABForum to involve major browser and operating system vendors in standardization efforts with the commercial CAs, the set of trusted CAs is mostly common among all browser vendors. Unfortunately, the mechanism to display which particular CA trusts a given SSL secured website varies greatly among different browsers which makes it difficult for end users to make intelligent trust decisions when visiting websites and choosing which browser to use.

Challenges facing the Public PKI Model:

While the existing PKI model of trust has generally satisfied the underlying goal of enabling end users to use SSL secured websites safely, the model is suffering from challenges which threaten to undermine the security of the entire model.

1. Attempts to obtain fraudulent certificates are on the rise
In the public PKI model, commercial CAs are given the difficult task of verifying the identity and right of a particular entity to operate a given website. Due to the global nature of the public Internet, this identity verification and authorization process must work relatively consistently across different countries, legal regulations and customs. Furthermore, the sheer number of requests for SSL certificates that CAs are expected to handle on a daily basis necessitates an outsourcing of some portion of the CAs operation. Traditionally, these issues have been addressed by implementing a separation of duties within the commercial CA operation where the organization that is responsible for issuing certificates (CA - Certificate Authority) is separate from the organization that verifies the contents of a certificate request (RA - Registration Authority). Furthermore, some commercial CAs offer the ability for other organizations such as domain registrars to resell commercial certificate issuance services.

Recently, certificate resellers and RAs have been the victims of targeted attacks by malicious crackers attempting to get certificates issued for domains which they are not the owners of. For example, earlier this year the commercial CA Comodo was blamed for issuing false certificates for several high value domains (yahoo.com, google.com, live.microsoft.com amongst others). In fact, the CA itself was not breached but rather a third party RA for Comodo was breached (reference 3). While Comodo reacted quickly in revoking the falsified certificates within minutes of discovering their issuance, the revocation mechanisms used today in the PKI model have issues which unfortunately result in revocation generally not being checked as a critical factor when visiting a SSL secured website.

2. Lack of effective revocation mechanisms
Current revocation mechanisms in use today in PKI are the use of regularly published blacklists of known, untrusted certificates. These blacklists, called certificate revocation lists (CRLs) are regularly generated by CAs and hosted on a publicly visible URL. The URL for revocation lists is embedded in SSL certificates. This revocation mechanism relies on the browser regularly downloading the CRLs published by CAs and cross checking SSL certificates against the CRL list. However, the CRL mechanism has a significant flaw in that CRLs are published an a recurring basis, meaning that if a fraudulent certificate is issued shortly after a CRL is published, that fraudulent certificate won't be listed in the CRL until it is next updated. The interval at which CRLs are published varies between CAs.

The other revocation mechanism that is generally used is an online request/response mechanism called online certificate status protocol (OCSP). OCSP, unlike CRLs, is a live request/response mechanism that permits a browser to send a certificate status request to an OCSP server (operated by the CA) to ask if a given certificate has been revoked. If the OCSP server indicates the certificate has been revoked, the browser can then choose to terminate the connection (known as a 'hard fail'). OCSP has a significant advantage over CRLs in that it can be updated immediately in the event of a fraudulently issued certificate.

However, placing such a requirement on the browser means that the overall availability of SSL websites is based on the availability of OCSP servers that are operated by the CAs. Many website operators would naturally be hesitant to tie the availability of their website to the availability of infrastructure that they don't control. In addition, privacy concerns have been raised with OCSP as OCSP servers could theoretically build a browsing history for users by correlating the OCSP requests coming from a given source IP address.

3. Perceived lack of transparency in the PKI model:
The final significant challenge that is facing the public PKI model is the overall lack of visibility into the various trust relationships that are established in order for the model to work. Commercial CAs are not necessarily well known to end users which is a natural side effect of attempts to simplify the security model for end users. So, when users visit a website and take the trouble to click on the certificate details for a website, they are presented with a brand name which is largely meaningless to them. While commercial CAs have standardized documentation which describes their practices in issuing certificates to websites, these documents are generally highly technical and contain legalese which is difficult for end users to understand.

The flexibility of the PKI model and the sheer number of commercial CAs which are trusted by commercial browsers means that the CA which vouches for a given website can be changed rather easily. So once a user has decided to trust a particular CA for a given website, they could find themselves having to repeat the process of trusting another CA without any warning.

The user interface presented by web browsers for SSL secured websites is largely inconsistent as browsers are themselves unsure what exactly to indicate to end users. Historically, the use of a 'padlock' icon on a website was used to indicate that the website was safe (user information between the browser could not be seen by malicious attackers), but over time the meaning of such an icon has been lost. End users really care about their information being safe not only between their browser and the website, but want some assurances that their information will be safe on the website. Since the browser cannot effectively vouch for the trustworthiness of a particular website, this responsibility is essentially being pushed to end users and the padlock icon is gradually being phased out.

Proposed Solutions:

Given the challenges listed above, there has been a surge of activity amongst browser manufacturers, CAs, and IETF standards organizations to propose a variety of solutions which are designed to help address some of these issues. Generally the solutions complement each other, but as with many other groups of organizations whose interests don't always align there are some key differences.

Solution 1:
Provide a mechanism for website operators to secure sites without relying on public CA issued certificates.

One interesting solution that has been discussed by the former IETF KeyAssure and now DANE (reference 4) working groups is to leverage the recently launched public DNSSEC service to provide information that can be used by a web browser to validate whether or not a SSL certificate that is presented to the browser is the same certificate that the website operator provisioned on their website. DANE (DNS-Based Authentication of Named Entities) proposes extensions to DNS that permit a website operator to essentially store a copy of the SSL certificate directly in the DNS record for their website. The idea is that if DNS lookups can be secured by DNSSEC (which itself is already protected by a type of public PKI), then information that is obtained from the domain registrar is trustworthy. This solution is based upon the premise that a SSL certificate is not designed to imply any sort of 'trustworthiness' of a particular website but rather that it is only designed to provide the cryptographic means for connections to a website to be confidential and safe from man-in-the-middle attacks. Users visiting a website secured with this type of certificate would then be responsible for determining whether or not the website is trustworthy based on an existing relationship with the website operator or using some other means to assess the trustworthiness of the website. Thus, a SSL certificate that is verified using DANE is essentially just as trustworthy as a domain validated certificate that is issued by public CAs today.

This solution certainly appeals to website operators as it does not require them to purchase SSL certificates from a CA. One particular website operator that currently does not use certificates from a mainstream public CA has a particularly well written explanation on their site which shares some insight this approach has for operators (reference 5).

While this approach is interesting, it does remove the vetting services that a public CA could potentially provide for website operators, particularly the type of vetting that is performed for extended validation certificates.

Solution 2:
Provide a mechanism for website operators to specify which public CA has issued their certificate.

Another interesting solution that also came out of the DANE working group discussions was an extension to DNS which permits website operators to specify which particular CA issued their certificate. This solution is interesting in that it permits website operators to basically maintain a 'whitelist' of CAs that they authorize to issue SSL certificates for their websites. This whitelist is known as a Certificate Authority Authorization (CAA) extension (reference 6). As with the solution described earlier, by using DNSSEC to secure the DNS records, the information in the DNS record can be trusted by the end user. Such a whitelist helps browsers and website operators to ensure that a SSL certificate has not been surreptitiously replaced by another certificate signed by a different CA. This hybrid solution still permits the website operator to obtain extended validation certificates from a public CA. Thus, end users can presumably trust the website is authentic based on the EV criteria.

Solution 3:
Build a dynamic mapping of SSL certificates to websites

This proposed solution strives to build a 'history' of which particular certificates are used to secure frequently visited websites directly within either the browser or in a public, externally maintained database. The idea behind this approach is that since website certificates are only rarely changed during normal operation (most public SSL certificates have lifetimes of 3 to 5 years), a change in a website certificate (which would be triggered by any change in the certificate contents or by a change in the CA which issued the certificate) would generally be unexpected and could be used to trigger a warning to the user. This solution, while not as prescriptive as the other solutions, does not require any changes to DNS records or mandate the use of DNSSEC and is in fact already implemented in Mozilla Firefox extensions such as Certificate Patrol (reference 7). Additionally, a publicly available mapping of websites to SSL certificates is already implemented via the Perspectives project (reference 8). The Perspectives project permits a user to choose an organization or person they trust to maintain a mapping of websites to SSL certificates instead of relying solely on the list of known CAs that are installed in their web browser.

Other solutions:

Many other proposals are currently being actively discussed in the various work groups to improve the overall security model for public PKI and SSL certificates. For example, to address the difficulty in effectively revoking certificates, extensions are being proposed to TLS which would permit websites to contact an OCSP server directly and attach the OCSP response to the TLS certificate messages that are sent to web browsers. A browser which understands OCSP stapled TLS messages could then use the OCSP response to verify that the certificate itself has not been revoked. This approach, called OCSP stapling, addresses some of the privacy and availability issues that arise when browsers contact OCSP servers directly.

Conclusions:

The public PKI infrastructure which is provided by commercial CAs, has generally served users of the public Internet well over the years and has enabled e-commerce to thrive. However, the model is under increasing pressure to adapt to market realities, increasingly sophisticated users and higher expectations of security on the public Internet. Proposed solutions are actively being discussed in various working groups with new solutions building off of fairly recently available improvements in the public Internet infrastructure such as DNSSEC. As these solutions are worked out and different approaches to securing sensitive information exchanged with public websites are created, new challenges will certainly arise which will continue to drive innovation in the public PKI model and Internet security in general.

References:

1) http://blog.securism.com/2009/01/summarizing-pki-certificate-validation/

2) http://www.cica.ca/service-and-products/business-opportunities-for-cas/trust-services/item10797.pdf

3) http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/

4) https://datatracker.ietf.org/wg/dane/charter/

5) http://aa.net.uk/cacert.html

6) http://tools.ietf.org/html/draft-hallambaker-donotissue-04

7) https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/

8 ) http://perspectives-project.org/

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan