HAProxy et SSL : terminaison TLS, SSL passthrough et sécurisation

1. Terminaison SSL (Offloading) #

HAProxy gère le déchiffrement pour soulager les serveurs web.

Configuration du certificat #

C'est la méthode la plus courante. HAProxy possède le certificat SSL et communique en HTTP clair avec les backends sur un réseau privé sécurisé.

frontend https-in
    bind *:443 ssl crt /etc/ssl/certs/mon-site.pem
    default_backend app_servers

Note : Le fichier .pem doit contenir le certificat et la clé privée.

2. SSL Pass-through #

Transmettre le flux chiffré sans inspection.

Utilisation du mode TCP #

Si vous ne voulez pas que HAProxy déchiffre le trafic (pour des raisons de confidentialité totale), utilisez le mode TCP (Layer 4).

frontend stream-in
    mode tcp
    bind *:443
    default_backend secure_web

3. Forcer le HTTPS #

Rediriger automatiquement les utilisateurs vers le port sécurisé.

Redirection HTTP vers HTTPS #

Une règle simple dans le frontend HTTP suffit.

frontend http-in
    bind *:80
    http-request redirect scheme https unless { ssl_fc }

Conclusion #

Un point central pour la sécurité.

Performance et Sécurité #

En centralisant le SSL, vous simplifiez la gestion des certificats (ex: Let's Encrypt) et optimisez les performances de vos serveurs d'application.

Mise en pratique : certificats et configuration complète #

Générer un certificat, configurer et tester.

Préparer le certificat #

HAProxy attend un fichier PEM unique contenant la chaîne de certificats puis la clé privée.

# Certificat auto-signé pour tester
openssl req -x509 -newkey rsa:4096 -nodes -days 365 -keyout app.key -out app.crt -subj "/CN=app.exemple.fr"
cat app.crt app.key > /etc/haproxy/certs/app.pem && chmod 600 /etc/haproxy/certs/app.pem

# Vérifier le contenu et la date d'expiration
openssl x509 -in /etc/haproxy/certs/app.pem -noout -subject -enddate

Frontend HTTPS et redirection #

global
    ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

frontend https_in
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1     # un répertoire = plusieurs certificats (SNI)
    http-request redirect scheme https unless { ssl_fc }
    http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains"
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend app

backend app
    balance roundrobin
    server web1 10.0.0.11:8080 check
    server web2 10.0.0.12:8080 check

Tester et diagnostiquer #

haproxy -c -f /etc/haproxy/haproxy.cfg && sudo systemctl reload haproxy
curl -vkI https://app.exemple.fr 2>&1 | grep -E "SSL|TLS|HTTP/"
openssl s_client -connect app.exemple.fr:443 -servername app.exemple.fr </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer
nmap --script ssl-enum-ciphers -p 443 app.exemple.fr          # lister les suites acceptées
echo "show ssl cert" | sudo socat stdio /var/run/haproxy.sock    # certificats chargés (Runtime API)

Bonne Pratique : Automatisez le renouvellement avec ACME (voir l'article ACME) et rechargez HAProxy sans coupure avec systemctl reload haproxy ou la commande Runtime set ssl cert.

SSL passthrough #

Laisser le chiffrement aux backends.

Configuration #

En SSL passthrough, HAProxy ne déchiffre pas : il travaille en mode TCP et route selon le nom demandé dans le message TLS (SNI). Les backends gardent leurs certificats ; HAProxy ne voit ni URL ni en-têtes.

frontend tls_in
    bind :443
    mode tcp
    tcp-request inspect-delay 5s
    tcp-request content accept if { req.ssl_hello_type 1 }
    use_backend app_tls if { req.ssl_sni -i app.example.com }
    default_backend web_tls

backend app_tls
    mode tcp
    server app1 10.0.0.11:443 check