Running head: SSL CERTIFICATE AUTHORITY ISSUES 1. Investigating Implementations Designed. to Resolve SSL Certificate Authority Issues.

Transcription

1 Running head: SSL CERTIFICATE AUTHORITY ISSUES 1 Investigating Implementations Designed to Resolve SSL Certificate Authority Issues Michael Ham Stefani Kokel Josh Stroschein Dakota State University

2 SSL CERTIFICATE AUTHORITY ISSUES 2 Abstract Secure Socket Layer (SSL) and Transport Layer Security (TLS) certificates comprise an exceptionally large foundation for web and network applications as they relate to end-to-end security. With such a large emphasis placed on the use of certificates across applications, several questions arise concerning several aspects of the underlying framework, including trust. Determining when not to trust a certificate poses a significant problem, not only for the end-user but also for domain owners. This paper reviews several projects that focus on addressing this issue: the Electronic Frontier Foundation s Sovereign Key proposal, Public Key Pinning, and HTTP Strict Transport Security (HSTS). For each technique, the technical validity, ease of use, and market acceptance of the proposal is considered. While these proposals address some of the structural inadequacies in the use of TLS, they do not provide a definite solution. This is due to a variety of factors, including lack of infrastructure, inconsistent browser/client implementation, and lack of transparency in certificate signing. Keywords: Sovereign Keys, Public Key Pinning, HTTP Secure Transport Security, SSL, TLS

3 SSL CERTIFICATE AUTHORITY ISSUES 3 Investigating Implementations Designed to Resolve SSL Certificate Authority Issues Secure Sockets Layer (SSL)/Transport Layer Security (TLS) certificates comprise an exceptionally large foundation for web and network applications as they relate to end-to-end security. With such a large emphasis placed on the use of certificates across applications, several questions arise concerning several aspects of the underlying framework, including trust. Transport Layer Security (TLS) secures online transmissions between two parties over the Transmission Control Protocol (TCP). TLS certificates are predominantly used with web browsers and web servers. While web sites/applications are the predominate platform for TLS implementation, the overall concepts are broadly applicable when communicating over TCP. When developing applications that communicate with other systems over a TCP/IP based network, we typically care about the following layers: Network Layer - Layer 3 (IPv4, IPv6, etc), Transport Layer - Layer 4 (TCP) and the Application layer - Layer 7 (HTTP). While the use of the OSI model is open for debate, it does provide a common frame of reference to assist us in establishing the role of TLS. TLS provides encryption at the Application layer: data is encrypted before it is handed off to lower layers. This provides security as the data is in transit. In setting up a TLS session, both parties are able to encrypt data to send to each other that only they have the capability to decrypt and read. This mechanism helps prevent a third-party from intercepting this data. If applications send and receive data without TLS, all of the data would be in clear-text and, if someone was in a position to intercept this communication, all of the data would be easily accessible. TLS relies on public key cryptography, in which a server provides a public key to the client that allows them to send encrypted communication back to the server. In order for a server

4 SSL CERTIFICATE AUTHORITY ISSUES 4 to offer a public key, they have to go to a Certificate Authority (CA) to prove their identity and right to get a certificate for a specific domain. Once the verification is complete, the CA provides the company with a new public key, one signed by the CA s private key. When a client requests a secure session with the server, the server sends the public key they received signed from the CA. Most modern browsers are configured by default to contain a list of CAs and their corresponding public keys. Now the client can use the public key it already posses to verify that the key it just received is in fact valid and signed from a CA, which in turn implies that they should trust the server that sent it. What happens when a public key is no longer valid? Currently, there is no widely accepted and implemented standard for the client to determine the validity of the public key sent. When a certificate is identified as no longer valid, especially when it is fraudulent or has been compromised, clients need to know to immediately stop trusting that certificate. There are currently two primary methods for a browser to check if a certificate is invalid or revoked: by using the Online Certificate Status Protocol (OCSP) or by using a Certificate Revocation List (CRL). Without getting into the details of these methods, the problem they pose is that browser support to check on the status of a certificate is inconsistent, from not using at all to selective use. This can lead to a revoked certificate being accepted by a browser for weeks after it has been revoked. Even when a browser recognizes that it has been given a revoked or otherwise invalid certificate, user notification is often weak, and the user commonly accepts the warning and continues to use the certificate in spite of the notification. While certificate expiration is one concern, effective solutions for detecting and preventing the use of fraudulent certificates is another. If a CA is compromised, then attackers can generate fraudulent valid certificates and masquerade as legitimate organizations, acting

5 SSL CERTIFICATE AUTHORITY ISSUES 5 on their behalf for nefarious purposes. When a fraudulent certificate is issued, it may allow for man-in-the-middle attacks to eavesdrop on SSL/TLS connections. There have been several highprofile cases, which have brought attention to the security of SSL certificates. In 2011, the Certificate Authority Comodo was tricked by attackers into issuing nine fraudulent certificates (Masters, 2011). Another example was the issuance of fraudulent certificates after a Dutch Certificate Authority, DigiNotar, was hacked (Vasco, 2011). In this case, an attacker was able to issue a fake wildcard certificate for google.com, allowing them to target Google s services. These fake certificates were eventually discovered by use of the Chrome browser, which leveraged public key pinning to detect and reject the fake certificate and ultimately lead to their discovery (Adkins, 2011). In this case, public key pinning proved an effective solution for detecting a fraudulent certificate to prevent the transmission of sensitive information over a compromised connection. Current work in this space appears to be sparse. The research presented in the paper focuses on 3 current solutions, their technical validity, ease of use, and market acceptance. One proposed project is the Electronic Frontier Foundation s Sovereign Keys project (Eckersley, 2011). This project aims to address the structural inefficiencies with Certificate Authorities and certificate revocation by removing the dependency on a third-party to check for revoked certificates and the associated, easily bypassed, browser warning. Another technique called public key pinning allows browsers to pin a specific value in the certificate chain to a given site (Evans et al., 2014). This reduces the number of authorities that can authenticate the domain while it is pinned. Most mainstream browsers contain built-in pin values for major sites. A draft proposal for HTTP Public Key Pinning (HPKP) exists to

6 SSL CERTIFICATE AUTHORITY ISSUES 6 extend the HTTP protocol to allow any site to provide their pin values to a client dynamically. A similar effort Trust Assertions for Certificate Keys (TACK) has been proposed to extend the TLS protocol to allow TLS servers to pin a chosen public key to a domain, but the current momentum appears to be supporting the HPKP protocol. (Marlinspike & Perrin, 2013). Certain websites are allowing the acceptance of the HTTP Strict Transport Security (HSTS) protocol alongside the adoption of major browsers. This specification defines a mechanism enabling websites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connection (Hodges, 2012). Such protocols demonstrate integrated browser support along with a seamless user experience. Protocols and projects such as HSTS provide a step further in the direction of forcing SSL communications while providing a method to assess the validity of the certificate being used.

7 SSL CERTIFICATE AUTHORITY ISSUES 7 Sovereign Keys Technical Validity Secure communication over the Internet depends almost exclusively on Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS), as discussed in the introduction of this paper. In order to understand the Electronic Frontier Foundation s (EFF) Sovereign Keys proposal, we need to take a closer look at how public key cryptography works as well as the public key infrastructure (PKI) that is in place to manage the public/private keys that are relied on for TLS. After discussing public key cryptography and PKI, we will discuss current implementations of SSL/TLS and the numerous components therein: Domain Name System (DNS), Certificate Authorities (CA) and client/server implementation. Finally, we will discuss the primary weaknesses in the current implementation, the Sovereign Keys proposal and how it aims to remedy those weaknesses. To begin, we need to understand public key cryptography, which is also known as asymmetric cryptography. In asymmetric cryptography there must exist two keys in which to provide for the desired cryptographic functions - namely the encryption/decryption of plaintext/ciphertext or the generation/validation of a digital signature. This differs from symmetric cryptography, which only utilizes a single key for desired cryptographic functions. The two keys utilized in asymmetric cryptography are commonly referred to as the public and private key. As the name implies, the public key is ultimately made public and utilized in encrypting plaintext and verifying digital signatures. Public keys are therefore made available to be public and not protected as a private key is. Private keys, on the other hand, are utilized to decrypt ciphertext (ciphertext is the result of running an encryption algorithm on plaintext) and to generate a digital signature. (Wikipedia, 2014)

8 SSL CERTIFICATE AUTHORITY ISSUES 8 Therefore, anyone with access to a public key is able to encrypt plaintext to send to the owner of the private key. The holder of the private key is then the only party able to decrypt the ciphertext. In dealing with communication that needs to be secured over the Internet, this provides an ideal solution. That is, after a client is able to obtain and verify a public key for an intended recipient, the client can send secure communications without fear of compromise (interception, tampering, et cetera) (Tews, 2012) It is worth pointing out that public keys can in fact be made public. Since the generation of the public and private keys is founded in mathematical principles, it is currently not feasible to attempt to generate a corresponding private key from a public key, allowing public keys to be freely shared. (Wikipedia, 2014) Utilizing asymmetric cryptography is a straightforward process and typically involves generating a public/private key, providing the public key to a third party and then sending/receiving ciphertext/plaintext. The major obstacle with this model is the distribution of the public key. While it is easy for an individual to generate their key-pair and post their public key, such as in an signature or social media platform, it is very difficult for this to scale to websites or high-traffic platforms that which to communicate securely with a large number of individuals in which they have no direct, personal relationship. It is not enough to simply make a public key available; the consumer of that public key has to also be able to verify that public key belongs to the person/organization that claims to own it. In order to solve this problem, the public key infrastructure was created and implemented. Public key infrastructure, or PKI, was designed to bind public keys with respective user identities by means of a certificate authority (CA) (Wikipedia, 2014). In it s simplest sense, PKI allows a third party to verify that a public key belongs to an individual/organization that is

9 SSL CERTIFICATE AUTHORITY ISSUES 9 claiming its ownership. Once the public key has been verified, the third-part can feel confident in their secure communications with the owner of the public key. PKI does this through the issuance of a digital certificate (also called an X.509 certificate), which ultimately proves ownership of a public key. The digital certificate will contain information such as the owner, their public key and the digital signature of the authority that is certifying that the digital certificate is valid (that is, the public key belongs to the purported individual/organization). In the case of web-based communications, the digital signature of the authority that has validated the digital certificate is typically a Certificate Authority (CA), which is considered the signer of the digital certificate. The digital certificate that is ultimately assigned to a host is the result of what is typically referred to as the X.509 hierarchy. The root of this hierarchical system begins with a few root CAs. These root CAs utilize a minimal amount of public keys to provide issuance of other certificates, which serves to bind the public key to the hosts identity. The root CAs are also able to delegate signing privileges to other organizations, which greatly expands the ability of the PKI architecture. This process results in a trust chain, which consists of the root s certificate, potential intermediate certificates and finally the host s certificate. Clients, i.e. browsers, are configured with a list of root certificates. When a browser encounters a host s certificate, they can leverage the root certificates they are already configured to trust to determine the identity of the host. With most modern browsers, they are configured to trust 600 or more root or intermediate certificates. (Gielesberger, 2013) With the invention of the CA, the ability to verify public keys can scale to the level needed to support TLS-based communication over the Internet. As long as the reputation of the CA is good, then they can trust any digital certificate signed by that CA, which implicitly means

10 SSL CERTIFICATE AUTHORITY ISSUES 10 they are trusting the public key with the intended third party (owner of the public key) without every verifying true ownership directly. While this appears to be an acceptable solution, problems arise when one cannot trust the CA. Cases in which trust is lost in a CA are when they are compromised and an attacker can issue fraudulent digital certificates that are genuinely signed by the CA. Anyone that trusts that CA will also trust the fraudulent certificate based on the stolen digital certificate. The DigiNotar story mentioned early in this document is an excellent example of the breakdown of the PKI system. Essentially, a CA is able to issue a valid, trusted certificate for a host without the consent of the host. (Gielesberger, 2013) This leads to one of the primary issues with the current architecture, since a browser will inherently trust a large number root and intermediate CAs, if a CA is compromised the attacker is able to issue fraudulent certificates without the host ever knowing. Once this has occurred, certificate revocation has to take place and in it s current form is highly ineffective and disorganized, as well as largely ignored by browsers and/or users. With the infrastructure in place, TLS was able to provide end-to-end encryption over the Internet. In a typical scenario, when a user wishes to connect to a web server a session is established. During the setup of the session, the web server will respond with it s public key. The browser can then verify the public key through the use of the digital certificate issued by a CA (and the inherent trust chain). If the public-keys match, then the browser trusts that public key and can proceed in using secure communications with the server. If the key is not verified, the browser typically displays a certificate error to the user. Currently, there is no widely accepted and implemented standard for the client to determine the validity of the public key sent; it simply checks if the certificate was legitimately signed. If a CA is compromised, then attackers can generate fraudulent valid certificates and masquerade as legitimate organizations,

11 SSL CERTIFICATE AUTHORITY ISSUES 11 acting on their behalf for nefarious purposes. When a certificate is identified as no longer valid, especially when it is fraudulent or has been compromised, clients need to know to immediately stop trusting that certificate. Due to the limitations of the structure of the CA, there is no effective way of communicating this to the clients. (Tews, 2012) (McKinley, 2012) The most common solution is for the browser to display a certificate error warning, indicating to the user that they cannot trust communication with the server and should not proceed. However, the user is typically allowed the opportunity to accept the certificate warning and proceed in establishing a secure connection with the site, using a potentially invalid public key. In this scenario, the client is potentially communicating sensitive information with an untrusted server. It is with this problem that EFF proposed Sovereign Keys aims to address. As previously stated, Sovereign Keys is a proposal and no current implementation exists. As such, we can discuss the technical validity of the proposal and determine how it helps in addressing the verification of a public-key. The overall goal of Sovereign Keys is to assist the consumer of a public-key in determining the validity of the public key they received from a server (or third party). This becomes especially important when the end-user cannot efficiently determine when they can no longer trust the CA or a specific certificate issued by a CA. In order to provide an additional element of security, one outside of the direct trust relationship with the CA, Sovereign Keys proposes an independent infrastructure that utilizes additional hardware, cooperation with website owners/operators and browser vendors. Sovereign Keys is a transparency-based system. (Gielesberger, 2013) The proposal includes, at its core, timeline servers, mirrors, and clients. A timeline server, which will contain an append-only data structure, is used to record the sovereign key. This sovereign key is generated by a site owner (or owner of a public key) after receiving a valid digital certificate from a CA. In order to generate a

12 SSL CERTIFICATE AUTHORITY ISSUES 12 sovereign key, the website must be able to prove domain ownership via the digital certificate signed by a CA. Once the sovereign key is generated, it is submitted to a timeline server. The timeline server appends this information, the key and the certificate, to its append-only data structure. The timeline servers are managed, when a key and certificate are submitted for addition to a timeline server, they can be checked for validity utilizing the digital certificate. If the submitted key is verified, the operator of the timeline server will add them to the database along with the domain name the sovereign key is valid for. (Tews, 2012)(Eckersley, 2011) With a Sovereign Key in place, when a client receives a host certificate, they are now able to check for a cross-signature in the X509 certificate, as shown in Figure 1. Figure 1. X.509 Certificate Signing (Gielesberger, 2013) The append-only data structure is a critical component in the proposed infrastructure. When a sovereign key is initially claimed for a domain name, it is recorded via the timeline server s records. These records can no longer be altered, which prevents a subsequent claimant from attempting to alter the original claim even if they had successfully been able to compromise a CA. since a claim is partially based on a valid digital certificate. The append-only data structure is guaranteed by utilizing an incrementing serial number and a monotonically increasing timestamp, which become a part of each entry into the timeline. In the proposal, if

13 SSL CERTIFICATE AUTHORITY ISSUES 13 any entry violates these two properties then a client will immediately stop trusting that timeline server. When a client requests a sovereign key, the client will trust the oldest claim to that key. (Eckersley, 2014) This aspect of the design also provides for the transparency of the system. Since the Sovereign Keys are made publicly available on the timeline server, a client is thus able to verify the cross-signature, which allows them to determine the validity of the certificate they were presented with. The timeline server is the core of the system because they hold the mapping between the host and its corresponding Sovereign Key. (Gielesberger, 2013) The process in which a client registers a Sovereign Key is worth paying particular attention. The request generates a write event to the timeline server, in which other timeline servers and mirrors are updated to the change. The process of associating a Sovereign Key to a host is called binding. The host will send a bind message to a timeline server with proof of domain ownership, which can include a valid CA-signed certificate or a key that utilizes DNSSEC via DANE. (Gielesberger, 2013) The timeline server will record the bind message and will be utilized by clients to determine the authenticity of the Sovereign Key. This is a critical step, as it produces the claim of trust from the host certificate to the root certificate. This trust is assumed, and discussed, later when a client verifies a domain by its Sovereign Key. In the proposal, there is not a single timeline server. Multiple timeline servers are proposed that are geographically disperse, diversely operated and exhibit various security mechanisms. According to the draft proposal, about timeline servers would be sufficient to implement the core infrastructure. However, clients would not be sending their queries directly to a timeline server but rather a mirror. In the proposal, there will be M mirrors, where there are more mirrors than timeline servers, would be added to the infrastructure to provide for accessibility and scalability, with the mirror containing a read-only copy of the entire append-

14 SSL CERTIFICATE AUTHORITY ISSUES 14 only data structure. This would also allow for verification of sovereign keys, as a client would be able to utilize the mirrors to verify the information they received. (Eckersley, 2011) Mirrors will be kept in-synchronization with the timeline servers to ensure accuracy and reliability. Mirrors will have a complete picture of the timeline data-structure, which allows them to detect rogue mirrors and remove them from the list of trusted mirrors. (Gielesberger, 2013) The final component in the proposal is the client. When a client receives an X.509 certificate it will not need to perform the usual certificate chain check, as this process will be guaranteed by the timeline server and the Sovereign Key. Instead, the client will contact a mirror to obtain the host s sovereign key and check that the certificate has been signed by that key. In order to cross-sign a certificate with a Sovereign Key, the proposal relies on an extension to the X509 data format. This extension allows for a certificate to be signed by more than one key, which is not supported without the extension. Clients that do not support this extension will ignore it and there will be no impact on their ability to handle the certificate as it normally would. (Gielesberger, 2013) When a client queries a mirror for a Sovereign Key, it receives a chronological listing of messages for that domain. The client then uses the key that signed the first bind message in order to verify the remaining messages as well as to connect to any defined services with the host. A host can submit an Unbind message, in which case the Sovereign Key is disassociated with the domain. If a client encounters an Unbind message, it evaluates the messages for a Rebind message. If a Rebind message is located than that key is used. If no Rebind is found then there is no valid Sovereign Key for that domain. (Gielesberger, 2013) In a typical scenario using sovereign keys, a client would attempt to connect to a website via it s domain name. The client wishes to establish secure communications and the server

15 SSL CERTIFICATE AUTHORITY ISSUES 15 supports HTTPS using SSL/TLS. The domain name system (DNS) is utilized to resolve a domain name into an Internet protocol (IP) address. The client then contacts the server via the IP address and attempts to establish a secure connection. The client s browser needs to be aware of sovereign keys and the server has to have a published sovereign key. Assuming the server published a sovereign key and the client is aware to check, the client will make a request to a mirror while establishing the secure connection to the website. The client is then able to verify that the public key provided by the server has been cross-signed by a sovereign key. If this cannot be verified, the client cannot send data to the server and may display an appropriate warning/error to the user. If verification is successful, the client is able to establish secure communications with the server (Eckersley, 2014). Figure 2. Architecture of Sovereign Keys (Gielesberger, 2013)

16 SSL CERTIFICATE AUTHORITY ISSUES 16 Ease of Use When looking at the implementation of Sovereign Keys, there are primarily two actors that we need to be concerned with: browser vendors and the site owners/operators. It is these two parties that will be largely responsible for the successful adoption of the proposal - assuming adequate infrastructure is built and in place. For the browser vendors, the most significant hurdle will be in creating products that are Sovereign Keys aware. This burden will largely fall on the browser vendors, as it is assumed that the typical user will not want to configure additional security. That is, the end user of a browser assumes that all the security they need for SSL/TLS communication is built directly into the browser and works without additional configuration. It is therefore up to the browser vendors to implement the Sovereign Keys protocol in the browser and provide an appropriate response when verification fails (as the proposal defines, the client cannot send data but may notify the user or leverage an alternate route). The other burden fails on the site operators, as it is up to them to submit a sovereign key to a timeline server for inclusion in the infrastructure. Additionally, the site operator must submit any self-signed changes to the infrastructure. These changes may include certificate revocations and renewals. (Eckersley, 2014) This leaves us with the end-user and how they fit into the infrastructure. In a typical browsing scenario, when verification fails the protocol states that the client cannot send data to the server and may inform the user of the problem. EFF s research has shown that most users will ignore any client-side certificate validation errors in order to proceed with their task at hand. In order to provide the user a seamless and secure connection to the legitimate server, the proposal includes automated circumvention of attacks. When a server operator/owner submits their sovereign key, they can additionally provide preferred, alternate routing paths. This

17 SSL CERTIFICATE AUTHORITY ISSUES 17 alternate routing may be implemented in lieu of client-side warning messages and be triggered automatically, making it transparent to the end user. The alternative is to decline the connection and inform the user that their request cannot be completed. (Eckersley, 2014) There are still significant problems that Sovereign Keys will face when dealing with the end-user. The primary problem is that the user will have to be using a browser that supports Sovereign Keys as well as connecting to a site that utilizes it. This additionally security needs to be transparent to the end-user, which means that all major browsers will need to support it as well as a significant number of site operators in order for it to achieve any level of effectiveness, preventing the user from performing additional configuration in their browser of choice or having to perform research in order to determine which sites support Sovereign Keys. Market Acceptance At the time of this writing, no support by browser vendors or large-scale site operators has been noted. The proposal is still in draft form. Prototype code is available (Gielesberger, 2013). However, the code appears to be incomplete and, according to commit logs, work stopped in August of 2012.

18 SSL CERTIFICATE AUTHORITY ISSUES 18 Public Key Pinning An underlying flaw in the PKI infrastructure is that browsers trust all Certificate Authority (CA) certificates for all domains equally. Thus, if one CA is compromised, the trustworthiness of the entire infrastructure is at risk. The risk occurs when a certificate is issued that is not approved by the domain owner. In reality, most domain owners only obtain their certificates from only a few CAs. Public key pinning takes advantage of the fact that website owners usually stick with the same set of CAs when obtaining new certificates. The idea of public key pinning is to associate a domain with the expected public key for that domain. Public key pinning allows the website operator to define a pinset, which is a value or set of values that must be present in the certificate chain that is presented for their website. If the pinned value is found, the connection is considered trusted. If the pinned value is not present in the certificate chain, the connection is considered untrustworthy. Public key pinning reduces the number of authorities that can authenticate the domain, thereby reducing the risk of a random compromised CA affecting the security of a given domain. Terminology for this technique varies and can be confusing. Google calls the technique certificate pinning. The Internet Engineering Task Force (IETF) calls it public key pinning. In this paper, we will refer to the technique as public key pinning. To further confuse the issue, there are two basic ideas for public key pinning, which we call static and dynamic. Static public key pinning occurs when the pinset is hard-coded into the browser or into a file that the browser references. All sites in the hard-coded list are protected; any additional sites not on the list are not protected. We will refer to static public key pinning as built-in pinning or built-in pins. Dynamic public key pinning occurs when the website is allowed to present their pinset to the browser during the first connection. The browser then stores that pinset and uses it for future

19 SSL CERTIFICATE AUTHORITY ISSUES 19 connections. We will refer to this as dynamic pinning or dynamic pinsets. When a concept applies to either static or dynamic pinning, we will use the generic term public key pinning. Recall that a certificate binds a specific domain to a specific public key. The basic idea behind built-in pinning is to whitelist specific certificates for specific domains. The whitelisted value must be present in the certificate chain presented by the domain. To implement pinning, a pin value(s) must be created for the site. The recommended approach for creating a pin value is to generate the sha-256 hash of the subjectpublickeyinformation block from one of the certificates in the certificate chain (OWASP). This block remains the same for as long as the domain continues to use that public/private key pair, even when a certificate is renewed or reissued. The certificate a website presents typically contains at least three public keys in the certificate chain: the site s own public key, the root CA public key, and any intermediate CAs that were used to generate the certificate. There are tradeoffs between security and maintenance in choosing the pin value. If the site s specific public key is pinned, the highest security that this method provides is obtained. However, if the website rotate keys or needs to replace their public/private key pair, it requires more effort to change the pin value and ensure the site is still accessible. If the root CA s public key is pinned, the result is maximum flexibility. The website operator doesn t have to change your pin value as long as they keep using that root CA to sign your certificates. But if the root is compromised, there is no additional protection. Intermediate CA s can be pinned as well. The value that is chosen simply depends on the desires of the site. However, it is always suggested that a backup pin value be added to the pinset. This allows the site to be accessed if there is a compromise or revocation of the primary pin value.

20 SSL CERTIFICATE AUTHORITY ISSUES 20 Technical Validity Built-in pinning has been proven to be a valid technique because it was effective in 2011 when Google Chrome prevented the fraudulent DigiNotar certificate from being used against the google.com domain and subdomains. Built-in pinning was implemented in Chrome version 13 in May In that version, many Google sites were pinned by hardcoding a pinset for those domains into Chrome. On September 27, 2011, an online user alibo noticed a certificate warning for the google.com domain while using Chrome (alibo, 2011). He posted the error and the fake certificate to the Gmail Help Forum. A screenshot of the certificate error is shown in Figure 3. It was later confirmed that a fraudulent certificate was issued by the DigiNotar CA for the *.google.com domain and subdomains. Because the certificate was properly signed, it appeared to be a legitimate certificate. Only Chrome was able to detect the fraudulent certificate immediately. Once the fraud was revealed, the certificate was revoked and could be detected as fraudulent using existing methods, such as the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP). The true benefit of public key pinning is that it enables detection of fraudulent certificates prior to the specific fraudulent certificate being revoked. The idea of built-in pinning is promising. However, the current implementation of hardcoded pins built into the browser does not scale across the Internet. Built-in pins help protect well-known websites such as Google and Twitter, but what about lesser known websites that want to pin a public key to their domain? Such sites must rely on dynamic pinning in order to achieve additional certificate protection.

21 SSL CERTIFICATE AUTHORITY ISSUES 21 Figure 3. Certificate Error Displayed in Chrome During DigiNotar Attack (alibo, 2011) Dynamic pinning is more difficult to implement than built-in pinning. A draft proposal exists to enable dynamic pinning by extending the HTTP protocol to allow for dynamic pinsets, instead of using only built-in pinsets (Evans, 2014). This proposal is known as HTTP Public Key Pinning (HPKP), and it is the method of dynamic pinning that is addressed in this paper. HPKP allows website operators to extend the HTTP header of their site s HTTP Response messages to clients. The header contains the pinset for the site. The browser would then remember the pinset and alert on any future connections that do not contain a public key in the advertised pinset. HPKP is still in draft form, but its specifications are becoming more stable. One important consideration with dynamic pinning, and specifically HPKP, is that the first connection is always trusted. Thus, this dynamic pinning is not a valid solution when an attacker is in a position to intercept or issue the first connection to a given site. Specifically, dynamic pinning will not detect man-in-the-middle attacks when they are the first connection.

22 SSL CERTIFICATE AUTHORITY ISSUES 22 Also, the technique is enforced within the browser, so if the user switches browsers, the first connection with the new browser is also not protected. Thus, dynamic pinning is not a perfect defense. However, it does improve the likelihood of identifying fraudulent certificates for websites that are not statically pinned. It also raises the bar for the adversary by requiring the attacker to be the first connection, not a subsequent connection. As a whole, public key pinning provides significant value by reducing the number of CAs and certificates that are accepted for a given domain. This allows a fraudulent certificate to be identified before it is listed on a Certificate Revocation List. Ease of Use The following subsections discuss the ease of use of public key pinning for end-users, developers, and website administrators. End-Users Both built-in pinning and dynamic pinning techniques are very easy for the end-user because they occur behind the scenes. As in the case of DigiNotar in 2011, the user simply received a certificate error message in Chrome informing the user that the presented certificate was invalid. Users do not have to configure any special settings or install any add-ons in order to benefit from the built-in pinning. Some browsers do allow the user to configure the level of public key pinning enforcement. For example, the user is given the following four options for enforcing public key pinning in Mozilla Firefox (Mozilla): 0. Pinning disabled 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)

23 SSL CERTIFICATE AUTHORITY ISSUES Strict. Pinning is always enforced. 3. Enforce test mode. By visiting the about:config page in Firefox, the user can enter the level of enforcement that they desire. As shown in Figure 4, the default level is Allow User MITM. This option allows SSL proxies to work in Firefox without additional configuration. Many corporate networks deploy SSL proxies in order to monitor network traffic. The use of an SSL proxy changes the certificate that is presented to the user, and pinned sites would not be accessible without this option. Figure 4. Mozilla Firefox Default Pinning Enforcement Browser and Application Developers Although built-in pinning is easy for the end-user, it does require coordination between browser developers and website administrators. Browser developers must maintain the list of pinsets and ensure that any changes get pushed out in new versions. The Open Web Application

24 SSL CERTIFICATE AUTHORITY ISSUES 24 Security Project (OWASP) website provides examples of how to implement built-in pinning in Android, ios,.net, and OpenSSL (OWASP). Dynamic pinning only requires that browser developers implement the HPKP protocol standard properly. Once the browser supports the protocol, the developers do not need to do anything additional to allow a site to use the protocol. Website Administrators Website administrators must determine what value(s) to pin. For built-in pinning, they must communicate the pinned value(s) to browser and application vendors so that the values are properly hard-coded. For HPKP, the administrator simply has to implement the HPKP protocol on their site and configure it to provide the pin value(s) and the maximum age for the pin value to be considered valid. In either case, if the administrator does not understand how pinning works, it is possible for them to inflict a denial-of-service to their own websites. This could occur if they decide to use a different CA when they renew their certificates, or if they pin to an incorrect value. It could also occur if they do not store a backup pin value. Market Acceptance The same feature that makes built-in pinning easy for consumers to use makes it easy for this technique to gain market acceptance. Developers simply have to enable support into the browser, and users simply need to upgrade to the latest version. Google first implemented builtin pinning in their Chrome browser in Since then, several other browsers have added built-in pinsets. The pin values that Chrome uses are available in their code repository and other browsers (Chromium, 2014). Firefox chose to use Chrome s pin values and build upon this existing list by adding their own specific domains. The table below highlights several web browsers that have added support for built-in pinning and HPKP.

25 SSL CERTIFICATE AUTHORITY ISSUES 25 Table 1. Support for Built-in Pinning and HPKP in Mainstream Browsers Browser Version Supporting Built-in Pinning Google Chrome Built-in: Version 13+ Date Support Added Built-in: June 14, 2011 (Evans, 2014) HPKP: Supported. HPKP: Unknown date. Mozilla Firefox Desktop Mozilla Firefox Mobile (Android) Internet Explorer Built-in: Version (Mozilla) HPKP: Version 35.0beta Built-in: Version (Mozilla) HPKP: Version 35.0beta Built-in: EMET implemented HPKP: Not currently implemented. Built-in: September 2, 2014 (Stamm, 2014) HPKP: December 4, 2014 Built-in: December 1, 2014 (Firefox, 2014) HPKP: December 4, 2014 (Firefox, 2014) Built-in: EMET implemented May 8, 2013 (Swiat, 2013) HPKP: To be implemented soon (Fisher, 2014) Dynamic pinning is not as stable and widely supported yet as built-in pinning is. Google Chrome supports HPKP, but we could not verify when that support was added. Mozilla Firefox recently released a beta version that supports the HPKP draft protocol. Internet Explorer is said to be considering adding HPKP support soon. A website exists to test whether or not your browser implements HPKP, and it shows test results for several popular browsers (Mosenkovs, 2014).

26 SSL CERTIFICATE AUTHORITY ISSUES 26 One important consideration is whether or not the user is allowed to bypass the pinning. This behavior is entirely dependent on how the developer chooses to enforce the pinning. We could not find a way to disable pinning in Chrome. As mentioned previously, Firefox enforces pinning by default, while allowing any local certs (such as proxies). Firefox can be changed to completely disable or strictly enforce pinning, although the configuration is through the about:config interface of which many users are not aware. Opera allows the user to easily bypass the security by clicking a Continue Anyway button. Internet Explorer is expected to implement HPKP in future versions. Screenshots of error messages displayed by several browsers are shown in the Appendix. Future Work Our research into public key pinning techniques can lead to future work. We tested several mainstream browsers, but additional browsers could be tested as well. Specifically, it would be interesting to learn if mobile device browsers provide the same protection, since they are written from a different code base. We encountered documentation that stated Mozilla allowed local proxies by default. Local proxies break the end-to-end security model, because they present a different key to the client, in order to proxy or inspect the connection. However, accepting a proxy connection negates the benefits that this technique provides. Additional testing could be performed using a proxy connection to test the browsers. Our research investigated the basics of the HPKP protocol. An in-depth protocol analysis could be performed to identify how robust the protocol is. A sniffer, such as Wireshark, could be used in a test environment to verify and compare how different sites and browsers implement HPKP. Other security scenarios could be considered as well. For example, if an attacker can

27 SSL CERTIFICATE AUTHORITY ISSUES 27 intercept and incorrectly pin the first connection, can they create a denial of service attack against a site? Finally, the Chrome source code repository contains the list of sites that Chrome statically pins. Analysis of this file could reveal interesting patterns or best practices. How many of the top sites are pinned? How frequently has this file changed over time? What typical max-age values are used when pinning a site? Are most sites pinned to the root CA certificate, an intermediate CA certificate, or to the website specific certificate? Are any specific CAs on the list more frequently, indicating that these CAs are more trusted than others? An understanding of the current implementation may help provide best practice guidance to other browser and application developers wishing to implement pinning.

28 SSL CERTIFICATE AUTHORITY ISSUES 28 HTTP Strict Transport Security (HSTS) Problem Statement Many web applications offer both SSL/TLS access and pure unencrypted communication between the client and server over HTTP via TCP. TCP does not provide channel integrity protection, confidentiality, nor secure host identification. Thus the Secure Sockets Layer (SSL) protocol and its successor Transport Layer Security (TLS), were developed in order to provide channel-oriented security, and are typically layered between application protocols and TCP (Hodges, Jackson, & Barth, 2012). Attackers are able to perform Man-in-The-Middle (MiTM) attacks between a client and server forcing the client to communicate with the intended destination via unencrypted HTTP. This ultimately can lead to the disclosure of sensitive information sent and received by the client/server. Researchers have deemed such attacks where one forces a normally secure connection such as HTTPS through an unencrypted protocol as stripping attacks. Both HTTPS and HTTPi are prone to stripping attacks that hijack a user s initial insecure HTTP request and remove redirects to secure content. Although it is possible to notice stripping attacks by manually checking browser security indicators, users often ignore these indicators (Singh, Wang, Moshchuk, Jackson, & Lee, 2012). Many users lack the technical ability or motivation to perform manual checks. Automated solutions that provide technical validity better server to mitigate these associated risks. Less prominent attacks than stripping attacks do pose threats potentially solved by HSTS. Such other threats include if a user bookmarks or manually types and is subject to a man-in-the-middle attacker or a web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP (OWASP, 2014). As seen with

29 SSL CERTIFICATE AUTHORITY ISSUES 29 the Man-in-The-Middle attacks, HSTS aims to mitigate risks with bookmarks and content inadvertently delivered over HTTP with an automated, transparent, and valid solution. Overview of the Protocol HTTPS is a protocol designed to provide some level security surrounding specific areas of client-server communication intended for encrypted channels such as integrity protection and secure host identification. (Hodges et al., 2012). Where HSTS comes in is actually verifying or statically assigning clients to communicate with servers over HTTPS and rejecting connections denoting otherwise. This enforcement is accomplished with user agents (UAs); Google Chrome and Firefox, implicitly, by including a static list of URLs to be accessed only over secure HTTPS connections (B, R, & S, 2013). By statically assigning the list of URLs in the users browser user agent that require HTTPS communication, HSTS aims to effectively eliminate the possibility of stripping attacks. HSTS also has an important server-side component that defines the metrics that a client user agent must meet. The web server forces a client to use HTTPS connections to access its web content. The web server attaches a special header called an HSTS header in the response packet, which intimates the user agent the following: request should be made through HTTPS, sub-domains to be accessed following this rule, max age of the rule ((B et al., 2013). By taking into account the server assigning a strict set of values for clients to follow, and clients having a matching set of metrics hard-coded in their browsers HSTS should effectively provide a layered security approach. Technical Validity HSTS offers enhanced security for users connecting to sites that have statically established that communications should occur only over HTTPS. However, this security is

30 SSL CERTIFICATE AUTHORITY ISSUES 30 limited to the prelisted URLs. At present, Chrome and Firefox are the browsers that have implemented HSTS at a primitive level and maintain separate lists of must-be-https URLs. (B et al., 2013). As a result, clients have a degree of likelihood of connecting to websites protected by SSL/TLS that are not defined by HSTS, and thus vulnerable to stripping attacks. This implementation also poses considerations about update frequency, validation of updates, and user requirements for updates to the HSTS lists used by browsers. It is important to note that sites not hard-coded into a browser rely on the max age directive to be set at an appropriate value. The max age directive instructs a client to identify the server as a valid HSTS host for a predetermined number of seconds (Hodges et al., 2012). If the max-age time expires before the client has finished its session, the client may be left vulnerable in similar ways to SSL sites that do not leverage HSTS. Therefore, proper configuration of the directives noted in HSTS headers need to be properly configured in order for clients to be protected in cases where the server is not included in a hard-coded list. The HSTS protocol focuses on effectively protecting end-users from three types of attacks: passive network attacks, active network attacks, and web development bugs. On the other hand, it is explicitly not a remedy for two other classes of threats: phishing and malware (Hodges et al., 2012). The attacks that HSTS defend against prove to be mitigated via technical strategies as opposed to soft strategies such as user education. Network-based attackers may be able to take advantage of HSTS sites that do not include subdomains as being protected with the includesubdomains directive. Without the includesubdomains directive, an active network attacker can simply choose an unprotected subdomain of example.com, such as attacker.example.com, and overwrite cookies in a manner similar to that of a related-domain attacker (Bortz, Barth, & Czeskis, 2011). Depending on the

31 SSL CERTIFICATE AUTHORITY ISSUES 31 structure of an organization s domain, including subdomains may or may not be possible; thus potentially leaving users vulnerable. Furthermore, in cases where sites are not included in a list of hard-coded HSTS hosts located in the user s browser, attackers may interfere with the client before initial HSTS communication occurs. Before HSTS can be enabled, or between re-enabling after the directive expires, an active network attacker has the ability to overwrite cookies as usual. While the directive can be made to expire arbitrarily far in the future, there is no way to eliminate the window before the browser first navigates to the web application (Bortz et al., 2011). This type of attack would require careful timing and planning to successfully execute. Ease of Use and Acceptance Administrator Administrators need to inject an HSTS header into the client/server communication for the protocol to be considered. Depending on the type of web server, the processes of introducing such functionality changes may be directly supported or need the assistance of third-party addons. Web servers based on NGNIX, Lighthttpd, and HTTP directly support integrating response headers for HSTS into web requests; however, Microsoft IIS does not natively support the manipulation of headers without third-party add-ons (OWASP, 2014). For most implementations of HSTS, the process of modifying header values does not appear to be overly complicated. Often times simple modifications a small number of server configuration files is necessary. Crafting an HSTS header is a process that raises multiple questions regarding the HSTS policy. Two directives in the header play a substantial role in how the HSTS policy is enforced; these directives include: max-age and includesubdomains. Depending on the structure and content of the web applications leveraging HSTS, these directives apply in different ways.

32 SSL CERTIFICATE AUTHORITY ISSUES 32 The max-age directive can impact hosts without a pre-loaded HSTS list. The REQUIRED "max-age" directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host (from whom the message was received) as a Known HSTS Host (Hodges et al., 2012). Common website use patterns need to be analyzed in order to effectively determine a proper max-age value. Many modern web browsers do come preconfigured with an HSTS host list, but this concept clearly does not scale over the large and volatile web. For those sites left off of a preconfigured HSTS, users must rely on a properly configured max-age value to identify the server as a HSTS host. Administrators also need to analyze organizational structure and SSL services; this formulates a well-defined view as to whether or not sub domains should be included. The OPTIONAL "includesubdomains" directive is a valueless directive which, if present (i.e., it is "asserted"), signals the UA that the HSTS Policy applies to this HSTS Host as well as any subdomains of the host's domain name (Hodges et al., 2012). If includesubdomains is enabled, all subdomains pointing to HTTPS will adapt the new header; this can be problematic in the case of third-party applications and those that cannot have web headers manipulated. If multiple sites exist under a domain and some sites do not support the manipulation of the headers, administrators will need to perform additional configuration for sites that allow headers to be modified. The problem of passing HTTP site traffic to HSTS enabled sites also has multiple solutions. A common solution is to simply leave the HTTP website enabled and configure it to redirect to the SSL enabled website. Ideally, this will make it more difficult for attackers to predict where the user traffic is being handled and may stop further attacks stemming from intercepting initial client to server communication.

33 SSL CERTIFICATE AUTHORITY ISSUES 33 From an administrative perspective, HSTS implementations can be relatively straightforward given a simple domain structure and predictable end-user usage patterns. In complex and diverse environments HSTS may not scale well when considering irregular use patterns, third-party, or unsupported web servers. In short, the technical implementation of HSTS is designed to be simple; in actuality it does require careful planning and insight from system administrators. End-User Most modern browsers should accept and support he use of the HSTS standard; however, clients running on older browsers may be unable to leverage the standard. The following browsers support HSTS: Google Chrome ( onwards), Firefox (4 onwards), and Opera (12 onwards) only. It is not known if other user agents will be implementing HSTS in the near future (B et al., 2013). Users connecting to sites defined by HSTS with one of the supported browsers are protected in most cases by a default configuration. Those using browsers that have not yet adopted or implemented support for HSTS will remain vulnerable to previously disclosed vulnerabilities and attacks. Even though users do not need to configure settings in most major browsers to reap the benefits of HSTS, the users choice in browser does make an impact. In 2013, Internet Explorer was the second most popular browser in the United States, with the independent analytics firm StatCounter estimating that the browser accounted for 25% of U.S. page views (Budak, Goel, & Rao, 2014). Given that current versions of Internet Explorer do not support HSTS natively, a large amount of Internet users are left unprotected.

34 SSL CERTIFICATE AUTHORITY ISSUES 34 Demographics and Adoption Percentagewise, HSTS adaptation has been relatively slow. The Trustworthy Internet Movement (TIM) is a non-profit, vendor-neutral organization that provides statistic information publicly regarding the state of SSL implementation. Beginning on Wednesday, April 25, 2012, TIM introduced SSL Pulse, a service to summarize and visualize their research and statistical information pertaining to SSL implementation, including HSTS adoption. As of December 9, 2014, SSL Pulse identified approximately 200,000 of the most popular SSL sites on which it bases it statistics off of. Having a large demographic and distinguishable, quantitative results are important as are trending results. As noted by TIM, the surveys they publish surveys are not a measurement, but a reasonable approximation of the state of SSL. More important than the results from any one round of tests is how the measurements change over time.(tmi, 2014). Given the datasets provided by TMI, both diversity and workable quantitative data exist to create meaningful results. Such information helps foster comparisons of other demographics and regions. Data from SSL Pulse shows a clear trend in an increase of Internet sites supporting HSTS. From November 2012 to November 2014, there has been a %1.653 increase of sites monitored by SSL Pulse that support HSTS traffic (see Table 2 and Figure 5). Over the course of the data represented in this report, there has yet to be a decrease in sites supporting or using HSTS despite declining numbers in sites being monitored (see Table 2 and Figure 6).

35 SSL CERTIFICATE AUTHORITY ISSUES 35 Table 2. SSL Pulse Sites Using Strict Transport Security Month Sites Surveyed Sites Supporting HSTS % of Sites Surveyed Supporting HSTS November 2, , % December 2, ,386 1, % January 3, ,046 1, % February 2, ,360 1, % March 4, ,270 1, % April 5, ,281 1, % May 2, ,022 1, % June 2, ,406 1, % July 3, ,257 1, % August 2, ,733 2, % September 3, ,967 2, % October 3, ,509 3, % November 5, ,089 3, % Note: The information above was gathered from SSL Pulse, a research project backed by Trustworthy Internet Movement and SSL Labs (TMI, 2014) Sites Supporting HSTS Figure 5. The above figure graphically shows the number of sites supporting HSTS as indicated by SSL Pulse data collected (TMI, 2014).

36 SSL CERTIFICATE AUTHORITY ISSUES % % % % % % % of Sites Surveyed Supporting HSTS Figure 6. The above figure graphically shows the percentage of sites supporting HSTS as indicated by SSL Pulse data collected (TMI, 2014). Another team of researchers focused primarily on the security analysis of the web as it relates to China produced very similar results. Out of 10,000 Chinese websites sampled, only 6.7% were found to support HTTPS. Of those websites supporting HTTPS, 1.3% of the HTTPS sites actually enforced HTSS; thus approximately 8 out of 10,000 or 0.08% of Chinese support HSTS. (Chen, Nikiforakis, Desmet, & Huygens, 2014). This data suggests that in different geographic regions, the adoption rate of HSTS varies. Research performed by Chen, et. al indicated that the Chinese adoption of HSTS fell below that of non-chinese websites by 2.3%. HSTS Conclusion Overall, HSTS is a reasonable mechanism for furthering the mitigation of risks associated with HTTPS traffic. Most notably, HSTS provides mechanisms to detect and prevent common attacks associated with HTTPS stripping and Man-in-The-Middle. While HSTS does provide

37 SSL CERTIFICATE AUTHORITY ISSUES 37 mechanisms for enforcing HTTPS communication between a client and server, it does little by itself to solve fundamental problems associated with identifying trusted certificates. HSTS does not have strong market acceptance, but trends show it is gaining popularity steadily. Lastly users browser choice affects the use of HSTS significantly.

38 SSL CERTIFICATE AUTHORITY ISSUES 38 Conclusion With the observed methodologies for resolving certificate authority issues and the underlying model of trust, it can be concluded that effective and technically valid solutions have been proposed. Many of these solutions such as sovereign keys, public key pinning, and HTTP Strict Transport Security prove to be technically sound, although adoption rates are either nonexistent or relatively low. As standards develop, regulations change, and support for these models matures, it is likely that solutions such as those addressed in this paper will see further adoption. As discussed, it will take an effort from major market participants to further the development of solutions to address certificate authority issues and model their products accordingly to support such solutions. For future studies, we propose an examination of technologies not yet implemented in a public setting such as sovereign keys, and a review of extensions created by third parties to fill gaps in major web related products such as IIS and Internet Explorer to support these technologies. The outcome of such studies and observations would be determining technical validity, easy of use, and overall acceptance of such solutions. This would ultimately give a better picture of the state of the certificate authority issues and what the public marketplace may be able to while standards and solutions continue to be developed.

39 SSL CERTIFICATE AUTHORITY ISSUES 39 References alibo. (2011, August 27). Is This MITM Attack to Gmail's SSL? Gmail Help Forum. Retrieved from B, S., R, H. P., & S, S. (2013). SHS-HTTPS enforcer: enforcing HTTPS and preventing MITM attacks. SIGSOFT Softw. Eng. Notes, 38(6), 1-4. doi: / Bortz, A., Barth, A., & Czeskis, A. (2011). Origin Cookies: Session Integrity for Web Applications. W2SP. Budak, C., Goel, S., & Rao, J. M. (2014). Do-Not-Track and the Economics of Third-Party Advertising. Boston U. School of Management Research Paper No Chen, P., Nikiforakis, N., Desmet, L., & Huygens, C. (2014). Security Analysis of the Chinese Web: How well is it protected?. Paper presented at the Proceedings of the 2014 Workshop on Cyber Security Analytics, Intelligence and Automation, Scottsdale, Arizona, USA. Retreived from chen.pdf?ip= &id= &acc=active SERVICE&key=70F2FDC0A279768C%2E19EE468B09A55866%2E4D4702B0C3E38 B35%2E4D4702B0C3E38B35&CFID= &CFTOKEN= & acm = _37972b0aea554ca5bb004cd6e88d1177. Chromium. (August 19, 2014). Transport Security State Static. Retrieved from Eckersley, Peter. (November 18, 2011). Sovereign Keys: A Proposal to Make HTTPS and More Secure. Electronic Frontier Foundation. Retrieved from

40 SSL CERTIFICATE AUTHORITY ISSUES 40 Eckersley, Peter. (n.d.). Git.eff.org Git - Sovereign-keys.git/blob - Sovereign-key-design.txt. Electronic Frontier Foundation. Retrieved from Evans, C. P. (2014, August 7). Public Key Pinning Extension for HTTP. Retrieved from Firefox. (2014, December 1). Version 34.0, first offered to Release channel users on December 1, Retrieved from Firefox Notes: US/mobile/34.0/releasenotes/ Firefox. (2014, December 4). Version 35.0beta, first offered to Beta channel users on December 4, Retrieved from Firefox Beta Notes: US/firefox/35.0beta/releasenotes/ Fisher, D. (2014, November 14). Microsoft considering public-key pinning for Internet Explorer. Retrieved from ThreatPost: Gielesberger, Michael. (n.d.). Alternatives to X.509. Retreived from Git. (n.d.). Git.eff.org Git - Sovereign-keys.git/tree. Electronic Frontier Foundation. Retrieved from Hodges, J., Jackson, C., & Barth, A. (2012). Http strict transport security (hsts). Retrieved from ietf. org/html/draft-ietf-websec-strict-transport-sec-04.

41 SSL CERTIFICATE AUTHORITY ISSUES 41 McKinley, Holly L. (2012). SSL and TLS: A Beginners Guide. SANS Institute InfoSec Reading Room (2012): Mosenkovs, D. (November 30, 2014). Public Key Pins Test. Retrieved from Mozilla. (n.d.). Introduction to Public-Key Cryptography. Mozilla Developer Network. Retrieved from Key_Cryptography. Mozilla. (n.d.). Security Engineering/Public Key Pinning. Retrieved from Mozilla Wiki: OWASP. (n.d.). Certificate and Public Key Pinning. Retrieved from Open Web Application Security Project: OWASP. (October 30, 2014). HTTP Strict Transport Security. OWASP. Retrieved from Singh, K., Wang, H. J., Moshchuk, A., Jackson, C., & Lee, W. (2012). Practical end-to-end web content integrity. Paper presented at the Proceedings of the 21st international conference on World Wide Web, Lyon, France. Retrieved from singh.pdf?ip= &id= &acc=active SERVICE&key=70F2FDC0A279768C%2E19EE468B09A55866%2E4D4702B0C3E38 B35%2E4D4702B0C3E38B35&CFID= &CFTOKEN= & acm = _8afcc98cf469d3d30eb851cad356a461. Stamm, S. (2014, September 2). Public key pinning released in Firefox. Mozilla Security Blog. Retrieved from

42 SSL CERTIFICATE AUTHORITY ISSUES 42 Swiat. (2013, May 8). EMET 4.0's Certificate Trust Feature. Microsoft Security Research & Defense Blog. Retrieved from Tews, Erik. (January 28, 2012). Sovereign Keys A Proposal for Fixing Attacks on CAs and DNSSEC. Cryptanalysis Breaking News. Retrieved from TMI. (November 5, 2014). SSL Pulse - Survey of the SSL Implementation of the Most Popular Web Sites. Retrieved December 9, 2014, 2014 from Wikipedia. (November 26, 2014). Public Key Certificate. Retrieved from Wikipedia. (n.d.) Public-key Cryptography. Wikimedia Foundation. Retrieved from Wikipedia. (n.d.). Public Key Infrastructure. Wikimedia Foundation. Retrieved from

43 SSL CERTIFICATE AUTHORITY ISSUES 43 Appendix Public Key Pinning Error Messages This Appendix shows screenshots from several browsers when the pinned value is not found in the certificate chain presented by the server. Google Chrome Figure A 1. Google Chrome Pinning Error Message

44 SSL CERTIFICATE AUTHORITY ISSUES 44 Mozilla Firefox Figure A 2. Firefox version 34.0, before HPKP was supported Figure A 3. Firefox Version 35.0 Beta, after HPKP was supported

45 SSL CERTIFICATE AUTHORITY ISSUES 45 Internet Explorer Figure A 4. IE version does not support HPKP

46 SSL CERTIFICATE AUTHORITY ISSUES 46 Safari Figure A 5. Safari 7.1 does not support HPKP

47 SSL CERTIFICATE AUTHORITY ISSUES 47 Opera Figure A 6. Opera allows users to bypass HPKP