Mutual TLS - Skip client certificate validation

[haritzsaiz]

Description:

Is it possible to request a client certificate during the (mutual) TLS handshake that:

• If no certificate is presented, the requests is forwarded to the upstream services
• If given by the client, the certificate is not validated at all by the Gateway. Simply the certificate information is forwarded to the upstream services using XFCC headers.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
  name: enable-mtls
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: eg
  tls:
    maxVersion: "1.2"
    clientValidation:
      optional: true
      caCertificateRefs:
      - kind: "Secret"
        group: ""
        name: "my-ca-secret"
  headers:
    xForwardedClientCert:
      mode: AppendForward
      certDetailsToAdd: 
      - Chain

If I've understood the documentation correctly, it's only possible configuring optional mutual TLS, that is:

• If no certificate is presented, the request is forwarded to the upstream services
• If given by the client, the certificate is ALWAYS validated at all by the Gateway using the given caCertificateRefs .

In fact, I've seen that if caCertificateRefs is not correcly specified, theCertificate Request is not present in the TLS handshake. Would it be possible perphaps if caCertificateRefs is null / not set, that simply no client certificate validation is performed?

[arkodg]

caCertificateRefs not being set can be perceived as a misconfiguration, and not intent, in the future we plan on return 500 for these cases #4153

The optional setting should help you support both cases

[haritzsaiz]

For sure I need to set optional to true, but I also need to define caCertificateRefs with a valid secret so that the server will send the client certificate request in the handshake, but it will then add the Distinguished Name of the CA certificate in the certificate request.

The TLS specification states the following (https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.4):

certificate_authorities

    A list of the distinguished names [[X501](https://datatracker.ietf.org/doc/html/rfc5246#ref-X501)] of acceptable
    certificate_authorities, represented in DER-encoded format.  These
    distinguished names may specify a desired distinguished name for a
    root CA or for a subordinate CA; thus, this message can be used to
    describe known roots as well as a desired authorization space.  If
    the certificate_authorities list is empty, then the client MAY
    send any certificate of the appropriate ClientCertificateType,
    unless there is some external arrangement to the contrary.

I'm interested in this part of the specification because some HTTP clients (or other protocols that support TLS) refuse sending a client certificate because they check against the Distinguished Names provided by the handshake.

If the certificate_authorities list is empty, then the client MAYsend any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary.

How can achieve the server sending the Certificate Request in the TLS handsahak with an empty list of Distinguished Names?

I was able to do this with Envoy right away, so I think it should be possible with Envoy Gateway.

[arkodg]

@haritzsaiz which field in envoy are you referring to ?

[haritzsaiz]

@arkodg Hi, forgot to reply. With this configuration, you achieve that (not defining the trusted_ca param):

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
    common_tls_context:
      tls_certificates:
        - certificate_chain: { filename: "/certs/bundle.crt" }
          private_key: { filename: "/certs/downstream.key" }
      validation_context:
        trust_chain_verification: ACCEPT_UNTRUSTED
          # trusted_ca: /certs/validation-ca.crt

[haritzsaiz]

Hi @arkodg could you take a look at this commit? I've tried to implement what's missing, but I'm not sure it's implemented correctly. Could you have a look at it? (Don't want to open a PR if you dont agree with the implementation) a8ba097

[arkodg]

reopening this issue, to make a decision on the definition of optional, and should it also accommodate untrusted certs / certs thats fail validation
ptal @envoyproxy/gateway-maintainers