-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Bonjour à tous,
Nous nous sommes mis en tête d'améliorer notre support SSL sur nos vieilles applications chez mon client. L'histoire commence par un audit sécu bien sûr en passant par un dette technique conséquente. (on parle de Oracle Weblogic Portal sur de la RedHat 5 qui papote avec du Mainframe). Bref, dans le tas, on a des trucs simples comme de l'apache ou du haproxy. Nous avons manipulé le configurateur de Mozilla plutôt bien fait a priori. https://mozilla.github.io/server-side-tls/ssl-config-generator/
La configuration générée semble correspondre à notre besoin (exemple, supporté de IE6 sous Windows XP à Chrome sous Windows 10). Comprendre les homologations sont satisfaisantes. Mais ça ressemble un peu à de la magie ce "tu copies et ça marche". Même si en effet croiser toutes les ciphers pour n'en retenir que quelques unes a déjà pris pas mal de temps à la main.
Cela nous amène à une question philosophique.
Vaut-il mieux lister toutes les ciphers acceptés et refusés (comme le fait le lien ci-dessus) ou à l'inverse lister le "max" de ce qu'on veut et dégager tout ce que l'on veut explicitement refuser (!null, !rc4, ....) tout en laissant les options par défaut d'openssl décider de ce qu'il est bon de faire.
Comment faites vous habituellement ? Et si vous avez des pointeurs sur le sujet ça me dit bien aussi.
Qu'on s'entende bien, je ne cherche pas la plus belle CipherSuite du moment mas plutôt la bonne façon d'aborder le sujet.
Quelques liens connexes pour la culture : https://www.howsmyssl.com/s/about.html#insecure-cipher-suites
https://tls.imirhil.fr/ciphers
Merci,
Bonsoir,
Le 19/03/2019 à 00:03, daffyduke@lautre.net a écrit :
Bonjour à tous,
Nous nous sommes mis en tête d'améliorer notre support SSL sur nos vieilles applications chez mon client. L'histoire commence par un audit sécu bien sûr en passant par un dette technique conséquente. (on parle de Oracle Weblogic Portal sur de la RedHat 5 qui papote avec du Mainframe). Bref, dans le tas, on a des trucs simples comme de l'apache ou du haproxy. Nous avons manipulé le configurateur de Mozilla plutôt bien fait a priori. https://mozilla.github.io/server-side-tls/ssl-config-generator/
La configuration générée semble correspondre à notre besoin (exemple, supporté de IE6 sous Windows XP à Chrome sous Windows 10). Comprendre les homologations sont satisfaisantes. Mais ça ressemble un peu à de la magie ce "tu copies et ça marche". Même si en effet croiser toutes les ciphers pour n'en retenir que quelques unes a déjà pris pas mal de temps à la main.
Cela nous amène à une question philosophique.
Vaut-il mieux lister toutes les ciphers acceptés et refusés (comme le fait le lien ci-dessus) ou à l'inverse lister le "max" de ce qu'on veut et dégager tout ce que l'on veut explicitement refuser (!null, !rc4, ....) tout en laissant les options par défaut d'openssl décider de ce qu'il est bon de faire.
Comment faites vous habituellement ? Et si vous avez des pointeurs sur le sujet ça me dit bien aussi.
Personnellement, je me contente de lister uniquement ce que j’accepte (dans mon cas ECDHE+CHACHA20:ECDHE+AESGCM:ECDHE+AESCCM), mais ça n’est pas forcément le plus simple selon ce que tu veux supporter. De mon côté c’est assez simple car la liste est courte.
Bonjour,
Le 19/03/2019 à 00:10, Bruno Pagani a écrit :
Vaut-il mieux lister toutes les ciphers acceptés et refusés (comme le fait le lien ci-dessus) ou à l'inverse lister le "max" de ce qu'on veut et dégager tout ce que l'on veut explicitement refuser (!null, !rc4, ....) tout en laissant les options par défaut d'openssl décider de ce qu'il est bon de faire.
Plutôt ça effectivement, ce qui donne à ce jour :
HIGH:!ADH:!AECDH:!MD5:!SHA:!RC4:!3DES
Cdt,
Hello,
Généralement, à taf-1 on avait 2 cas : - Système sécurisé pour administrations => Préco de l'ANSSI/BSI => pas le choix on applique la CS donnée par l'autorité. - Grand public => on désactive les protocoles les plus pourris (SSLv* et TLSv1 voire interdire aussi le TLSv1.1 si on fait du SNI), ensuite on désactive les algos évidents (!eNULL, !aNULL, !LOW, !SHA). Ensuite on recroise avec les précos officielles et les navigateurs supportés.
Pour du IE6, tu dois obligatoirement garder le TLSv1.0, les OS ne supportant que TLSv1.0 dans les version supportant IE6.
Si tu utilises un reverse proxy devant tu vas peut être devoir jouer avec les directives pour affaiblir les CS et protocoles possibles vers ton serveur derrière. Par exemple si ton serveur est en SSLv3 et que ton RP est un httpd >2.4.16, le SSLv3 est désactivé par défaut, il va falloir le réactiver.
Jonathan
Le mar. 19 mars 2019 à 11:43, Jérôme BERTHIER via FRsAG frsag@frsag.org a écrit :
Bonjour,
Le 19/03/2019 à 00:10, Bruno Pagani a écrit :
Vaut-il mieux lister toutes les ciphers acceptés et refusés (comme le
fait
le lien ci-dessus) ou à l'inverse lister le "max" de ce qu'on veut et dégager tout ce que l'on veut explicitement refuser (!null, !rc4, ....) tout en laissant les options par défaut d'openssl décider de ce qu'il est bon de faire.
Plutôt ça effectivement, ce qui donne à ce jour :
HIGH:!ADH:!AECDH:!MD5:!SHA:!RC4:!3DES
Cdt,
-- Jérôme BERTHIER
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Le Mon, 18 Mar 2019 16:03:39 -0700 daffyduke@lautre.net a écrit:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Bonjour à tous,
Nous nous sommes mis en tête d'améliorer notre support SSL sur nos vieilles applications chez mon client. L'histoire commence par un audit sécu bien sûr en passant par un dette technique conséquente. (on parle de Oracle Weblogic Portal sur de la RedHat 5 qui papote avec du Mainframe). Bref, dans le tas, on a des trucs simples comme de l'apache ou du haproxy. Nous avons manipulé le configurateur de Mozilla plutôt bien fait a priori. https://mozilla.github.io/server-side-tls/ssl-config-generator/
La configuration générée semble correspondre à notre besoin (exemple, supporté de IE6 sous Windows XP à Chrome sous Windows 10). Comprendre les homologations sont satisfaisantes. Mais ça ressemble un peu à de la magie ce "tu copies et ça marche". Même si en effet croiser toutes les ciphers pour n'en retenir que quelques unes a déjà pris pas mal de temps à la main.
Cela nous amène à une question philosophique.
Vaut-il mieux lister toutes les ciphers acceptés et refusés (comme le fait le lien ci-dessus) ou à l'inverse lister le "max" de ce qu'on veut et dégager tout ce que l'on veut explicitement refuser (!null, !rc4, ....) tout en laissant les options par défaut d'openssl décider de ce qu'il est bon de faire.
Comment faites vous habituellement ? Et si vous avez des pointeurs sur le sujet ça me dit bien aussi.
Qu'on s'entende bien, je ne cherche pas la plus belle CipherSuite du moment mas plutôt la bonne façon d'aborder le sujet.
Quelques liens connexes pour la culture : https://www.howsmyssl.com/s/about.html#insecure-cipher-suites
https://tls.imirhil.fr/ciphers
Merci, -----BEGIN PGP SIGNATURE----- Version: FlowCrypt 6.6.8 Gmail Encryption Comment: Seamlessly send and receive encrypted email
wkYEAREIAAYFAlyQI8oACgkQRjQjk2P2DCzScACgoh1A5PO5NhTCiX/Zzg90 No40LtEAoJXJCBuZHsD4MUiUS/Fw7xg/APOl =f2v3 -----END PGP SIGNATURE----- _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
T'as linké l'outil d'Aeris, je te link son article : https://blog.imirhil.fr/2015/09/02/cryptcheck-verifiez-implementations-tls.h...
D'après Aeris lui-même, les recommandations de l'article sont toujours d'actualité.
Personnellement, ça donne ECDHE+CHACHA20:ECDHE+AESGCM en HTTPS (HAProxy) et ECDHE+CHACHA20:ECDHE+AES en SMTP (Postfix). Le seconde est celle « recommandée » (enfin, ECDHE+AES suffit, mais autant supporter mieux). Elle supporte quasiment tout, tout en étant totalement sécurisée. Après si tu veux de l'IE sur XP, faudra ajouter le support de quelques trucs plus anciens, à la main à partir de la liste de ciphers que tu as donnée de préférence. Ou réfléchir pour s'en débarrasser rapidement.
Breizh.
mardi 19 mars 2019, 00:28:08 CET Breizh wrote:
Bonjour,
T'as linké l'outil d'Aeris, je te link son article : https://blog.imirhil.fr/2015/09/02/cryptcheck-verifiez-implementations-tls.h...
D'après Aeris lui-même, les recommandations de l'article sont toujours d'actualité.
Personnellement, ça donne ECDHE+CHACHA20:ECDHE+AESGCM en HTTPS (HAProxy) et ECDHE+CHACHA20:ECDHE+AES en SMTP (Postfix). Le seconde est celle « recommandée » (enfin, ECDHE+AES suffit, mais autant supporter mieux). Elle supporte quasiment tout, tout en étant totalement sécurisée. Après si tu veux de l'IE sur XP, faudra ajouter le support de quelques trucs plus anciens, à la main à partir de la liste de ciphers que tu as donnée de préférence. Ou réfléchir pour s'en débarrasser rapidement.
Breizh.
Vu que ça cause Cryptcheck, je me permets d’évoquer l'outil que j'ai fait avec un collègue pour générer un dashboard des notes cryptcheck de nos sites : https://framagit.org/framasoft/cryptcheck-dashboard/
C'est à utiliser dans GitlabCI et ça pousse dans des Gitlab pages, mais ça serait pas très compliqué à modifier pour un autre setup.
Ça vérifie aussi la présence des enregistrements A et AAAA des domaines testés (vu que chez Framasoft, on est tout en double stack IPv4/IPv6, le seul truc qui pouvait empêcher l'usage d'IPv6, c'était l'oubli du AAAA).
Vous pouvez voir le résultat sur https://framasoft.frama.io/cryptcheck-dashboard/. On n'est pas à 100% de A+ à cause : - du démon gitlab pages qui permet pas de changer les protocoles, les ciphers et d'ajouter un en-tête HSTS - de loomio, qu'on utilise à partir de docker et qui veut pas changer les protocoles et ciphers malgré mes efforts.
Le 19 mars 2019 07:53:50 GMT+01:00, Luc Didry luc@didry.org a écrit :
mardi 19 mars 2019, 00:28:08 CET Breizh wrote:
Bonjour,
T'as linké l'outil d'Aeris, je te link son article :
https://blog.imirhil.fr/2015/09/02/cryptcheck-verifiez-implementations-tls.h...
D'après Aeris lui-même, les recommandations de l'article sont
toujours
d'actualité.
Personnellement, ça donne ECDHE+CHACHA20:ECDHE+AESGCM en HTTPS (HAProxy) et ECDHE+CHACHA20:ECDHE+AES en SMTP (Postfix). Le seconde est celle « recommandée » (enfin, ECDHE+AES suffit, mais autant supporter mieux). Elle supporte quasiment tout, tout en étant totalement sécurisée. Après si tu veux de l'IE sur XP, faudra ajouter le support de quelques trucs plus anciens, à la main à partir de la liste de ciphers que tu as donnée de préférence. Ou réfléchir pour
s'en
débarrasser rapidement.
Breizh.
Vu que ça cause Cryptcheck, je me permets d’évoquer l'outil que j'ai fait avec un collègue pour générer un dashboard des notes cryptcheck de nos sites : https://framagit.org/framasoft/cryptcheck-dashboard/
C'est à utiliser dans GitlabCI et ça pousse dans des Gitlab pages, mais ça serait pas très compliqué à modifier pour un autre setup.
Ça vérifie aussi la présence des enregistrements A et AAAA des domaines testés (vu que chez Framasoft, on est tout en double stack IPv4/IPv6, le seul truc qui pouvait empêcher l'usage d'IPv6, c'était l'oubli du AAAA).
Vous pouvez voir le résultat sur https://framasoft.frama.io/cryptcheck-dashboard/. On n'est pas à 100% de A+ à cause :
- du démon gitlab pages qui permet pas de changer les protocoles, les
ciphers et d'ajouter un en-tête HSTS
- de loomio, qu'on utilise à partir de docker et qui veut pas changer
les protocoles et ciphers malgré mes efforts.
Luc https://fiat-tux.fr/ https://luc.frama.io/ Internet n'est pas compliqué, Internet est ce que vous en faites.
Liste de diffusion du FRsAG http://www.frsag.org/
Je me permet d'apporter une pierre à l'édifice : au delà des tests avec Cryptcheck, il est intéressant aussi d'utiliser testssl.sh, outil qui teste la vulnérabilité à des failles connues et qui simule les navigateurs les plus répandus et indique si ils pourront se connecter.
Personnellement, j'utilise les deux.
Le 19/03/2019 à 07:53, Luc Didry a écrit :
mardi 19 mars 2019, 00:28:08 CET Breizh wrote:
Bonjour,
T'as linké l'outil d'Aeris, je te link son article : https://blog.imirhil.fr/2015/09/02/cryptcheck-verifiez-implementations-tls.h...
D'après Aeris lui-même, les recommandations de l'article sont toujours d'actualité.
Personnellement, ça donne ECDHE+CHACHA20:ECDHE+AESGCM en HTTPS (HAProxy) et ECDHE+CHACHA20:ECDHE+AES en SMTP (Postfix). Le seconde est celle « recommandée » (enfin, ECDHE+AES suffit, mais autant supporter mieux). Elle supporte quasiment tout, tout en étant totalement sécurisée. Après si tu veux de l'IE sur XP, faudra ajouter le support de quelques trucs plus anciens, à la main à partir de la liste de ciphers que tu as donnée de préférence. Ou réfléchir pour s'en débarrasser rapidement.
Breizh.
Vu que ça cause Cryptcheck, je me permets d’évoquer l'outil que j'ai fait avec un collègue pour générer un dashboard des notes cryptcheck de nos sites : https://framagit.org/framasoft/cryptcheck-dashboard/
C'est à utiliser dans GitlabCI et ça pousse dans des Gitlab pages, mais ça serait pas très compliqué à modifier pour un autre setup.
Ça vérifie aussi la présence des enregistrements A et AAAA des domaines testés (vu que chez Framasoft, on est tout en double stack IPv4/IPv6, le seul truc qui pouvait empêcher l'usage d'IPv6, c'était l'oubli du AAAA).
Vous pouvez voir le résultat sur https://framasoft.frama.io/cryptcheck-dashboard/. On n'est pas à 100% de A+ à cause :
- du démon gitlab pages qui permet pas de changer les protocoles, les ciphers et d'ajouter un en-tête HSTS
- de loomio, qu'on utilise à partir de docker et qui veut pas changer les protocoles et ciphers malgré mes efforts.
Un reverse-proxy pour faire la terminaison SSL en amont c’est pas envisageable ?
mardi 19 mars 2019, 10:18:14 CET Bruno Pagani wrote:
Un reverse-proxy pour faire la terminaison SSL en amont c’est pas envisageable ?
Y a des chances que ça finisse comme ça pour Loomio, par contre pour le démon gitlab pages, c'est pas possible : il chope les certificats kivonbien pour les domaines perso depuis le fichier de config en JSON des pages servies.
Le 19/03/2019 à 10:26, Luc Didry a écrit :
mardi 19 mars 2019, 10:18:14 CET Bruno Pagani wrote:
Un reverse-proxy pour faire la terminaison SSL en amont c’est pas envisageable ?
Y a des chances que ça finisse comme ça pour Loomio, par contre pour le démon gitlab pages, c'est pas possible : il chope les certificats kivonbien pour les domaines perso depuis le fichier de config en JSON des pages servies.
Pas sûr de comprendre : quand tu dis qu’il récupère le cert qui va bien, c’est auprès d’une CA ou sur le système de fichiers ? Dans le premier cas, le reverse-proxy en front pourrait laisser le démon récupérer les certificats et s’en servir lui pour terminer le SSL, non (quitte à relayer vers le démon en SSL après si le démon accepte que ça, la sécurité plus faible ne serait plus un problème car en interne). Dans le second cas, je suis pas expert en reverse-proxy, mais je ne vois pas pourquoi ce dernier ne pourrait pas faire le même taf.
mardi 19 mars 2019, 10:31:43 CET Bruno Pagani wrote:
Pas sûr de comprendre : quand tu dis qu’il récupère le cert qui va bien, c’est auprès d’une CA ou sur le système de fichiers ? Dans le premier cas, le reverse-proxy en front pourrait laisser le démon récupérer les certificats et s’en servir lui pour terminer le SSL, non (quitte à relayer vers le démon en SSL après si le démon accepte que ça, la sécurité plus faible ne serait plus un problème car en interne). Dans le second cas, je suis pas expert en reverse-proxy, mais je ne vois pas pourquoi ce dernier ne pourrait pas faire le même taf.
Dans le système de fichier, mais c'est pas dans des fichiers plats, c'est genre { "certificate": { "cert": "XXX", "key": "XXX" } }
Donc il charge le certificat et la clé mais à aucun moment ceux-ci ne sont présents en fichiers plats au format habituel.
Mais y a des tickets chez Gitlab pour permettre la customisation SSL du démon, y a qu'à attendre. Pis ça va, c'est un F sur cryptcheck qui note méchamment mais A chez ssllabs, donc c'est pas forcément le truc le plus urgent du monde non plus.
Le 19/03/2019 à 00:03, daffyduke@lautre.net a écrit :
Vaut-il mieux lister toutes les ciphers acceptés et refusés (comme le fait le lien ci-dessus) ou à l'inverse lister le "max" de ce qu'on veut et dégager tout ce que l'on veut explicitement refuser (!null, !rc4, ....) tout en laissant les options par défaut d'openssl décider de ce qu'il est bon de faire.
Philosophiquement, je dirais que de refuser tout ce qui est dangereux (par défaut je me base sur https://www.ssi.gouv.fr/entreprise/guide/recommandations-de-securite-relativ... comme source) est la bonne façon de faire. Ainsi la négociation se faisant sur le "meilleur" commun tu bénéficies des améliorations quand elle sont disponibles.
Qu'on s'entende bien, je ne cherche pas la plus belle CipherSuite du moment mas plutôt la bonne façon d'aborder le sujet.
Lorsque j'ai été confronté au sujet, je me suis basé sur les statistiques de ma terminaison ssl afin de déterminer les taux d'usage. Ensuite il a fallut présenter aux entités supérieurs l'avantage de mieux sécuriser les communications à contre balancer avec les pertes business de quelques clients obsolètes.
Bon courage.
-
Benoît -
Breizh -
Bruno Pagani -
Bégault Luc -
daffyduke＠lautre.net -
Jonathan bartoua Schneider -
Jérôme BERTHIER -
Luc Didry