envoyproxy/envoy

Extend TrustChainVerification to support SSL_VERIFY_NONE mode

Open

#30 091 ouverte le 11 oct. 2023

Voir sur GitHub
 (12 commentaires) (0 réactions) (0 assignés)C++ (5 373 forks)batch import
area/tlsenhancementhelp wanted

Métriques du dépôt

Stars
 (27 997 stars)
Métriques de merge PR
 (Merge moyen 8j) (378 PRs mergées en 30 j)

Description

Title: Add a trust chain mode that accepts a client certificate if one is presented but does not request it.

Description: The scenario is that I'm terminating TLS in Envoy but for legacy reasons doing authorization in the backend. One of the authorization formats is mTLS, so I need to extract the client certificate and forward it on to the backend. The problem is the endpoint is shared and not all requests use the same authorizatio, this is a business rule and (currently) isn't something that can be known when setting the Envoy configuration.

Our initial approach was to use ACCEPT_UNTRUSTED. This allowed us to terminate TLS at Envoy and still extract the client certificate which we passed over XFF headers to the backend. This works fine except ACCEPT_UNTRUSTED sets SSL_VERIFY_PEER: https://github.com/envoyproxy/envoy/blob/main/source/extensions/transport_sockets/tls/cert_validator/default_validator.cc#L65

"SSL_VERIFY_PEER...On a server it requests a client certificate and makes errors fatal. However, anonymous clients are still allowed." https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_VERIFY_PEER

It's the requesting a client cert that's the issue. We need to accept one if one is presented but not request one - this is causing unexpected behaviour (browsers are prompting for cert selection). What would be ideal is to accept a certificate if one is presented but not request it - which based on the description seems to be what SSL_VERIFY_NONE does (though I've never used this so I'm basing this purely on the one line description and my own confirmation bias).

Guide contributeur