"Man in the middle" using revoked certificates. Part 2

Our previous article described the basic mechanisms for checking the status of certificates (checking whether a certificate has been revoked). In this article we will answer the following questions:



1. How are certificate status verification mechanisms implemented in modern Web browsers?

2. Who is to blame? Why are they implemented that way?

3. What to do ? What are the prospects?



This article will be useful to those who are interested in understanding the mechanisms used in practice for checking the status of certificates.

')

On Habré already wrote on this topic (for example, here and here ), we in this article decided to give an even more detailed description of the checks performed by modern browsers, more relevant information about their settings, and, finally, a description of how you can fix the current situation in the future.

Certificate status checks implemented in Web browsers

The mechanisms for checking the status of certificates implemented in modern Web browsers are a combination of the previously described basic mechanisms (CRL, OCSP, OCSP stapling) and their modifications. The combination of basic mechanisms is carried out to ensure redundancy: if one of the sources of information about the status of a certificate becomes unavailable, then a backup one is used. For example, OCSP may be used as the main mechanism for checking the status of certificates, but if the OCSP server is unavailable or the server fails, the CRL loading for the client will be more time-consuming.



To understand the basic problem of checking the status of certificates implemented in modern browsers, it suffices to consider the following man-in-the-middle attack scenario.







The server's private key has been compromised. The server owner revoked the compromised key certificate, generated a new key pair and received a new certificate.

The intruder seized the revoked private key and server certificate. In this scenario, we deliberately do not say how he accomplished this: as a result of the compromise of the server itself or as a result of the compromise of the certification center (CA). This is done to demonstrate how browsers behave in both situations.



The intruder, the “man in the middle”, controls all traffic coming from the client. He may intercept or block this traffic, may attempt to respond to the client on behalf of other network services.



The client’s web browser, when attempting to establish a TLS connection with the server, connects to the “man in the middle”. "Man in the middle" is presented by the server using a revoked certificate without an attached OCSP response (aka OCSP stapling ). The intruder blocks requests from the client to all OCSP servers and CRL distribution points (aka CDP ). The intruder also blocks the client’s attempts to update the Web browser or its components (for example, the black lists of “CRLSets” or “OneCRL”, which will be discussed later).



Man-in-the-middle blocking of requests to all OCSP servers and CRL distribution points, firstly, supports the initial condition according to which an intruder could compromise both the server and the CA, and, secondly, most fully demonstrates certificate status checks, performed by modern browsers.



The following is a description of the status checks for certificates performed by various Windows web browsers. For other platforms, details of checks may vary slightly.

Mozilla firefox

The behavior of Mozilla Firefox version 54 (the most relevant at the time of this writing) for such an attack differs depending on the type of server certificate: DV or EV. By issuing a DV-certificate (domain validated), CA only confirms that the owner of the key specified in the certificate controls the domain specified in the certificate. Most certifications are DV. EV certificate (extended validation) confirms not only the domain ownership, but also the identity of the domain owner. Such certificates require additional checks from the CA, because they are much more expensive and less common.



Checking the status of DV certificates performed by Firefox is described in the following diagram:







The scheme for simplicity does not show the interaction with the cache of previously received OCSP responses, because we assume that they either do not exist (because of an attack or because the server is accessed for the first time in quite a long time), or they are outdated and talk about That the certificate is not revoked. In the second case, the browser behavior is trivial: the connection will be allowed.



So, the browser checks the status of the server certificate chain (intermediate CA certificates and the server certificate itself). To check the status of intermediate CA certificates, use the OneCRL blacklist stored locally on the client, containing information about revoked certificates collected from various CRL distribution points. The status of the blacklist is maintained using the CRL aggregator, a separate remote service that works as follows:



1. The aggregator periodically polls a certain set of CRL distribution points.

2. From the received CRLs, selects the most critical information about revoked certificates (for example, certificates revoked due to the compromised private key).

3. Updates based on this information to blacklists in browsers.



The CRL aggregator and, as a result, the contents of the OneCRL blacklist is controlled by Mozilla. “OneCRL” does not cover all revoked certificates, but only certificates of some intermediate CAs and a small number of server certificates. This is done to reduce the size of the black list. The current list of “OneCRL” can be found here .



To check the status of the server certificate, information obtained from “OneCRL”, attached OCSP responses or responses obtained as a result of an OCSP request is used. The diagram shows the check of the presence of the attached OCSP response for the server certificate only, because Firefox does not support the attached OCSP responses for intermediate CA certificates ( RFC 6961 ).



It is important that if none of the sources of information on the status of the certificate is available, then the certificate is not considered revoked . In other words, the test is performed in soft fail mode. Thus, the attack "man in the middle" is successful. It does not matter whose key was compromised initially, the key of the server itself or the CA.



In addition, it is worth noting that the client-side of the OCSP protocol, implemented in Firefox, does not support one-time random codes (nonce) and, therefore, OCSP responses are not protected against replay attacks.



A similar situation arises when checking EV certificates. The only difference is that the browser additionally performs OCSP requests for intermediate CA certificates:







You can change the browser behavior and enable the hard fail mode (i.e., prohibiting the establishment of a TLS connection in cases where certificate status information is not available) by setting the "security.OCSP.require" option in the browser settings ("about: config") to true:







It should be noted that this setting does not activate the use of the OCSP protocol for intermediate CA certificates in cases where the server presents a DV certificate.



For the end user, hard fail in Firefox looks like this:







Note that the man-in-the-middle attack is still possible! .. The intruder is required to conduct an OCSP replay replay attack, sending the old OCSP response generated before the certificate was revoked. However, this attack can only be carried out until the “old” OCSP response expires. At the same time, the OCSP response can be quite long. Often it is equal to a week.

Microsoft Internet Explorer / Edge

Microsoft Internet Explorer version 11 and Microsoft Edge version 40 browsers behave the same for DV and EV certificates:







In the scheme, as before, for simplicity, the interaction with the cache of previously received OCSP responses and CRLs is not shown, although a separate article can be devoted to this.



For each checked certificate in the chain in the absence of attached OCSP responses, an OCSP request is executed. At the same time, Internet Explorer and Edge do not support attached OCSP responses for intermediate CA certificates ( RFC 6961 ) and do not protect OCSP responses from replay attacks. If the OCSP server is not available, then an attempt is made to load the CRL.



The check is also performed in soft fail mode. Thus, the man-in-the-middle attack is also successful and it also does not matter whose key was compromised initially, the key of the server itself or the CA.



You can change the behavior of Internet Explorer, for example, by setting the registry key value "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_WARN_ON_SEC_CERT_REV_FAILED \ iexplore.exe" to 1. Then, if there is no information about the certificate status, the connection will still be allowed, however A small warning will appear in the address bar:







For Edge, no such settings were found.

Google Chrome / Cromium

Google Chrome and Chromium version 59 browsers behave as follows when checking DV certificates:







The checks performed by Chrome are similar to those performed by Firefox, with the exception that Chrome refused to perform OCSP requests when checking DV certificates. “CRLSets” in Chrome is similar to “OneCRL” in Firefox (strictly speaking, the “CRLSets” mechanism appeared even earlier) and has the same problems of incompleteness and lack of control to the end user.



OCSP requests are used when checking EV certificates (here the picture becomes almost identical to what we observed for Firefox):







Like other browsers, Chrome and Chromium operate in soft fail mode. Attached OCSP responses for intermediate CA certificates ( RFC 6961 ) and protection of OCSP responses against replay attacks are not supported.



You can change the behavior of Chrome and Chromium by making changes to the group policy ( instructions here ) and by including the following options:







Equivalent tuning is possible under Linux ( here ).



After making these changes, Chrome and Chromium will perform checks similar to those done by Internet Explorer (in the absence of attached OCSP responses, they will start performing OCSP requests with a rollback to downloading the CRL for the entire certificate chain), but in hard ail mode, i.e. ., if OCSP servers and CRL distribution points are unavailable, the connection will be prohibited:







It should be noted once again that the “man in the middle” attack is still possible. The intruder is required to block the OCSP and carry out the CRL replay attack, sending the “old” CRL generated before the certificate was revoked. However, this attack can only be carried out until the “old” CRL expires. In this case, the validity of the CRL can be quite long. For example, the CRL for a “www.google.com” certificate is valid for a week.

Other browsers and platforms

For other popular browsers and platforms, the situation is the same: everywhere certificates status checks are performed in soft fail mode, or not at all. You can read more here or here .

Why now everything works that way?

This is well written in the blog of Adam Langley . The absence of hard fail and the rejection of the explicit execution of OCSP requests on the client side are due to the following factors:

• CA infrastructure will be a single point of failure. The inaccessibility of the OCSP server can cause a denial of service to a whole segment of the Internet. CA infrastructure becomes a new target for DDoS;
• Increased cost of the support center infrastructure. CA is required to buy channels with greater bandwidth and provide protection against DDoS;
• reduced reliability of TLS connections in unstable or noisy networks (for example, mobile networks);
• The volume of traffic is increased and a large bandwidth is required, which is critical, again, for mobile clients;
• problems using OCSP together with a captive portal. Passwords are usually transmitted over TLS, however, a TLS connection cannot be established and authenticated until answers are received from OCSP servers. You can't send OCSP requests, because OCSP servers (at least for intermediate CA certificates) are usually on the Internet, and there is no access to them at this stage. This problem can be solved with the help of attached OCSP responses, but checking the status of intermediate certificates currently still requires sending OCSP requests, since no browser supports attached OCSP responses for intermediate CA certificates ( RFC 6961 ).

In this case, a complete rejection of the explicit execution of OCSP requests on the client side does not occur, since it can still protect from the “man in the middle” in cases when it is “close” to the server “far” from the client, i.e. Access to TLS traffic, but cannot block OCSP:

What are the prospects?

The obvious conclusion from all of the above: the status checks for the certificates in browsers do not work, and this is not news. At the same time, it is simply impossible to take and go to hard fail for objective reasons.



Is there a practical solution to this problem? After analyzing and putting together many of the already proposed partial solutions to this problem (in particular, the extension of TLS feature certificates, short-term certificates, CRL aggregators, etc., which will be described in detail below), we bring to your attention our idea of ​​how verification of the status of certificates should occur in practice.



The basis is the assertion that not all services require online verification of the status of certificates. For most services, the overhead associated with ensuring strict online status checks for certificates in hard fail mode does not pay back the risks associated with a man-in-the-middle attack using revoked certificates. In other words, in terms of checking the status of certificates, services are divided into two types:



1. The minority for which strict online status checks of certificates in hard fail mode will be carried out.

2. The majority for which online status checks of certificates will not be performed at all (other protection measures will be taken).



Browsers can distinguish such services by the presence of a special extension in the server certificate. Depending on the type of service, the client will either perform a “paranoid” verification of the status of certificates, or will not perform it at all. Now more about each of these two schemes.

The paranoid scheme of checking the status of certificates for a minority

In 2015, the specification of the new X.509 standard certificate extension, called the “TLS feature” (in the early stages of the development of the standard also known as “OCSP must staple”), was published. This certificate extension allows you to capture in the certificate those TLS protocol options that the TLS server that presents this certificate will support. Such an option of the TLS protocol in particular is the attached OCSP responses. An example of a certificate with this extension is schematically shown below:







The certificate has an extension “TLS Feature” (highlighted in red), indicating that the TLS server must support the attached OCSP responses specified in RFC 6066 (“Status Request (Version 1)”), and a newer version of this option ( “Status Request (Version 2)”), as specified in RFC 6961 — multiple attached OCSP responses. The new version of this TLS protocol option allows you to attach OCSP responses for intermediate TC certificates.



For example, if, when connecting a client that supports the “Status Request (Version 1)” option, the server “www.example.com” together with its certificate shown in the figure above did not send the message “ClientHello” of the handshake protocol attached OCSP response version 1, then the TLS connection setup is terminated with an error. Thus, a “man in the middle” using a revoked certificate of this kind will not be able to discard the attached OCSP response indicating that this certificate has been revoked.



Since we are building a “paranoid” certificate status verification scheme, in addition to using certificates with the “TLS Feature” extension, the following should also be noted:



1. Attached OCSP responses should be protected from replay attacks (random one-time codes should be used). Even when using certificates with such an extension, the offender has a window for attack, determined by the OCSP response time: it is still possible to carry out a replay attack and send the old OCSP response received before the certificate was revoked.

2. The “Status Request (Version 2)” option should be used. This option allows you to attach OCSP responses for all certificates in a chain, not just for a server certificate. This allows you to completely abandon the explicit execution of OCSP requests on the client side and all its inherent and previously described shortcomings.



So, in the end, the “paranoid” scheme for checking the status of certificates is based on the following:

• The TLS server uses a certificate with the “TLS Feature” extension, which requires the server to support the TLS “Status Request (Version 1)” and “Status Request (Version 2)” options;
• TLS-client and TLS-server should use attached OCSP-responses protected by random one-time codes from replay attacks;
• if the TLS client supports the “Status Request (Version 1)” option, but does not support the “Status Request (Version 2)” option, having received a certificate with the “TLS Feature” extension from the server, it must explicitly perform OCSP requests (using random one-time codes) for intermediate CA certificates in hard fail mode.

With all this, this verification scheme, as already mentioned, will have the following disadvantages:

• increasing the load on the OCSP servers of the TC;
• vulnerability to DDoS attacks on servers TC.

The solution to the first problem can be the resumption of TLS connections using the session ID or session ticket mechanisms. These mechanisms are protected from the considered man-in-the-middle attack and allow you to resume a previously established TLS connection without sending certificates and, accordingly, without executing requests to the OCSP servers of the CA. With this approach, reducing the load on OCSP servers will occur at the cost of storing additional information necessary to resume the connection on the client and the server (or only the client).



As a solution to the second problem on the server, you can alternately use several certificates issued by independent CAs. In this case, while the OCSP servers of one CA will be “lying” due to DDoS, the TLS server will use an alternative certificate issued by another CA that is not under attack. Using multiple certificates will also allow you to balance the load between CAs.



In order to assess how the client side (under Windows) is ready for a transition to a bright future, you can look at the following table:

Scheme for most

As mentioned earlier, for most services, the overhead associated with ensuring strict online checks on the status of certificates in hard fail mode does not pay back the risks associated with the man-in-the-middle attack using revoked certificates. In this case, it is better not to defend against this attack, but to minimize the time interval during which this attack will be possible. For this purpose, certificates with a short period of validity (for example, 1-2 days) are used.



Thus, most services will use certificates without the “TLS Feature” extension, but with a short validity period. For such certificates, online status checks for certificates will not be performed at all. Instead, there will be frequent updates of rapidly aging certificates.



We add that using certificates with a short period of validity is equivalent to using certificates with the “TLS Feature” extension, which requires the use of attached OCSP responses, together with attached OCSP responses that are not protected from replay attacks (i.e. OCSP responses cached on TLS server). At the same time, certificates with a short period of validity are slightly more effective in terms of saving traffic and the number of operations required to verify a certificate.



The approach with the use of certificates with a short term of validity has a number of advantages, but it is of little use for CA certificates. To check the status of such certificates, you can use periodically updated blacklists similar to “CRLSets” and “OneCRL”, but giving users more control over the CRL aggregators. Users, for example, should be able to add new polled CRL distribution points. This is important because some organizations deploy their own non-public CAs for internal use. The solution may be the possibility of using private CRL aggregators. In this case, you will need to develop an open protocol for interaction between the client and the CRL aggregator, ensuring compatibility between clients and aggregators of various vendors.

Total

Well, so far everything is not very good: verification of the status of certificates in modern browsers really does not work.



However, there is still light at the end of the tunnel, and the situation is gradually, albeit slowly, moving towards the best.