Support for Certificate Revocation in Istio Gateway

/ Jimmy Song

Recently, the Istio community is working on Issue 17763
, to add Istio support for certificate revocation, which is currently under development, see PR #42859 – OSCP Stapling
and OCSP Stapling for Istio Gateways
. This blog will introduce you to the way of certificate revocation and the progress of Istio’s solution.

Istio uses Envoy SDS to distribute certificates. There are two scenarios:

  • Distribute internal certificates for mTLS. In this case, it is necessary to verify whether the certificates of the client and server are revoked
  • Distribute the certificate of the external service to the service in the cluster to encrypt the communication outside the cluster. At this time, the service in the cluster is equivalent to the client, and only needs to verify whether the server certificate is revoked

This article discusses the second scenario, the certificate revocation of Istio Gateway, as shown in the following figure:

image

Diagram of certificate revocation for Istio Gateway

The CA controls the life of the certificate by setting the TTL. If the certificate is to be terminated early, the certificate can be revoked. There are two ways to revoke the certificate:

  1. Configure Certificate Revocation List (CRL)
  2. Online Certificate Status Protocol (OCSP)

CRL (Certificate Revocation List)

A CRL (Certificate Revocation List) is a mechanism for managing and verifying the validity of certificates. It contains a list of certificates that have been revoked, which is regularly updated by the issuing authority (CA). When a certificate-validating client (such as a browser) receives a certificate, it checks to see if the certificate is listed as revoked in the CRL, and if so, the certificate is considered invalid.

CRLs are usually stored on the servers of the authority (CA) and are publicly accessible via the Internet. A client (for example, a browser) that validates a certificate can download and check the CRL to determine if the certificate is valid. CRLs can be stored in a variety of formats (such as DER or PEM) and published via HTTP, LDAP, or other protocols for verification purposes.

CRL files are usually stored in binary form, not directly readable text files. However, tools such as OpenSSL can be used to convert to other formats such as PEM for easier reading. Here is an example CRL file named crl.pem , represented in PEM format:

 -----BEGIN X509 CRL-----  
MIIBtjCBqwIBATANBgkqhkiG9w0BAQUFADBBMQswCQYDVQQGEwJVUzERMA8GA1UE  
CBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMREwDwYDVQQKEwhNeSBDQTEQ  
MA4GA1UECxMHQ2VydGlmaWNhdGUxGDAWBgNVBAMTD01ZIEJ1c2luZXNzIENBMB4X  
DTA5MDUwMzE1MTQwMFoXDTEwMDUwMjE1MTQwMFqgLzAtMB8GA1UdIwQYMBaAFJ4f  
6Nz7Vuw/NcZXG0U8O6OZ9XB0MAsGA1UdDwQEAwIFoDAdBgNVHQ4EFgQUU6G9fjRK  
op+JU6vQPnnhxBxHtzUwDQYJKoZIhvcNAQEFBQADgYEAbYoLz7MnJ4ltIS+nCquG  
N/v+8rE00/N0pGzN/dCv/8t0W0tGTGr2zGRb0mv67MPOmWmHcZZq3sOxgEIp8T+O  
OJxDCD/xJN6hB0NgN/Z0+fX9hU6bL/6zhwUy/l51xddmSd5KKhJ7FmOh2Py5m9Au  
4fJh7w+OLyjKV7rz55WKjvY =  
-----END X509 CRL-----

Convert it to a readable format using OpenSSL:

 openssl crl -inform PEM -in crl.pem -noout -text

The output is:

 Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: /C=US/ST=New York/L=New York/O=My CA/OU=Certificate/CN=My Business CA Last Update: May 3 11:40:00 2009 GMT Next Update: May 2 11:40:00 2010 GMT Revoked Certificates: Serial Number: 1 (0x1) Revocation Date: May 3 11:40:00 2009 GMT

Note : Only one revoked certificate is saved in the list of this CRL file.

Although CRL is widely used, there are several disadvantages in using CRL files to revoke certificates:

  1. Timeliness : CRL files must be updated regularly, otherwise recently revoked certificates will not be recognized;
  2. Availability : If the CRL server cannot be reached, it cannot be verified that the certificate has been revoked;
  3. Efficiency : CRL files become larger and larger as the number of certificates increases, so the process of verifying certificates may slow down;
  4. Security : The CRL file itself also needs security protection, otherwise an attacker may tamper with the CRL to evade the restrictions on revoking certificates;

Therefore, there are now more efficient and secure certificate revocation mechanisms, such as OCSP (Online Certificate Status Protocol), which can verify the status of certificates in real time and do not need to store a list of all revoked certificates.

OCSP Stapling

OCSP Stapling (officially known as TLS Certificate Status Query Extension) is a TLS (Transport Layer Security) extension used to prove that the status of the certificate is valid. It allows servers to pre-retrieve certificate status information and “pin” that information into TLS certificates to reduce reliance on certificate authorities and improve the efficiency of certificate status verification. Can be used instead of OCSP to query the status of X.509 certificates. The server sends a pre-cached OCSP response during the TLS handshake, and the user only needs to verify the validity of the response without sending a request to the digital certificate certification authority (CA). See Wikipedia for details
.

OCSP only works with individual certificates, not lists. After the client receives the certificate, it communicates with the CA to check the revocation status. The response can be one of “good”, “revoked”, or “unknown”.

Although using OSCP Stapling saves the burden of maintaining CRL, it still has the following disadvantages:

  1. Additional resource overhead: The CA server needs to continuously respond to OCSP challenges to ensure the validity of the certificate, which will cause additional overhead on the server’s CPU and network bandwidth;
  2. Availability problem : If the OCSP server is unavailable, the client will not be able to obtain the validity information of the certificate;
  3. Security issues : If the OCSP response is tampered with or the server is insecure, the validity information of the certificate may be tampered with, thereby affecting security;
  4. Compatibility issues : OCSP Stapling is not a feature supported by all browsers, so additional compatibility on older browsers may be required.

The challenge with OCSP is that it places a significant burden on the CA, since each client needs to independently obtain the verification of the certificate. Overall, OCSP Stapling can improve the efficiency and security of certificate verification, but there are some issues that need to be considered. Therefore, many factors need to be considered comprehensively when adopting this technology.

Istio supports OSCP Stapling

Many web servers support OSCP Stapling, and the cloud-native edge proxy Envoy also supports this function. Envoy needs to be configured as follows:

  • Configure DownstreamTlsContext
    oscp_staple_policy in:
    • LENIENT_STAPLING : OCSP response is optional, this is the default
    • STRICT_STAPLING : The OCSP response is optional, but will be used if present and valid.
    • MUST_STAPLE : OCSP response is required
  • Configure TlsCertificate
    oscp_staple in oscp_staple , the response must be DER encoded and can only be provided by filename or inline_bytes . Responses may relate to only one certificate.

Currently, Envoy already supports OSCP Stapling, which acts as the data plane of Istio and the proxy in Istio Gateway. In theory, Istio can also support this function. However, Istio’s OSCP Stapling certificate revocation support is still in progress, see PR #42859 – OSCP Stapling
. The new progress of this function will be updated in this article, please stay tuned.

This article is transferred from https://jimmysong.io/blog/ocsp-stapling-for-istio-gateways/
This site is only for collection, and the copyright belongs to the original author.