mTLS support without using sni

[ndbemmanuel]

Is it possible to add support to have mutual TLS authentication without having SNI support. We have deployed devices that need to have mutual TLS authentication and doesn’t support SNI. We did get a somewhat working solution by having the following config :

bind-https: ":443 ssl crt /var/lib/haproxy/crt/sw0081-dev_sw0081-srv.pem.pem ca-file /var/lib/haproxy/cacerts/ca_sw0081-dev_sw0081-ca.pem.pem verify optional"

config-frontend
        http-request set-var(req.hostbackend) var(req.base),map_dir(/etc/haproxy/maps/_front_https_sni__prefix.map) if !{ var(req.hostbackend) -m found }
        acl tls-has-invalid-crt ssl_c_ca_err gt 0
        acl tls-has-invalid-crt ssl_c_err gt 0
        acl tls-need-crt hdr(host) -i -m str -f /etc/haproxy/maps/_front_tls_needcrt__exact.list
        acl tls-check-crt hdr(host)  -i -m str -f /etc/haproxy/maps/_front_tls_auth__exact.list
        http-request set-var(req.tls_invalidcrt_redir) str(_internal) if tls-has-invalid-crt tls-check-crt

In sort, it’s a copy the SNI config but applied to the host header field

But that solution has some problems:

• The container will crash before the required ingress rules are created with a file not found
• Modification of the ingress rules like adding a path prefix rule will break the fronted
• It is applied both to HTTP and HTTPS front end
• Depends of the internal working of the load balancer

Our suggestion:

• Have an option to ingress annotation would tell that the endpoint needs to be accessible using only the host header field.
  • Set the HTTPS binding to have verify optional
  • Configure the front end to validate both with and without the SNI
  • Configure the front end to find the correct back end with and without SNI

[jcmoraisjr]

Iirc the details of this functionality, the SNI extension has three roles:

• choose a proper server certificate to the client;
• defines if mTLS should be used and use a proper CA bundle;
• if a client certificate is provided, guarantee that the client was properly authenticated before forward the request.

The first two options is a matter of configuring mTLS in the default backend, but HAProxy Ingress currently doesn't do this and I'll take care. The third and last option compares SNI and Host header if a certificate was provided, this behavior can be changed on behalf of a less secure deployment, which isn't a problem at all if all of your clients use the same CA bundle.

Is this approach useful in your use case?

[ndbemmanuel]

Yes, that would be useful.
We only have one host name that requires to support non-sni configuration It is also currently the only host name that currently require mTLS. It would cover actual use cases and allow to set the configuration without knowing the internal working of the haproxy.cfg configuration.

So, It will cover these required use cases:

• Client not supporting SNI connecting to the host requiring mTLS

  • Connect and be authenticated with default front-end config
  • Host name should be validated to be allowed to use non-SNI configuration (that one would be an improvement from my workaround and would need an annotation to ingress)

• Client not supporting SNI without TLS

  • Access must be granted to host not requiring mTLS
  • Access must be denied to host requiring mTLS

• Client with SNI (with or without mTLS)

  • Continue to work as it is currently
  • Client using SNI with hostname allowed non SNI mTLS must work (Would allow upgraded devices that now support SNI to continue to work)

Non required use case but may be useful for someone else and is not covered by the solution:

• Client not supporting SNI connecting to host requiring mTLS
  • Using a consolidated CA bundle and validating ssl_c_i_dn to allow only the correct host bundle
  • It may have side effects in the case of clients having client certificates for multiple host when the browser try to choose the correct one. But modern browser should support SNI
  • Useful only for devices where the configuration is explicitly set.

[mogoman]

hi jcmoraisjr

I am working on vertifying my cluster with a large provider and it seems they don't support SNI - it was difficult to debug that until I finally did curl https://<ip address> and got the same error in my logs vs the query from the vendor:

2024-09-23T17:42:51.159898544Z 2024-09-23T17:42:51+00:00 127.0.0.1 1 2024-09-23T17:42:51.159750+00:00 - ingress 4697 - - 10.42.6.110:44780 [23/Sep/2024:17:42:51.124] _front_https/1: SSL handshake failure

mTLS with the fqdn works fine in my tests, but it seems the remote server at the vendor doesn't support this; they are resolving and then using the IP.

I'm happy to create a dedicated ingress controller or even cluster, if this is possible?

Thanks