mTLS client certificate revocation vulnerability with TLS Session Resumption

An SSL/TLS session resumption can occur when a client reestablishes a connection with a server by using an existing SSL/TLS session ID, which allows for faster connection setup times compared to establishing a new session from scratch. This process is often used in high-latency networks or where minimizing latency is critical. However, this particular vulnerability was discovered due to the fact that when a client presents a certificate during an SSL/TLS handshake, Cloudflare stores the certificate chain on the TLS connection and checks the revocation status before passing it along for further processing (such as evaluating Firewall Rules). When sessions were resumed, code to store the client certificate chain in application data did not run, resulting in an empty certificate chain. This meant that Cloudflare was unable to check the revocation status when using session resumption, which could lead to a situation where traffic from revoked mTLS certificates is allowed through Firewall Rules. This issue only affected mutual TLS (mTLS) connections, where both client and server authenticate each other using SSL/TLS certificates. To address this vulnerability, Cloudflare initially disabled session resumption for all mTLS connections to the edge. Subsequently, a fix was developed that supports both session resumption and revocation by removing the requirement of depending on data stored within the TLS connection state. Instead, an API call is used to grant access to the leaf certificate in both session resumption and non-session resumption cases. This issue highlights the importance of proper implementation and testing of security features such as SSL/TLS revocation checking, especially when dealing with high-value targets or sensitive data. By quickly identifying and addressing this vulnerability, Cloudflare has taken steps to ensure the continued protection of its customers' data.