-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bonjour à tous, Cette nuit, une faille dans le protocole SSLv3 a été révélée. Il est important de noter que c'est une faille dans le protocole et non dans une implémentation du protocole. Les détails sont dévoilés ici : http://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting... Pour résumer ce qui y est dit, il faut désactiver SSLv3 dans le meilleur des cas, ou au moins, empêcher les clients de passer de TLS à SSLv3 en cas d'erreur réseau (ce qui est une technique pour exploiter la faille). Par ailleurs, on parle beaucoup de HTTP comme protocole vulnérable (ce qui est un fait), mais la faille s'appuie notamment sur des bouts de texte connus pour avoir le reste (donc, récupérer les cookies par exemple sur HTTP). Cela veut dire que ça marche sur d'autres protocoles verbeux, type IRC (pour récupérer le mot de passe). Un client n'est vulnérable que si on est capable de sniffer ses paquets, donc wifi, MITM, etc. Debian (par exemple), va désactiver le support de SSLv3 sur Iceweasel. Bonne journée, - -- Pierre Schweitzer <pierre@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUPiBZAAoJEHVFVWw9WFsLYDEQAICBytkbGj2GgzHF3iN0/fHS ZbUbOKTnl8cPsf1HsHz/zGj6bwRWHTLoQJZclmZFU7HiolZRaDllzM2nvDTn7Yx/ sd45IA/Xj2ePEIVmARTZX7p3IF8O5Cc8QIWesGYgZQ3U5pGUIDOGpFsBF1YE+zkg EH4iWXoy/kawroktYKKZ7IPt6j0ep9mgkWgCa8uZF+dpo9Wk59cfkCvLax6Ny0rg Iu601f24wH5Q7EfZJM9BI7YB2UvuNWPpNlyLRpdWAihuHf6wcWfk2O92kgdv7MPv wYm6qA7BU9dQlsIbVYRQf3rhpqNbvnhkAXoVD49BQ9MG7Vs399Ha+k7Jc9MAFNIF 1DzcR1gqgKPIClKNVRjn/RFZY4S4NaA+T/Jkzn153Mc78CpIvEVOESGj/UBUy0yX F242qDqsJOiHqpQ3azFfGxGZMyMmR7NlIlG5YCRPiiEdvu1yRW9dZJi1ZDe+Y1S9 1sx8/McmVeGEMQ4KpxWIyMHfereMRNmfmvuGcrShJsEguvWPoeFo/xNq0e6+1shF lKCjmq0iYRV3yM0BhBNovod7LbpRluDnleu+/GnFwiE6s+z+DLyxFTCxvVR+3Oir RYJUTiDqe6UiZ2mek+L2eoBVOSyvZNODSgAUiSB60wtP27dhCPT5A+1BoUw6413n vqnEYR3M6wUf80kFMwjR =gRgZ -----END PGP SIGNATURE-----
Bonjour, Il faut désactiver surtout le SSL toute version du côté des serveurs. Ce n'est pas pour les quelques personnes qui utilisent encore un IE6 non mis à jour sur XP que l'on va mettre en danger tout ceux qui ont des navigateurs récents. Normalement rien qu'avec le choix d'algorithmes sécurisés la compatibilité avec les vieux navigateurs est déjà cassée et si tel est le cas le serveur est déjà vulnérable à d'autres failles. Conclusion c'est un argument de plus pour couper définitivement SSL. Le 15/10/2014 09:20, Pierre Schweitzer a écrit :
Bonjour à tous,
Cette nuit, une faille dans le protocole SSLv3 a été révélée. Il est important de noter que c'est une faille dans le protocole et non dans une implémentation du protocole. Les détails sont dévoilés ici : http://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting...
Pour résumer ce qui y est dit, il faut désactiver SSLv3 dans le meilleur des cas, ou au moins, empêcher les clients de passer de TLS à SSLv3 en cas d'erreur réseau (ce qui est une technique pour exploiter la faille). Par ailleurs, on parle beaucoup de HTTP comme protocole vulnérable (ce qui est un fait), mais la faille s'appuie notamment sur des bouts de texte connus pour avoir le reste (donc, récupérer les cookies par exemple sur HTTP). Cela veut dire que ça marche sur d'autres protocoles verbeux, type IRC (pour récupérer le mot de passe).
Un client n'est vulnérable que si on est capable de sniffer ses paquets, donc wifi, MITM, etc.
Debian (par exemple), va désactiver le support de SSLv3 sur Iceweasel.
Bonne journée, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Pour compléter Wallace, je me permets de linker le site de microsoft : https://www.modern.ie/en-us/ie6countdown On voit que IE6 en france est à 0.8% … Le Thursday 16 Oct 2014 à 11:25:07 (+0200), Wallace a écrit :
Bonjour, Il faut désactiver surtout le SSL toute version du côté des serveurs. Ce n'est pas pour les quelques personnes qui utilisent encore un IE6 non mis à jour sur XP que l'on va mettre en danger tout ceux qui ont des navigateurs récents. Normalement rien qu'avec le choix d'algorithmes sécurisés la compatibilité avec les vieux navigateurs est déjà cassée et si tel est le cas le serveur est déjà vulnérable à d'autres failles.
Conclusion c'est un argument de plus pour couper définitivement SSL.
Le 15/10/2014 09:20, Pierre Schweitzer a écrit :
Bonjour à tous,
Cette nuit, une faille dans le protocole SSLv3 a été révélée. Il est important de noter que c'est une faille dans le protocole et non dans une implémentation du protocole. Les détails sont dévoilés ici : http://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting...
Pour résumer ce qui y est dit, il faut désactiver SSLv3 dans le meilleur des cas, ou au moins, empêcher les clients de passer de TLS à SSLv3 en cas d'erreur réseau (ce qui est une technique pour exploiter la faille). Par ailleurs, on parle beaucoup de HTTP comme protocole vulnérable (ce qui est un fait), mais la faille s'appuie notamment sur des bouts de texte connus pour avoir le reste (donc, récupérer les cookies par exemple sur HTTP). Cela veut dire que ça marche sur d'autres protocoles verbeux, type IRC (pour récupérer le mot de passe).
Un client n'est vulnérable que si on est capable de sniffer ses paquets, donc wifi, MITM, etc.
Debian (par exemple), va désactiver le support de SSLv3 sur Iceweasel.
Bonne journée, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- | Florentin Clouet AdminSys GNU/Linux | | florentin@clouet.me +33 6 88 05 25 75 | -- Se tromper est humain ; Vraiment foutre la merde necessite le mot de passe de root.
Ciao En lisant en diagonale la CVE associée, je suis tombé sur : https://cipherli.st/ C'est sympa pour avoir une configuration recommandée fonctionnelle. Km
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sinon : https://wiki.mozilla.org/Security/Server_Side_TLS On 10/16/2014 02:40 PM, cam.lafit@azerttyu.net wrote:
Ciao
En lisant en diagonale la CVE associée, je suis tombé sur :
C'est sympa pour avoir une configuration recommandée fonctionnelle.
Km _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
- -- Pierre Schweitzer <pierre@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUP8E7AAoJEHVFVWw9WFsL9swP/2h0FWc0koolmLVrxgtGeUlj o2h+O5AB/wpvbV1DSjYYRZFsYuR0cn2YnLLcSOxuv3SRTvGD/aj3NeenPC+X1lFU T9Mzx094cgo0xYCVCYCKY+NIHIrcKaMROlbqWdzKjPpogqfiZ423IER6ilOP4Ne5 huttC51lrpCiCucwczf6RzYvzJY5PqRMhbZPsYS5kpWVqKGhvBFCphwNJorf9Q4P 80CTyTUEqujcSi7v4Ng9KcSc6iniQfaFjnhcy+kIekW46n2J1c/ysN+sBbxbQszs GocSHuhMnIbAZC1ZOTxwHzst14U4veBHxncvGEFXZr0wMEOL+NBUNHKwVnFvkZWh PwxcmgqZwGmmUcxhtA/tgt6xOxOhGrCrc6zLR4iTAyDR5YKKlOuytrft+Xw3oR4T /0+Pf7gifUa3eW9jXF4xEF4bW8KDYYh/pR169f9NtR/YJ6zGgqEiTr5WITFy5JL9 wuNDkJRgyD2R87KPdk505HgWfFfp8bZOtd6dex8e6IYXoVIQRKDp/FPbqFECWMrc uB2s1bLfEUgnMkBwKlAUUlbn52S1AVBeakXKrD8mzUEb88jdgVa1HJRL13EmvBjw MNRGSlVbdRUebmTy0y4zT1uw1e44ob6ro669qjpdq8hagQRfX2fzYW0OHgFXMW3P wL9jtmIbW/3s6gUFHc3v =635o -----END PGP SIGNATURE-----
Le 16/10/2014 14:59, Pierre Schweitzer a écrit :
Sinon : https://wiki.mozilla.org/Security/Server_Side_TLS A noter que pour Mozilla le TLS 1.0 est aussi à désactiver, va falloir que je recherche pourquoi.
Mais qu'à l'inverse ils conseillent de mettre des algos en AES128 alors qu'on admet qu'ils sont trop facilement cassable, ils veulent sans doute assurer la compatibilité avec les vieux FF ou Thunderbird. https://cipherli.st/ pareil est un peu laxiste sur les algos et n'est pas assez stricte à mon goût mais ça reste un bon début sur la configuration de base, si déjà tout le monde pouvait être à ce niveau là ça serait pas mal.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/16/2014 04:07 PM, Wallace wrote:
Le 16/10/2014 14:59, Pierre Schweitzer a écrit :
Sinon : https://wiki.mozilla.org/Security/Server_Side_TLS A noter que pour Mozilla le TLS 1.0 est aussi à désactiver, va falloir que je recherche pourquoi.
Typiquement parce que TLSv1.0 est encore sensible à des attaques type BEAST (attaque contre les ciphers CBC). Les mécanismes de protection contre ces attaques n'ont été intégrés que dans TLSv1.1.
Mais qu'à l'inverse ils conseillent de mettre des algos en AES128 alors qu'on admet qu'ils sont trop facilement cassable, ils veulent sans doute assurer la compatibilité avec les vieux FF ou Thunderbird.
pareil est un peu laxiste sur les algos et n'est pas assez stricte à mon goût mais ça reste un bon début sur la configuration de base, si déjà tout le monde pouvait être à ce niveau là ça serait pas mal.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
- -- Pierre Schweitzer <pierre@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUP9T/AAoJEHVFVWw9WFsLK2YP/1Pr2Zhym9Wv95NwiN5xFYlc rTvGNOTqRiJmwjhvz3vQ2oYJS+hzQ+gZQ3kD99VPKSLpzZh/ZM942tteOZ86pk7D q0SmGNDSRhmIvEwJM8aFQS5r55tx9u+E68nKGBeTkfO3sV4PEIp5Z30J8zggZfTd +Gk2DMNAt+QwTr0L9T6SLHjrRFnDwkEcC2Jjw9Yyty8Dqzh14P/rt3/PH/tXMTcm Lyvz9VtS0Mub3TxYSzpan2jya2zgxPs/6xRZmqMPuen25K62Z5/0hhk27FfCEyk5 Z6jx6bGKYFxSlda+JsNsJKQli7Mi7Zwr4hraB1c+T8GkvXOgF1D62Fz557xyFMGM jmDNo569Fsy6dqpszk38d+72SNA0zD2HYEDDb1lIUfByNCZ3DwFJKlq35CedWeyy MUsDW3TTWQ71uV8jv34apEYYUbdDA+hBXaU6TwNw5zVnEOAOzj4xt9g5uveYwQkV K1zot+DNnDt9JpkSBkKr4SBDJ6z/TP1UNCTQyUjhHx/9Goi6V6ffwZWOTpXndzmZ hKWuVbhqv2uVZ0dLDKA0GsZ+Ekniz76Lk66u/wQ+3R25xp3PL+99Vq7CtqD5nx0T AdNrbjy3LHzGxkpJVaC+cO3dNKUygxjl3S5U4CmgnRzohlXJNp4Sk/uPh3E03giN y5ayu4UTtHmKCr8cOORr =kpeN -----END PGP SIGNATURE-----
Wallace <wallace@morkitu.org> writes:
Le 16/10/2014 14:59, Pierre Schweitzer a écrit :
Sinon : https://wiki.mozilla.org/Security/Server_Side_TLS A noter que pour Mozilla le TLS 1.0 est aussi à désactiver, va falloir que je recherche pourquoi.
Mais qu'à l'inverse ils conseillent de mettre des algos en AES128 alors qu'on admet qu'ils sont trop facilement cassables,
C'est qui, "on" ? :) Je doute que AES128 soit une cause de préoccupations. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Le 16 oct. - 14:40, cam.lafit@azerttyu.net a écrit :
Ciao
En lisant en diagonale la CVE associée, je suis tombé sur :
C'est sympa pour avoir une configuration recommandée fonctionnelle.
Km
Il y a également : https://github.com/jvehent/cipherscan Analyze.py permet de comparer sa configuration avec les recommandations de Mozilla. Julien
Le 16-10-2014 15:13, Julien Rabier a écrit :
https://cipherli.st/ Il y a également : https://github.com/jvehent/cipherscan Analyze.py permet de comparer sa configuration avec les recommandations de Mozilla.
Et pour valider le tout, le classique: https://www.ssllabs.com/ssltest/ A noter aussi, une version bêta qui vérifie poodle et également d'autre trucs: https://dev.ssllabs.com/ssltest/ Arnaud, A+ en nginx et apache ;)
Personne ne parle de bettecrypto ? https://bettercrypto.org/ Ils éditent un pdf sur les bestpratices en crypto pour différents services (même IIS ! (merde il est pas encore minuit)). Le pdf en question : https://bettercrypto.org/static/applied-crypto-hardening.pdf Sinon oui la doc de chez Mozilla est pas mal du tout également. Le Thursday 16 Oct 2014 à 15:17:34 (+0200), Arnaud Launay a écrit :
Le 16-10-2014 15:13, Julien Rabier a écrit :
https://cipherli.st/ Il y a également : https://github.com/jvehent/cipherscan Analyze.py permet de comparer sa configuration avec les recommandations de Mozilla.
Et pour valider le tout, le classique: https://www.ssllabs.com/ssltest/
A noter aussi, une version bêta qui vérifie poodle et également d'autre trucs:
https://dev.ssllabs.com/ssltest/
Arnaud, A+ en nginx et apache ;) _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- | Florentin Clouet AdminSys GNU/Linux | | florentin@clouet.me +33 6 88 05 25 75 | -- Linux est obsolète. -+- Andrew Tanenbaum -+-
Personne ne parle de bettercrypto ? https://bettercrypto.org/ Ils éditent un pdf sur les bestpratices en crypto pour différents services (même IIS ! (trolldi)) Le pdf en question : https://bettercrypto.org/static/applied-crypto-hardening.pdf Sinon oui la doc de chez Mozilla est pas mal du tout également. Le Thursday 16 Oct 2014 à 15:17:34 (+0200), Arnaud Launay a écrit :
Le 16-10-2014 15:13, Julien Rabier a écrit :
https://cipherli.st/ Il y a également : https://github.com/jvehent/cipherscan Analyze.py permet de comparer sa configuration avec les recommandations de Mozilla.
Et pour valider le tout, le classique: https://www.ssllabs.com/ssltest/
A noter aussi, une version bêta qui vérifie poodle et également d'autre trucs:
https://dev.ssllabs.com/ssltest/
Arnaud, A+ en nginx et apache ;) _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- | Florentin Clouet AdminSys GNU/Linux | | florentin@clouet.me +33 6 88 05 25 75 | -- La programmation en C++ chez les industriels est comme le sexe chez les adolescents : - tout le monde y pense ; - tout le monde en parle ; - tout le monde croit que le voisin le fait ; - presque personne ne le fait. Ceux qui le font : - le font mal ; - pensent que la prochaine fois ce sera mieux ; - ne prennent pas de précautions.
Bonjour à toutes et tous, On Wed, 15 Oct 2014 09:20:57 +0200 Pierre Schweitzer <pierre@reactos.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bonjour à tous,
Cette nuit, une faille dans le protocole SSLv3 a été révélée. Il est important de noter que c'est une faille dans le protocole et non dans une implémentation du protocole. Les détails sont dévoilés ici : http://googleonlinesecurity.blogspot.de/2014/10/this-poodle-bites-exploiting...
Pour résumer ce qui y est dit, il faut désactiver SSLv3 dans le meilleur des cas, ou au moins, empêcher les clients de passer de TLS à SSLv3 en cas d'erreur réseau (ce qui est une technique pour exploiter la faille). Par ailleurs, on parle beaucoup de HTTP comme protocole vulnérable (ce qui est un fait), mais la faille s'appuie notamment sur des bouts de texte connus pour avoir le reste (donc, récupérer les cookies par exemple sur HTTP). Cela veut dire que ça marche sur d'autres protocoles verbeux, type IRC (pour récupérer le mot de passe).
Un client n'est vulnérable que si on est capable de sniffer ses paquets, donc wifi, MITM, etc.
Debian (par exemple), va désactiver le support de SSLv3 sur Iceweasel.
Bonne journée,
De ce que j'ai compris, les trois parades possibles sont : * désactiver le protocole SSLv3 ; * interdire les ciphers en mode CBC ; * activer TLS_FALLBACK_SCSV. Sauf que : * si on désactive SSLv3 on perd un bon nombre de clients vieux et/ou exotiques, et pas seulement les navigateurs web des clients, on perd aussi les automates (Java 1.6, etc.) des fournisseurs, des partenaires et peut-être même des clients aussi ; * si on interdit les ciphers en mode CBC dans SSLv3 il ne reste plus grand chose à part RC4, qui n'est pas une solution, plutôt un problème ; * TLS_FALLBACK_SCSV (<https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-02>) n'est pas encore standardisé et n'est implémenté pratiquement nulle part (appliances, etc.). Sachant que le mode CBC et RC4 sont interdit dans TLS 1.3 (standardisation en cours, publication dans les mois à venir), on voit bien que dans les faits les jours de SSLv3 sont comptés... La situation sur ce front n'est pas simple : couper SSLv3 c'est fermer la porte à des clients (les décideurs vont pas aimer), et le laisser en vie c'est compromettre la sécurité de tous les autres clients... Les équipes techniques ont-elles le pouvoir de pousser une telle décision ? :-) Bien cordialement, -- Maxime DERCHE OpenPGP public key ID : 0xA0C235A4 (fingerprint : AB0A 5850 FE8F F958 C08A C08E 2FA5 E1F4 A0C2 35A4) http://www.mouet-mouet.net/maxime/blog/index.php
Bonjour, Le 18/10/2014 10:07, Maxime DERCHE a écrit :
La situation sur ce front n'est pas simple : couper SSLv3 c'est fermer la porte à des clients (les décideurs vont pas aimer)
Vu du côté du verre à moitié plein, c'est aussi protéger les clients et avec une bonne communication, ça se vend.
Hello,
La situation sur ce front n'est pas simple : couper SSLv3 c'est fermer la porte à des clients (les décideurs vont pas aimer), et le laisser en vie c'est compromettre la sécurité de tous les autres clients... Les équipes techniques ont-elles le pouvoir de pousser une telle décision ? :-)
Ca fait plus de 6 mois que j'ai coupé SSLv3 de pas mal de services dont certains pour des clients type bancaires. Je n'ai jamais eu de retours négatifs, donc on peux penser que de fait, en interne chez ce type de clients on a déjà fait de sorte que SSLv3 soit bannis. D'un autre coté ça me rassure. A noter que je bosse pour une boite de logiciels et ne travaille pas avec du e-commerce. Xavier
Stats relevées auprès de différents partenaires : - côté transitaires de paiements internet, <1% des transactions en SSLv3 - côté téléservices administration, en gros 3%. La masse des connexions en SSLv3 vient d’IE6 sous XP et de clients en Oracle Java 6. A partir de XP SP3 on peut faire du TLS 1.0 (IE8). On trouve parfois aussi des clients de Web Services codés avec de vieilles technos (Delphi 2010 par exemple). Bref avant de désactiver, vérifier avec ses clients. Stéphane
Le 19 oct. 2014 à 12:18, Xavier Beaudouin <kiwi@oav.net> a écrit :
Hello,
La situation sur ce front n'est pas simple : couper SSLv3 c'est fermer la porte à des clients (les décideurs vont pas aimer), et le laisser en vie c'est compromettre la sécurité de tous les autres clients... Les équipes techniques ont-elles le pouvoir de pousser une telle décision ? :-)
Ca fait plus de 6 mois que j'ai coupé SSLv3 de pas mal de services dont certains pour des clients type bancaires.
Je n'ai jamais eu de retours négatifs, donc on peux penser que de fait, en interne chez ce type de clients on a déjà fait de sorte que SSLv3 soit bannis.
D'un autre coté ça me rassure.
A noter que je bosse pour une boite de logiciels et ne travaille pas avec du e-commerce.
Xavier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 20/10/2014 1:20, Stephane Martin a écrit :
Stats relevées auprès de différents partenaires : - côté transitaires de paiements internet, <1% des transactions en SSLv3 - côté téléservices administration, en gros 3%.
Ca m'étonne pas... :)
La masse des connexions en SSLv3 vient d’IE6 sous XP et de clients en Oracle Java 6. A partir de XP SP3 on peut faire du TLS 1.0 (IE8). On trouve parfois aussi des clients de Web Services codés avec de vieilles technos (Delphi 2010 par exemple).
Bref avant de désactiver, vérifier avec ses clients.
Effectivement, mais bon XP n'est plus supporté par m$ depuis début 2014. S'amuser a encore le supporter c'est un peu aider les botnet a exister aussi. Après rien n'empêche de mettre une page : "votre OS est trop vieux et trop dangereux, veuillez upgrader IE6 a IE8 ou utiliser firefox, chrome ou chrominum". Dans des cas sites public ouvert sur 0.0.0.0/0 avoir une certaine sécurité dans les protocole https est bon pour faire avancer les choses. Laisser les trous de sécu pour juste garder la compat IE6.... C'est un corresponds franchement a une non évolution des techno... Sinon dans ce cas là il faut laisser aussi les sites gopher:// ? /Xavier -- Xavier Beaudouin
participants (11)
-
Arnaud Launay -
cam.lafit＠azerttyu.net -
Denis Fondras -
Florentin Clouet -
jca+frsag＠wxcvbn.org -
Julien Rabier -
Maxime DERCHE -
Pierre Schweitzer -
Stephane Martin -
Wallace -
Xavier Beaudouin