Hi Matt,
On Sat, 3 Nov 2018 at 20:32, Matthew Sanders <[email protected]> wrote: > I ran into a few work arounds to the problem, but I fear there is a few > performance considerations with these > approaches and felt there must be a more native way HAProxy could help with > this situation. > > In this blog post: > https://www.loadbalancer.org/blog/client-certificate-authentication-with-haproxy/ > > The author references an answer from another community member who suggests the > first approach here: > https://discourse.haproxy.org/t/how-to-set-ssl-verify-client-for-specific-domain-name/1489/3 > > The second (but pretty much the same) approach I found was on Stack Exchange > here: > https://serverfault.com/a/663923 > > I prefer the second approach as it doesn't use the abstract namespace which > as the documentation points out are not 'rebindable' with multi-process > soft-restart. Right, whatever works best for you. IP loopback through 127/8, unix domain sockets or abstract namespace have each it's own advantages and disadvantages. I'd assume that unix domain sockets would be ideal for your use-case (just use the correct user/group settings if you drop privileges). > My concerns are: > > 1. This relies on SNI which will add some delay up front 'tcp-request > inspect-delay 5s'. This happens even if I plan to terminate the TLS > connection at HAProxy. No, that's not the case. 5 seconds is the time when haproxy gives up waiting for a TLS client_hello on this connection, but it doesn't mean you suffer from this delay for regular connections. The moment the hello is there, the hello is analyzed and forwarded. > 2. Then we route to a backend internally to then route to another loopback > causing some more minor delay. > 3. The internal routing would then increase the unix open file count per > request > > Is there any other solutions that may avoid these issues, or am I needlessly > worried about it in the first place? Whether this is something that critically affects your product or not is something you'll have to benchmark. If you are netflix and trying to squeeze 100gbit/s out of a single edge-cluster, those things will matter. If you are forwarding a few hundred mbit/s of traffic and a few thousand concurrent connections with any half-decent HW, it probably doesn't. > Can HAProxy be improved to more natively support such a workflow? Actually I believe we already have a way. You can set TLS options per certificate in Haproxy 1.8, including the verify option. You can do that with crt-list: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt-list So instead of referring to a certificate you just refer to a crt-list, which then contains a list of certificates with specific configurations: frontend httpsin bind :443 ssl crt-list /etc/haproxy/crtlist $ cat /etc/haproxy/crtlist www.example.org [verify none] admin.example.org [verify required] Of course that means using dedicated certificates (and also, they should not overlap - so no wildcard certificate on the main site and a more specific one for admin area - otherwise you the browser may use the wildcard cert connection for both). Regards, Lukas
