Securiser apache 2

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Domaine Durcissement du chiffrement TLS/SSL sur Apache
Module mod_ssl
Directives clés SSLProtocol, SSLCipherSuite
Voir aussi Securiser apache · Modsecurity

Cette page couvre spécifiquement le durcissement du chiffrement TLS/SSL (choix des protocoles et suites de chiffrement) — pour le durcissement général d'Apache et de PHP (masquage de version, permissions, contrôle d'accès...), voir Securiser apache.

Le contenu source de cette page date de l'époque du guide Applied Crypto Hardening (bettercrypto.org, ~2015) : les recommandations de suites de chiffrement précises ci-dessous sont datées et conservées à titre de référence historique/pédagogique — voir la section « Recommandation actuelle » pour l'approche à privilégier aujourd'hui.

Concepts

Une négociation TLS combine plusieurs briques indépendantes, chacune ayant ses propres faiblesses possibles :

  • Échange de clé (key exchange) : établit un secret partagé entre client et serveur sans
 qu'un tiers à l'écoute puisse le déduire. Exemple : DHE, ECDHE.
  • Authentification : le client vérifie l'identité du serveur via son certificat.
 Exemple : RSA.
  • Chiffrement (cipher) : chiffre le flux de données. Exemple : AES256.
  • Code d'authentification de message (MAC) : garantit l'intégrité des messages (absence
 de modification en transit). Exemple : SHA-256.
  • AEAD (Authenticated Encryption with Associated Data) : combine chiffrement et
 authentification dans un seul mode opératoire de bloc. Exemple : AES256-GCM.

Suites à éviter

  • ADH (Anonymous Diffie-Hellman) — pas d'authentification du serveur.
  • Suites NULL — pas de chiffrement du tout.
  • Suites d'export (export key exchange) — chiffrement volontairement affaibli, héritage
 des restrictions à l'export américaines des années 1990, aujourd'hui triviales à casser.
  • Suites faibles (40/56 bits).
  • RC4 — reconnu cassable depuis 2013, interdit en TLS depuis la RFC 7465 (2015).
  • 3DES — 112 bits de sécurité effective, vulnérable à l'attaque Sweet32, à proscrire.

Forward secrecy

La forward secrecy (confidentialité persistante) garantit qu'une compromission ultérieure de la clé privée du serveur ne permet pas de déchiffrer les sessions passées enregistrées. Elle nécessite des suites ECDHE (ou DHE), qui négocient une clé de session éphémère à chaque connexion plutôt que de dériver directement la clé de la paire RSA du serveur.

Problèmes connus à mitiger (état de l'art ~2015)

  • Renégociation non sécurisée → désactiver la renégociation initiée par le client.
  • Compression TLS → à désactiver (attaque CRIME).
  • Fuite d'information via la compression HTTP → attaque BREACH, à considérer indépendamment de
 la compression TLS.
  • RC4 → à désactiver (cf. ci-dessus).
  • Attaque BEAST → concernait TLS 1.0, mitigée côté navigateurs modernes depuis longtemps.
  • HSTS (HTTP Strict Transport Security) → à déployer pour forcer le HTTPS côté navigateur.

Exemple de configuration (historique)

SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3
SSLCertificateFile /etc/ssl/certs/certificate.crt
SSLCertificateKeyFile /etc/ssl/certs/privatekey.key

Cet exemple visait TLS 1.2 avec forward secrecy et suites AES256/SHA-2 — compatible à l'époque avec Windows 7/8.1, OpenSSL ≥ 1.0.1e, Safari 6+/iOS 6.0.1+.

Recommandation actuelle

La liste de suites ci-dessus est obsolète : la quasi-totalité des protocoles/algorithmes qu'elle cherchait à exclure au cas par cas (SSLv2, SSLv3, RC4, 3DES, compression TLS) sont aujourd'hui simplement supprimés d'OpenSSL et des navigateurs modernes, rendant la plupart de ces exclusions manuelles inutiles. L'approche recommandée aujourd'hui :

  • Se limiter à TLS 1.2 et TLS 1.3 (SSLProtocol -all +TLSv1.2 +TLSv1.3),
 TLS 1.3 supprimant nativement la négociation de suites de chiffrement faibles.
 Generator], qui maintient à jour les recommandations par niveau de compatibilité
 (Modern / Intermediate / Old) plutôt que de recopier une liste de suites figée dans le
 temps.
  • Vérifier le résultat avec un scanner externe (type Qualys SSL Labs) plutôt que de se fier à
 une checklist statique.

Voir aussi