J'ai lu sur divers forums concernant la vulnérabilité POODLE
dans SSLv3
. Il est recommandé de désactiver SSLv3
et de prendre en charge TLS_FALLBACK_SCSV
sur les serveurs.
Comment activer le support de TLS_FALLBACK_SCSV
sur Apache2.2
?
Mettez à niveau la dernière version d’openssl, qui prend automatiquement en charge TLS-FALLBACK-SCSV . Apache utilisera cela.
De https://www.openssl.org/news/secadv_20141015.txt :
OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc.
Debian et d’autres distributions déploient des backports de la mise à jour TLS-FALLBACK-SCSV sur OpenSSL.
Redémarrez votre Apache après la mise à jour.
SSL Labs vérifiera si vous supportez TLS_FALLBACK_SCSV
.
Remarquez comment https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96&hideResults=on notes "TLS_FALLBACK_SCSV supporté"
Autant que je sache, ce n'est pas une configuration dans Apache, mais un comportement d'OpenSSL.
OpenSSL a ajouté la prise en charge de TLS_FALLBACK_SCSV pour autoriser les applications bloquer la possibilité pour un attaquant de MITM de forcer un protocole rétrograder.
https://www.openssl.org/news/secadv_20141015.txt
Sur Debian, vous pouvez mettre à jour openssl sans mettre à jour libssl, vous voulez vraiment que libssl soit mis à jour. Apache utilise libssl.
Mettez à niveau le dernier package OpenSSL qui implémente TLS_FALLBACK_SCSV. Puis, dans votre configuration Apache, désactivez également SSLv3.
SSLProtocol all -SSLv2 -SSLv3
Cette réponse sur le site de pile 'askubuntu' donne plus de détails et explique comment configurer un ensemble de serveurs différents pour cela.
Il ne devrait pas être nécessaire de faire les deux; TLS_FALLBACK_SCSV est un mécanisme permettant d'empêcher les attaques par rétrogradation, mais si votre serveur n'autorise pas les connexions SSLv3 (ou v2), il n'est pas nécessaire (car ces connexions dégradées ne fonctionneraient pas).
Éditer (pour intégrer les commentaires): Techniquement, TLS_FALLBACK_SCSV est toujours utile avec SSL désactivé, car il permet d’éviter que la connexion ne soit rétrogradée à TLS <1.2. Mais cela n’est pas nécessaire pour se défendre contre POODLE, car le vulnérable SSLv3 est désactivé.
TLS_FALLBACK_SCSV est utile contre POODLE uniquement si vous devez prendre en charge les clients SSLv3 (versions vraiment anciennes IE ou quelque chose du genre). Ces clients seront toujours vulnérables à l'attaque, mais les clients modernes prenant en charge cette option seraient protégés contre l'attaque par rétrogradation.
Placez la ligne suivante dans votre fichier de configuration ou remplacez toute ligne existante commençant par SSLProtocol: SSLProtocol All -SSLv2 -SSLv3
Puis lancez: $ Sudo Apache2ctl configtest && Sudo service Apache2 restart
Vous pouvez tester exécuter la commande $ openssl s_client -connect <Host>:<port> -ssl3
Je peux confirmer qu'il n'est pas nécessaire de changer rien sur Apache (du moins pour Ubuntu 14.04). J'ai redémarré Apache après la mise à jour de openssl et TLS_FALLBACK_SCSV
fonctionne.
TLS_EMPTY_RENEGOTIATION_INFO_SCSV est le mot magique . Pour plus de détails, reportez-vous à http://www.exploresecurity.com , voici ce qu'il dit:
TLS_FALLBACK_SCSV est une fausse suite de chiffrement publiée dans le client Bonjour, qui commence la négociation SSL/TLS. SCSV signifie “Signalisation Valeur de la suite de chiffrement ». L'idée d'utiliser une suite de chiffrement comme signal est pas nouveau: TLS_EMPTY_RENEGOTIATION_INFO_SCSV est un moyen que les clients peuvent annonce qu'ils soutiennent la renégociation sécurisée (adressage CVE-2009-3555)
Donc, enfin, pour un projet Spring-boot avec Apache Server intégré, la configuration devrait ressembler à ceci:
server.ssl.enabled-protocols=TLSvx,TLSvx.y....
server.ssl.protocol=TLS
server.ssl.ciphers=TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_............TLS_EMPTY_RENAGOTIATION_INFO_SCSV
server.server-header="Willi Wonka!"
PS - Pour voir toutes les configurations/propriétés de Spring-boot, veuillez visiter ceci: https://docs.spring.io