GoSSIP_SJTU · 2015/11/16 when

Author: zhang lu

0 x00 briefly

In recent years, SSL/TLS protocols based on the PKI system have been exposed to many security problems, such as HeartBleed, POODLE and Freak attacks. In 2014, there were thousands of Cves about SSL/TLS certificate verification problems. In view of various problems exposed in the implementation of SSL protocol, here we discuss the existing reinforcement and prevention schemes, mainly including four aspects:

A) Key pinning strategy B) HSTS strategy C) multipath certificate checking strategy D) DNs-based authentication

The following are detailed descriptions based on these four strategies.

0x01 Key Pinning Strategy

Key Pinning Introduction

Pinning is a security technique that links a server’s host name to cryptographic elements such as certificates and public keys. For example, if you know the correct certificate of a website and link to the website again, you can compare the known correct certificate with the certificate received from the website to determine whether the website is attacked by man-in-the-middle. You can hash the certificate (for example, SHA-256) and save the hash value locally. In this way, it is more convenient and saves space than a full certificate.

Public Key pinning is more practical than certificate pinning, because many times when certificates are resigned they don’t change their public key information, which is why many certificates have the same public key. In this way, if the local pin is the public key information, it is ok to receive different certificates, as long as the public key content is the same, they can be trusted.

For a certificate-independent protocol such as SSH, you can pin the public key directly, but for SSL/TLS, the best way is to pin the HASH value of the SPKI (SubjectPublicKeyInfo) portion of the X.509 certificate. The SPKI section contains the public key and other additional information for security verification (including the public key encryption algorithm used, public key bits).

2. Pin position

To ensure security, the public and private keys of the server are frequently changed. If the private key is leaked, you need to issue a new certificate from the CA. And the same site may have multiple public and private key pairs deployed. If the pin is the server’s public key, maintenance and use can be complicated.

Based on the above considerations, the pin location can be placed on the certificate chain. Typically, the certificate chain starts with the terminal certificate, has an intermediate CA certificate, and ends with the root CA certificate. If the pin is the information of the last two certificates (the information of the intermediate CA or the root CA), the certificate chain is unchanged and the PIN information does not need to be changed as long as the certificate issued by the same CA is replaced.

However, another problem occurs here. Cas may have many upper-level intermediate cas or different root cas. When the server replaces the certificate, even if the same CA is selected, the upper-level intermediate CAS may be different.

Based on these considerations, the best pin location can be on the second certificate in the certificate chain, that is, the certificate of the CA that issued the certificate to the server, because even if the server changes the certificate, the CA will be selected to issue the certificate, and the PIN information will not change.

3. When to use pin

The most efficient way of pinning pinning is in native applications. At this time, as the developer can control both sides of the communication, both for desktop applications and mobile applications, such as some banking software, payment software, etc.

In this case, if developers can control both sides of the communication (client and server), they can use their own certificates as pinning information, as well as certificates issued by third-party cas.

4. Drawbacks of Key pinning:

  • If the server private key is leaked, you need to change the key pair. In addition, the server often changes the key pair to ensure that the same key does not encrypt too much information. At this time, it is necessary to change the pin information frequently, and the operation is complicated.
  • There can also be multiple certificates on the same site, and if the content of pinning is not complete, there can be error messages.
  • For some applications, replacing pin information requires software upgrade, which is inconvenient.

0 x02 HSTS strategy

1. Introduction to HSTS

HTTP Strict Transport Security (HSTS) HTTP Strict Transport Security (HSTS), which was first proposed in 2009 and standardized in RFC 6797 in November 2012, is an Internet Security policy mechanism published by the Internet Engineering task force. Web sites can choose to use the HSTS policy to force browsers to use TLS and discontinue all connections with incorrect certificates, thereby mitigating some of the risks browsers face when implementing TLS.

The use of HSTS strategy mainly solves the following problems:

  • Faced with a host name (which does not specify a protocol), the browser does not know whether the site uses TLS;
  • When a certificate error occurs, the connection is not blocked, but an alarm is sent to the user (most users choose to ignore it).
  • HTTPS pages load resources from an HTTP origin, known as mixed Content. Attackers can control the mix content loaded from insecure pages to HTTPS pages to achieve the attack effect.
  • Cookies adhere to a different same-origin policy than Web Content and are isolated only by host, so HTTPS and HTTP share cookies.

HSTS solves these problems in two ways:

  • Convert all HTTP to HTTPS locally to ensure that HSTS websites can only be accessed through HTTPS.
  • Break the link when a certificate error is encountered.

2. Security significance of HSTS

Some sites that support HTTPS also generally listen for HTTP requests and redirect them to HTTPS later. For example, if http://www.facebook.com is received, the user access is redirected to https://www.facebook.com. This redirection is not secure because the first request uses HTTP, which allows the attacker to retrieve sensitive information (such as Coocie from the previous secure session), or redirect the user to phishing sites. In addition, according to users’ input habits, HTTPS is not added before the host name, which is more likely to cause threats.

The HSTS policy prevents this threat by requiring the browser to force HTTP to HTTPS locally and then communicate with the server over HTTPS.

3. HSTS execution

The server turns on HSTS by including the strict-transport-Security field in the hypertext Transfer protocol response header returned by the server when the client makes a request over HTTPS (the HSTS field set for non-encrypted transmission is invalid, Strict-transport-security header information is ignored by the browser when passed through an HTTP request, because an attacker may intercept or tamper with HTTP headers until the first secure connection is made over HTTPS. The HSTS policy is configured for the site only after the strict-transport-Security header is received. This can be solved by using the browser to preload the HSTS policy.

The strict-transport-Security fields include:

Strict-Transport-Security: max-age=expireTime [; includeSubdomains]
Copy the code

The max-age parameter specifies the expiration time, in seconds. The browser needs to remember when the site is accessible only through HTTPS. IncludeSubdomains is optional, indicating that the subdomains of the site also need to be accessed via HTTPS.

The strict-transport-security field is handled by the browser:

When the browser uses HTTPS to access a website for the first time and receives a header containing this field from the server, it records this information and converts all requests to the website to HTTPS within the validity period. Each time the browser receives the strict-transport-Security header, it updates the validity period specified by max-age, which prevents the HSTS policy from expiring.

Let’s briefly describe the HSTS functionality with graphics:

Figure 1

Figure 1 illustrates the process of redirecting HTTP requests to HTTPS under normal circumstances. This process is not secure.

Figure 2

Figure 2 shows that the strict-transport-Security header for HSTS is received on the first secure connection, and the HSTS policy is enforced on subsequent accesses.

Figure 3

Figure 3 illustrates the HSTS policy execution process.

4. HSTS deployment

HSTS should be deployed with consideration for comprehensiveness. By default, HSTS is only deployed for host names that return strict-transport-security response headers, but many sites can deploy multiple domain names, so be aware that the HSTS policy is deployed to all domain names.

Some sites with only one host name also need to consider whether the deployment is comprehensive. For example, when a user wants to access a website, the WWW prefix is not added (enter XXX.com to visit www.XXX.com). Because the user input cannot be controlled, all host names must be overwritten when configuring HSTS.

In addition, the comprehensiveness of HSTS deployment should take into account all pathnames that can reach the website. For example, users may enter the root domain name first and then access other sub-domain names. In this case, if the root domain name is not deployed, SSL stripping attacks may be triggered.

5, HSTS Preloading

When a user correctly connects to a website using HTTPS for the first time and receives the strict-transport-Security header, the HSTS policy is set for the website based on the header information. To improve HSTS security efficiency and resolve the first Visit problem, The Google security team sets the HSTS preload List in The Chrome browser. All domain names in the list automatically apply the HSTS policy. Firefox, Safari, and the latest version of Internet Explorer all incorporate Chrome’s HSTS Preload List.

The following requirements can be met using HSTS Preload:

  • Ensure that both root and subdomains are forced to use HTTPS.
  • All subdomains are marked with a policy validity time and a preload tag indicating that the domain owner agrees to be added to the Preload list.

For financial institutions, government websites, or social networks, HSTS can mitigate threats to a large number of SSL/TLS protocols. However, the HSTS strategy is not inferior to certificate forgery attacks and requires key-pinning strategies to be used in tandem.

0x03 Multipathing Certificate Detection

The core idea of the multipath certificate check policy is to verify the validity of the certificate received by the client through multiple methods and methods, not only relying on the PKI system but excluding the authority of the CA.

There are two methods for checking multipathing certificates:

  • Notarial assistant certificate examination;
  • Tor Network Check;
  • Social network Checks with the help of Social networks.

Here we focus on the first two methods.

1, notary assistant certificate inspection

1.1 introduction of Notary

Notaries to assist in verifying certificates refers to assisting in verifying whether certificates are legal and valid through a third party (Notaries). One of the first was Perspectives, a Plug-in for Firefox that compares incoming server certificates with a large number of Notaries from different network nodes, so that even if some of them were to break down, an attacker would still not be able to breach all of them. Check whether the certificates are the same to determine whether a man in the middle attack occurs.

Figure 4.

Figure 4 shows the process of certificate comparison using Notaries. When the client receives the certificate returned by the server, it sends a request to the set notaries, searches for the corresponding certificates in the notaries according to the host name of the server, and compares the returned certificates. If there is any difference, the certificate will be considered invalid. These notaries are deployed in different online environments.

1.2 Notaries Certificate obtained

The Notaries, which correspond to the original Perspectives, will regularly and actively scan hosts across the network to obtain the public key corresponding to the certificate, and store it in the local database. When the Perspectives plug-in of the browser requires certificate comparison, the public key of the certificate corresponding to the host will be obtained from the database. Return to the client for comparison. Convergence Notary offers a similar feature in 2011, except that Convergence Notary does not actively scan the entire network and only asks the host for a certificate that is not already in the local database. At the moment, Perspectives and Convergence are the two authoritative notary conservators, each safeguarding the many notaries that can be shared.

1.3 Assessment of Notaries

Using Notaries as a third party to assist in public key checking, browsers can rely entirely on the trusted Notaries set by plug-ins, weakening the PKI system based on X.509 certificates. At the same time, if one Notaries is breached, users can change their Settings and choose a different Notaries.

There are some downsides to using Notaries for certificate verification:

  • This reduces user experience and adds a layer of certificate verification process, slowing down network access speed.
  • For some Notaries, there are privacies about which websites users want to visit;
  • Some websites may have multiple certificates, leading to false positives of Notaries.

2. Tor-network Auxiliary certificate check

The characteristic of THE Onion network is that when a user visits a fixed destination, the path is random each time. Specifically, TOR clients maintain a browser-like proxy that provides an excuse for other software to enter the TOR network. TOR nodes choose different paths for different connections and are not vulnerable to man-in-the-middle attacks. This feature can be used to check multipath certificates.

The Onion nets-assisted certificate check is established in the case of a certificate warning in normal HTTPS protocol, the onion network obtains the certificate again and compares the two certificates to determine whether the two certificates are the same to determine whether the two certificates are under man-in-the-middle attack.

Figure 5

Figure 5 shows the process of checking multipath certificates using TOR-Network:

  • Alice receives an HTTPS certificate warning;
  • Access TO ONION network through the AGENT of ONION Network;
  • Get the certificate of the target server;
  • Check whether the certificates obtained twice are the same.

The idea of multipath certificate check is to obtain multiple certificates and compare them with the received certificates to determine whether the certificates are subject to man-in-the-middle attacks and improve communication security. However, this method inevitably increases the TLS connection time and reduces user experience.

0x04 Dns-based Authentication Policy

4.1 introduction of DANE

DANE (DNS-BASED Authentication of Named Entities) is a security standard that combines domain name and cryptography elements. It was standardized and defined in RFC 6698 in August 2012. Domain name owners can control DNS configuration and use DNS as a separate channel to enforce TLS security. DANE is easy to deploy, but DNS alone does not provide any security and relies on the DNSSEC protocol.

In short, DNSSEC uses digital signature authentication technology to verify the identity of each DNS in the whole request chain when making a domain name request, ensuring that the final received domain name information is correct and not tampered with.

The current authentication mechanism is divided into two phases: one is that a group of trusted third parties issue certificates for the real owners of domain names, known as CAS. Second, clients (such as browsers) can detect that the certificate corresponding to a host name is correct. Based on this separate architecture because communication parties are generally far away from each other, authentication is easy to detect fraud. With THE DNSSEC protocol, DNS requests can be secured, DNS can be used to provide authentication, and there is a new way to communicate with the domain name owner, thus eliminating the dependency on CA.

In short, DANE is the certificate corresponding to the host name of the client pin, which is then obtained through a DNS request and compared to determine the credence of the certificate.

4.2 DANE role

  • Secure deployment of self-signed certificates

    Right now, self-signed certificates are considered insecure because there is no way to distinguish between self-signed certificates and man-in-the-middle forged certificates, which means that self-signed certificates are all the same. However, we can pin a self-signed certificate with secure DNS so that the browser knows that the self-signed certificate in use is secure and can easily distinguish a forged certificate from a man-in-the-middle attack.

  • Security deployment private root certificate If safe to pin a server certificate, you can also pin any certificate of the server certificate in the certificate chain, that is to construct a web site that you have the root of the certificate, and let the client trust this certificate, this way to have a lot of website developers, more convenient.

  • Support for CA certificates and Public keys -pinning Ca-issued certificates and root certificates can also be done on client side without changing the existing authentication architecture.

4.3 DANE to perform

DANE extends a new DNS Record type called TLSA Resource Record(TLSA RR or TLSA). TLSA contains four zones :(1) Certificate Usage; (2)Selector; (3)Matching Type; (4) Certificate Association Data.

Where Certificate Usage field has four different values:

0-CA specification: PIN a CA, and there must be a certificate issued by the corresponding CA in the certificate chain. 1- Specify TLS certificates: TLSA records the exact TLS certificates specified to be used for a domain name; 2- Trust point declaration: pin a site’s own CA on the client, which may not be a publicly trusted CA; 3- Certificate issuing by domain name: Pin a specific TLS certificate on the client. The certificate can be a certificate issued by a host

The last two values indicate that DANE is perfectly capable of supporting self-signed certificates while also ensuring the security of using self-signed certificates.

Since then, we’ve covered four common SSL/TLS hardening strategies, each of which has its pros and cons. Key pinning can be used in conjunction with HSTS to ensure that HTTPS is enforced while also ensuring certificate security. In addition, there is always some conflict between security and user experience, and different people have different opinions on the difference between taking and taking.