HAProxy community

SSL Renegotiation with SSL backend


#1

Hi all,
I have a problem with HAProxy configuration. Because my HAProxy isn’t in the same data center as my web server, I have working configuration to connect www-backend to my webserver’s HTTPS port. It all works just fine.

Well… Almost.

Today I tried to upload a file (250 kB) using a <form> and I got HTTP 413 Request entity too large. Checking the Apache server log, I’ve found two messages:

AH02018: request body exceeds maximum size (131072) for SSL buffer, referer: https://my.website.com/page

and

AH02257: could not buffer message body to allow SSL renegotiation to proceed, referer: https://my.website.com/page

I’ve done some investigation, found couple of old articles at stackoverflow, all recommending setting Apache’s SSLRenegBufferSize to something bigger. I don’t want to go that way.

I’ve tried to upload the file directly to webserver (bypassing HAProxy) and it works just fine.

Changing my server definition in www-backend from:

server server1 1.2.3.4:443 check ssl verify none

to

server server1 1.2.3.4:80 check

resolved the issue and I was able to upload the file while being connected through HAProxy.

However, I don’t like the possibility of a MITM attack between HAProxy and my www servers (however unlikely it is).

Is there a way to prevent the SSL renegotiation when user submits the form and uploads the file to the server?

My haproxy.cfg:

global
  log /dev/log local0 notice
  chroot /var/lib/haproxy

  stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
  stats timeout 30s

  user haproxy
  group haproxy
  daemon

  tune.ssl.default-dh-param 2048
  ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
  ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
  ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
  ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

defaults
  log global
  mode http

  option dontlognull
  option forwardfor
  option redispatch

  timeout connect 15000
  timeout client 50000
  timeout server 50000

frontend http-in
  bind :80
  bind *:443 ssl crt /etc/haproxy/certificate.pem

  option forwardfor
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Port %[dst_port]

  # Redirect if HTTPS is *not* used
  redirect scheme https code 301 if !{ ssl_fc }

  # Test URI to see if its a letsencrypt request
  acl letsencrypt-acl path_beg /.well-known/acme-challenge/
  use_backend letsencrypt-backend if letsencrypt-acl

  default_backend www-backend

backend www-backend
  stick-table type ip size 200k expire 30m
  stick on src
  default-server inter 1s

  balance roundrobin

  server server1 1.2.3.4:80 check
  #server server1 1.2.3.4:443 check ssl verify none

Any help is much appreciated!


#2

Haproxy does not trigger any renegotiation, your Apache configuration does.

Please read:
https://bz.apache.org/bugzilla/show_bug.cgi?id=39243