LDAP connections that use TLS can fail with "mismatching" SNI/hostname verification settings

[michaelklishin]

Modern Erlang versions automatically enable SNI/hostname verification. If target servers use wildcard x.509 certificates,
then Erlang's TLS library requires the hostname check to be customized, which is not currently possible using a static term config (advanced.config).

So we need to provide a configuration setting that would support a few cases:

• Wildcard certificates
• Exact matching
• Disabling hostname verification entirely (not to be confused with disabling peer verification, which actually affects security meaningfully and can already be done)

[patcable]

👋 thanks for making this!

From a security perspective, I would say that hostname validation has some amount of meaningful (but low) security value, right - making sure the other end of the connection is presenting the certificate we expect it would, based on the connection parameters we've set is a good thing in addition to ensuring the trust chain is correct. It's a small hedge against DNS being pointed at the wrong thing, too. I think this might matter a slightly more in environments that use a public CA vs an internal PKI, though.

From an operations perspective (this is more important, imo): If an LDAP server sits behind a load balancer - some LBs require the SNI header to know what certificate to present for RMQ to validate in the first place. Generally i've seen this on large CDNs that need to provide that kind of service, but is fairly easy to implement with something like HAproxy - it will use the SNI information to then present a certificate for validation (fairly easy to set up too - https://stuff-things.net/2016/11/30/haproxy-sni/). I could imagine this being an issue for folks using a SaaS LDAP provider.

Given that SNI was introduced back in 2010, I think that it'd be safe to use SNI on every TLS LDAP connection. And, since folks generally expect wildcard validation to work (and wildcards have been around longer), that seems safe too - at least in the LDAP module. Perhaps both of these things could eventually make their way into RMQ proper, though that feels like it would need more coordinated effort to determine safety there, and I'm pretty unqualified to speak to that.

On wildcards, adding in {customize_hostname_check, [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]} into any TLS options that are specified in rabbitmq_auth_backend_ldap.ssl_options. would do the trick. As I understand it, one can't just toss this in their advanced config since it references an anonymous function.

On SNI:

1. Less ideal: could just document that it the server_name_indicator value needs to be set in rabbitmq_auth_backend_ldap.ssl_options if using any kind of TLS. This sparks a little less joy, but at least it's a findable answer.
2. More ideal, but I imagine more time to complete: Auto populate the server_name_indicator field based on the host you're connecting to. I'm not sure how this would work with connection pools, but this is my first time looking at Erlang source, so I suspect folks who know more than me could speak to that.

Thanks for taking the time to talk through this on the RMQ Community Slack - the ejabberd issue you found was super helpful for my initial (unrelated) server configuration issue 👍

[mikeries]

I was struggling with an issue related to this. I wanted to encrypt communication between nodes in a cluster, but did not want to create key-pairs for each node. Adding the {customize_hostname_check, [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]} to the inter_node_tls.config file didn't work. I eventually found the thread on slack that referenced this issue and saw the {server_name_indication,disable} solution that Patrick Cable posted. That did the trick!