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

What to do if your server has a private key? A question that has become particularly relevant after Heartbleed .

The sequence of actions that immediately comes to mind:
1. Contact the certification center.
2. Revoke server certificate.
3. Re-generate keys.
4. Request a new certificate for the server.
5. Raise the glass for the success of the operation and try to live on.

Unfortunately, it's not that simple. In this and the next article we will answer the following questions in detail:
')

• What are the mechanisms for checking the status of certificates?
• How are they implemented in modern web browsers?
• Who is guilty? Why are they implemented that way?
• 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 (checking whether a certificate is revoked).

UPD: added the second part of the article! Read here .

TLS protocol and X.509 public key infrastructure in short

A modern secure Web stands on two pillars: the TLS protocol and the X.509 public key infrastructure . To establish a secure TLS connection, the server must transmit its public key to the client. The authenticity of the server key sent over unprotected public networks is ensured by a chain of X.509 infrastructure public key certificates .


A certification authority (CA, certification, CA) may revoke a previously signed (issued) certificate, for example, if the private key corresponding to this certificate is compromised. Therefore, in order to exclude the possibility of connecting to a “man in the middle”, when installing a TLS connection, the client must not only check the correctness of the signatures of the entire certificate chain provided by the server, but also check the status of the certificates provided to him (the certificate is valid or revoked).

Certificate Status Checker Mechanisms

Practical mechanisms for checking the status of certificates are based on certificate revocation lists (CRLs) and on the certificate certificate online protocol (OCSP).

Further, as an example, we will consider the server certificate with the domain name www.example.com , issued by the CA “Example Certification Authority”, shown schematically in the figure:

CRL mechanism

CAs publish CRLs with serial numbers of revoked certificates in CRL distribution points (CRL distribution points, CDP). Addresses (URLs) of CRL distribution points that should be contacted to obtain information on the status of the certificate being checked are, as a rule, indicated in the certificate itself.

To check the status of the certificate shown in the figure above, you need to download the CRL available at the URL ca.example.com/crl and check whether it contains the serial number of the certificate being verified (46: 35: AC: 5F).

The figure shows a schematic of the loaded CRL.


It states that the CA “Example Certification Authority” revoked three certificates with serial numbers 00: C9: 79: 0E, 46: 35: AC: 5F and 50: 4E: 6F: C7. The certificate to be verified is revoked because its serial number is in this list.

Customers receive fresh CRLs in one of the following ways:

• (conditionally in the "passive" or offline mode) with the help of periodic updates. CRLs in the client database can be updated automatically, for example, when updating client software or manually by an administrator;
• (in "active" or online mode) independently loading them as required from CDP.

CRLs are most often used for offline checks and are not well suited for systems that need the most up-to-date certificate status information and require the above-mentioned online CRL downloads, for the following reasons:

• CRLs are redundant and poorly suited for frequent repetitive downloads. Sometimes their sizes are close to 1 MB;
• CRLs are not protected from replay attacks and allow the “person in the middle” to slip the victim out of date CRLs that do not yet contain information about compromised keys.

OCSP mechanism

OCSP, as its name implies, is designed to get the most up-to-date information about the status of a certificate online and does not have the above CRL flaws.

Consider the operation of this protocol on the example for the certificate www.example.com (see the second picture to the article). For information about the status of the certificate, the TLS client uses the OCSP client to send a request to the OCSP server (OCSP responder) of the CA specified in the certificate authority access access (AIA) certificate:


The request indicates the serial number of the certificate being verified (46: 35: AC: 5F). Also, in the request, a random one-time code (nonce) can optionally be transmitted to protect the OCSP server response from a replay attack. The OCSP server response says that the certificate with serial number 46: 35: AC: 5F was revoked because its corresponding private key was compromised. The OCSP response is protected from forgery and replay attacks, because it is signed by a trusted key of the OCSP server and contains random one-time code received from the client.

It should be noted that protection against replay attacks in OCSP is optional and its absence has its advantages. Disabling the checking of the random one-time code value on the client allows you to cache OCSP responses on the server side, reducing the overhead of the protocol.
OCSP problems are:

• increase the time for setting up a TLS connection;
• disclosure of client connection history to a third party (CA).

OCSP stapling

To solve these problems, an extension of the TLS protocol was proposed, allowing attachment of OCSP responses to certificates ( OCSP stapling ) and transferring responsibility for running OCSP to a TLS server.

The figure shows a diagram of the use of OCSP stapling:


The diagram describes the following steps:

1. The TLS server, acting as an OCSP client, collects information about the status of its certificate chain by accessing the OCSP servers of the corresponding CAs;
2. TLS server caches received OCSP responses;
3. When a TLS connection is established, the server sends its certificate chain to the client along with its corresponding OCSP responses.

In this way:

• TLS connection setup time does not increase, because at the time of establishing the OCSP connection, neither the client nor the server is running;
• reduced load on the OCSP-servers TC;
• The client does not disclose CA network resources used by it.

“But where is the protection against replay attacks?” You ask. Here it really does not exist, however, the considered TLS protocol extension allows clients to send a random one-time code when establishing a connection:


This option of using OCSP stapling does not allow caching OCSP responses on the server, which increases the time required to establish a TLS connection and increases the load on the servers of the CA.

It should be noted that there are two versions of OCSP stapling. The first version for unclear reason allows you to attach an OCSP response only for the certificate of the server itself. With this version, it is the responsibility of the client to obtain information about the status of the remaining certificates in the chain. This flaw is fixed in the new version .

To be continued ... In the meantime - great news!

In this article, we looked at three basic mechanisms for verifying the status of certificates. The checks carried out in practice are add-ins on these mechanisms or their combination. The topic of further discussion and the next article - how are certificate status checks implemented in Web browsers?

We talked about the problem of revoked certificates and the “Nightmare of compromised keys” on the “face-to-face” NeoQUEST-2016. We even have a great video in which the author of the article talks about revoked certificates:



While we are actively preparing for the next "confrontation" NeoQUEST-2017, which will be held in St. Petersburg on June 29 (and for which we are waiting for everyone who wants it!), We are telling interesting news:

We are announcing a competition for the "confrontation" of NeoQUEST-2017!

If you have interesting research on information security and you want to share them with the world - go to the site neoquest.ru, send a request through a special web form, and the organizers will contact you! For all questions feel free to write to support@neoquest.ru !