3

We get enough TLS traffic on HAProxy now that a single process isn't able to cope with the number of new TLS connections.

After seeing how StackOverflow uses a TLS proxy on processes 2-N that sends traffic back to process 1, I started experimenting with that, as the default behavior (each process acting independently) is less than ideal.

I've now effectively got a configuration like this:

global
  nbproc 3
  cpu-map 1 0 
  cpu-map 2 1 
  cpu-map 3 2

  stats bind-process all 

  stats socket /haproxy/proc1.sock mode 666 level admin process 1
  stats socket /haproxy/proc2.sock mode 666 level admin process 2 
  stats socket /haproxy/proc2.sock mode 666 level admin process 3 

defaults
  log global 
  mode http 
  option dontlognull

listen tlsproxy
  bind-process 2 3 
  bind 0.0.0.0:443 ssl crt /haproxy/example.com.pem 
  mode tcp
  option tcplog 

  server fe_www abns@fe_www.sock send-proxy 

frontend fe_www 
  bind-process 1 
  bind 0.0.0.0:80
  bind abns@fe_www.sock accept-proxy 

  default_backend be_www

backend be_www 
  bind-process 1 

  server www01 10.1.1.1:80

This works.

However, information about the TLS connection is not available to fe_www

This causes two problems:

ACLs that use TLS connection information (eg to redirect HTTP traffic to HTTPS) are now broken, as everything is now a non-secure connection.

HTTP Logging of information like the TLS Version, TLS Ciphers, etc is broken - that information is not carried across.

I've tried swapping the use of abstract named sockets for loopback IP bindings, but this doesn't help.

Is there a way to bring the TLS information across in the proxied connection?

  • Is there a reason you're using `mode tcp` in `listen tlsproxy`? – gxx Oct 06 '17 at 10:29
  • @gf_ hello again. Mainly because that's what the StackExchange guys were configuring it as. But even in http mode it doesn't pass the TLS info iirc –  Oct 07 '17 at 02:53

2 Answers2

1

You can use send-proxy-v2-ssl to send SSL related information but as discussed in this ML thread HAProxy does not implement yet the parsing of those information in the receiving part (accept-proxy).

The only solution here is as suggested by "gf_", you need to use mode http in the tlsproxy part and do all the ssl related actions (ACLs, redirects, logging) there.

Mo3m3n
  • 414
  • 2
  • 6
  • Hi, thanks for the answer... unfortunately doing this means I then either have two log entries (i.e one from the tlsproxy and one from the fe_www), or if I turn off logging on fe_www then I lose the information about the backend being used. I've also noticed that it doesn't pass across the TCP connection information either. –  Oct 11 '17 at 00:55
  • Additionally another issue is that I then cannot have ACLs that choose a backend based on TLS information either. –  Oct 11 '17 at 01:42
1

For those willing/able to wait for HAProxy 1.8 to come out, multithreading support using nbthread instead of nbproc looks like it will solve all of these issues.

Based on the linked blog post, it looks like this would be the correct version of the config to use for HAProxy 1.8 and later:

global
  nbthread 3

  stats bind-process all 

  stats socket /haproxy/proc.sock mode 666 level admin

defaults
  log global 
  mode http 
  option dontlognull


frontend fe_www 
  bind 0.0.0.0:80

  default_backend be_www

backend be_www 

  server www01 10.1.1.1:80