-----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.
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/
Ciao
En lisant en diagonale la CVE associée, je suis tombé sur :
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.
Le 16/10/2014 14:59, Pierre Schweitzer a écrit :
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.
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 :
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.
Wallace wallace@morkitu.org writes:
Le 16/10/2014 14:59, Pierre Schweitzer a écrit :
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.
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 :
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 :
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/
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 :
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/
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,
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