envoyproxy/envoy

Extend TrustChainVerification to support SSL_VERIFY_NONE mode

Open

#30,091 创建于 2023年10月11日

在 GitHub 查看
 (12 评论) (0 反应) (0 负责人)C++ (5,373 fork)batch import
area/tlsenhancementhelp wanted

仓库指标

Star
 (27,997 star)
PR 合并指标
 (平均合并 8天) (30 天内合并 378 个 PR)

描述

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).

贡献者指南