Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l’accès chiffré aux serveurs Web. Il n’y a donc plus aucun site Web qui est à l’abri d’une attaque « man in the middle ».
Concrètement, l’attaque consiste à injecter du texte connu dans une page Web (via du JavaScript introduit dans une publicité vérolée, par exemple). Après, il suffit d’écouter la conversion (il faut quand même une session de 30 minutes pour l’exploit actuel) pour découvrir la clef AES. L’exploit permet donc de déchiffrer la page, mais aussi les cookies, et donc de s’identifier sur le site visé.
La faille concerne la version 1.0 de TLS et est corrigée dans la version 1.1, sortie en 2006. En outre, OpenSSL propose un contournement depuis 2004 ; il consiste à injecter des données aléatoires dans la transaction. Malheureusement, les navigateurs utilisent principalement NSS plutôt qu’OpenSSL, et même si sur le serveur on peut forcer l’utilisation de TLS 1.1 ou 1.2, très peu de navigateurs Web les supportent, ce qui freine le déploiement sur les serveurs. Actuellement, seuls IE 9 et Opera en sont capables !
Il faut cependant noter que ces failles sont connues depuis longtemps, c’est ce qui avait mené au correctif dans OpenSSL et à la création de TLS 1.1. Mais c’est la première fois qu’une attaque est publiée, validant ces propositions.
Quelques conseils de navigation :
- utiliser l’extension Firefox noscript ;
- actuellement, là où l’attaque pourra faire le plus de dégât, est sur les webmails ou sur les systèmes de paiement tels que Paypal (ben oui, si quelqu’un pirate ma connexion sur LinuxFr.org, ce ne sera pas très grave, car j’utilise différents mots de passe). Privilégiez donc les clients de messagerie électronique comme mutt ou Thunderbird, en désactivant le HTML.
Merci à Altor pour son aide lors de la rédaction de cette dépêche.
Aller plus loin
- Le blog de Bruce Schneier (336 clics)
- Le blog de Stéphane Bortzmeyer (661 clics)
- Navigateurs supportant TLS 1.2 (382 clics)
# Alarmiste
Posté par Gui13 (site web personnel) . Évalué à 10.
Franchement cette dépêche est très alarmiste, alors que l'article de Stéphane Bortzmeier présenté dans la liste des sources ne l'est pas du tout.
Il explique même que la presse s'est empressée de dénoncer la mort du SSL en l'absence de toutes preuves, ce que semble faire cette dépêche.
Je cite stéphane:
[^] # Re: Alarmiste
Posté par Pinaraf . Évalué à 4.
La faille reste tout de même sévère.
Mais la dépêche n'est pas claire : il ne suffit pas d'insérer du texte, il faut injecter du JS qui soit exécuté et qui effectue une série de requêtes HTTPS vers la victime.
Et il faut aussi avoir un moyen pour écouter le traffic réseau.
Concrêtement, cette attaque réduit énormément la sécurité du HTTPS sur un réseau pas du tout sécurisé, genre un réseau wifi public. Mais heureusement, pas grand chose de plus...
[^] # Re: Alarmiste
Posté par Zenitram (site web personnel) . Évalué à 7.
Euh... Justement, c'est la l’intérêt de SSL : si tu as confiance dans ton réseau, point besoin de SSL! Si je comprend ce que tu dis, SSL serait donc utile à des moment où il est inutile, bizarre. SSL n'est-il pas utile quand tu n'as pas de réseau sécurisé?
Et c'est pas comme si le Wifi public n'était pas fortement déployé (bars, hotels, FON...), et tout lem onde n'a pas li'dée de passer par un VPN (payant) au dessus.
[^] # Re: Alarmiste
Posté par Pinaraf . Évalué à 8.
si tu as confiance dans ton réseau, point besoin de SSL!
Si, tu as besoin de SSL parce que tu communiques pas que avec ton réseau. Mais après tu dois faire confiance en ton FAI pour qu'il te fasse pas une attaque MITM.
[^] # Re: Alarmiste
Posté par Zenitram (site web personnel) . Évalué à 2.
Question con : quelle différence fais-tu entre un mec qui se connecte au Wifi public et ton FAI? Parce que pour moi, les deux ont accès à exactement la même chose (le flux TCP/IP), et donc ont les mêmes moyens. Si l'un est faible, l'autre l'est tout autant.
Pour quelle raison fais-tu la différence entre "sécurisé" (ton FAI seul) et "non sécurisé" (ton FAI + Wifi public) en matière de sécurité, à part le niveau de confiance dans ton FAI (qui n'empèche aucunement le MITM, juste tu imagine qu'il ne va pas le faire)?
[^] # Re: Alarmiste
Posté par J Avd . Évalué à 2.
Pourquoi payant ? Rien ne t'empêche de créer un serveur VPN chez toi (openvpn par ex) et de t'y connecter lorsque tu es dans un réseau "glauque"...
Le problème c'est que cette faille SSL compromet peut être aussi les tunnels VPN, à moins que ça ne touche que HTTPS dans ce cas on est sauvé...
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
[^] # Re: Alarmiste
Posté par Zenitram (site web personnel) . Évalué à -4.
Argh. Tu marques un point. Reste le prix de l'électricité du PC allumé (bon, pas chez moi, il est toujours allumé :) ) et de la complexité de mise en oeuvre pour Mr tout le monde.
[^] # Re: Alarmiste
Posté par Juke (site web personnel) . Évalué à -1.
aptitude install openssh-server un tunnel socks on a vu pire comme complexité.
[^] # Re: Alarmiste
Posté par Zenitram (site web personnel) . Évalué à -4.
j'ai tapé n'importe où avec le clavier vu que tu m'as pas dit ou taper ce texte, ça n'a rien fait. Tu peux parler une langue compréhensible par Mr tout le monde plutôt que de sortir du charabia de "Je me la pète, je suis un bidouilleur qui roxe et j'emmerde ceux qui ne parle pas ma langue"?
Surtout que Mr tout le monde n'a pas Linux (<1% de part de marché de Mr tout le monde, super ta simplicité, faudrait ue j'installe un OS entier pour que ça soit "simple"!), et même sous Linux:
[zenitram@localhost]# aptitude install openssh-server
-bash: aptitude: command not found.
(ben oui, chez d'autre c'est yum)
Et après, c'est bien joli, j'ai installé openssh-server, et ça marche comment? Par miracle, n'importe quel PC à côté, je lui dis à haute voix "PC, fait un VPN", et il le fait?
Bref, non, ce n'est pas aussi simple que tu veux le faire croire, tu fais juste l'élitiste qui ne veut surtout pas se mettre au niveau de Mr tout le monde, ça serait trop rabaissant.
[^] # Re: Alarmiste
Posté par Juke (site web personnel) . Évalué à 5.
Le lundi 26 septembre 2011 à 16:21 +0200, Zenitram a écrit :
> j'ai tapé n'importe où avec le clavier vu que tu m'as pas dit ou taper ce
> texte, ça n'a rien fait. Tu peux parler une langue compréhensible par Mr tout
> le monde plutôt que de sortir du charabia de "Je me la pète, je suis un
> bidouilleur qui roxe et j'emmerde ceux qui ne parle pas ma langue"?
On est sur dlfp pas au café du commerce, si c'est monsieur tout le monde qui me demande (faudrait déjà qu'il soit au courant des problèmes posés par TLS) là c'est toi qui parle de complexité de mise en œuvre, je dise juste que c'est pas si compliqué que ça (pour le "public dlfp")
les tunnels marchent avec putty. Les journalistes du boulot de ma nana l'utilisent sans problèmes pour accéder à leurs infra) et elles n'ont pas du tout un profil geek.
en gros tu monte un tunnel socks vers le serveur, et tu indique à tes appli de passer par le proxy socks
http://glr81.free.fr/pages/sshd-socks-proxy.htm
si tu veux rediriger tout le traffic tu peux utiliser tsocks ou sshuttle.
Depuis openssh 4.3 il est possible de monter des interfaces tunX mais je n'ai pas encore trop regardé comment ça fonctionne.
je veux rien te faire croire du tout. tu parle de vulnérabilité ssl, de
vpn, ça me semble pas hors de ta portée. J'ai pas posté ce commentaire
sur clubic.
non.
[^] # Re: Alarmiste
Posté par Zenitram (site web personnel) . Évalué à -5.
Je me cite : "Et de la complexité de mise en oeuvre pour Mr tout le monde." (oui, c'est la phrase à laquelle tu as répondu).
Je ne savais pas que Putty faisait aussi serveur... (ben oui, Mr tout le monde n'a pas un serveur sous Linux sous la main, 99.99% des gens ont juste une machine chez eux, et encore, pas mal de gens ont juste un portable qu'ils baladent, et 99% des gens sont sous Windows ou Mac donc raté pour la "aptitude").
Bref, non, ce n'est toujours pas si simple, excepté pour de très rares personnes.
Désolé que je pense à Mr tout le monde et pas seulement aux lecteurs de LinuxFr... Mais je continuerai à penser à eux.
Ben si, toujours.
[^] # Re: Alarmiste
Posté par Juke (site web personnel) . Évalué à 6.
Le lundi 26 septembre 2011 à 17:31 +0200, Zenitram a écrit :
> oui, c'est la phrase à laquelle tu as répondu
effectivement je me suis un peu enflammé alors/
[^] # Re: Alarmiste
Posté par Zenitram (site web personnel) . Évalué à 3.
bah... On est deux comme ça ;-).
[^] # Re: Alarmiste
Posté par Grunt . Évalué à 5.
La complexité technique est un faux problème. Les gens sont parfaitement capables d'apprendre comment fonctionne un truc aussi complexe que Facebook, alors que pour un néophyte c'est affreusement compliqué. Perso, quand j'entends parler de "murs" ou "d'application Facebook" j'y pige absolument rien.
Le jour où j'ai voulu créer un compte MSN (y'a des années de ça), j'ai du m'y reprendre une demi-douzaine de fois pour passer la procédure complexe de création de compte, renseignement des données personnelles, saisie du captcha, de la question secrète, lecture et compréhension du CLUF, paramétrage du client.. alors qu'à l'époque je savais déjà installer une distro Linux et y configurer un VPN.
Ils sont capables de trouver leur chemin dans Poste de travail/clic droit/propriété/gestionnaire de périphérique/Internet pour changer les paramètres de leur navigateur Web, alors que ça n'a absolument rien d'intuitif ou d'évident comment chemin.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Alarmiste
Posté par Maclag . Évalué à 0.
Ah là làààà, non, c'est pas "simple".
Pourquoi? Parce que l'utilisateur lambda ne veut pas apprendre à faire un truc pour faire un machin. Tu lui parles de VPN, il comprend qu'à la fin, il va sur internet, mais pas comme avant. Il sait pas trop s'il l'a fait ou pas. C'est compliqué (et surtout c'est chiant).
Tu lui demandes de s'adapter à la nouvelle nomenclature à la mode sur les systèmes de réseaux sociaux. Il va voir le résultat, c'est de l'utilisation directe, et ça, c'est coolࡊ!
Bref, aucun rapport!
[^] # Re: Alarmiste
Posté par Didrik Pining . Évalué à 1.
Tu veux dire comme les solutions du genre vpntunnel.se, de type OpenVPN basé sur... OpenSSL ?
D'ailleurs c'est une bonne question, ça. Est-ce que seul les browsers sont impactés, ou est-ce que cette faille peut être exploitée pour autre chose que de l'HTTPS ?
[^] # Re: Alarmiste
Posté par Zenitram (site web personnel) . Évalué à 2.
Si j'ai bien compris, OpenVPN utilise OpenSSL des deux côtés (client et serveurs), avec le patch qui va bien pour éviter ce genre d'attaque (pas de TLS 1.1 ou 1.2, mais des petites bidouilles autour de TLS 1.0), donc il ne semble pas que ce genre d'outil soit impacté à court terme (ça reste une faiblesse que d'utiliser TLS 1.0...). Le "hic" étant que les navigateurs n'utilisent pas OpenSSL, si encore une fois j'ai bien compris.
[^] # Re: Alarmiste
Posté par Larry Cow . Évalué à 8.
Surtout que bon, pour injecter du Javascript dans un VPN, faut être imaginatif.
[^] # Re: Alarmiste
Posté par Antoine . Évalué à 2.
Bon, et pourquoi les navigateurs n'utiliseraient pas la même bidouille qu'OpenSSL dans leur propre pile crypto, ce qui règlerait le problème ?
[^] # Re: Alarmiste
Posté par claudex . Évalué à 1.
Même si ces failles ont été découvertes il y a longtemps, il y a désormais un exploit qui les mets en évidence. Je trouve justement l'article de Stéphane Bortzmeier trop peu alarmiste, ce n'est pas parce qu'on connait la faille depuis longtemps qu'elle devient moins dangereuse. Surtout qu'il n'y a quasiment aucun moyen de l'éviter, à part utiliser Opera vers des sites qui utilise TLS >= 1.1, ce qui doit fortement réduire tes possibilités de navigation.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Alarmiste
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour le problème de mauvais support, il "suffit" d'avoir un suite de test comme les test acid pour le css. On a vu que c'est très efficace pour pousser à l'amélioration.
"La première sécurité est la liberté"
# Chrome ne devrait pas être vulnérable
Posté par un_brice (site web personnel) . Évalué à -6.
Ça fait quelques temps que Chrome interdit l'inclusion de Javascript non authentifié par les pages HTTPS (en tout cas, la beta le fait depuis plus d'un mois ). Un message apparaît demandant de valider manuellement le chargement du script.
Google Chrome et Chromium ne devraient donc pas être vulnérables, ce qui illustre une fois de plus le soin apporté à la sécurité de ces navigateurs.
[^] # Re: Chrome ne devrait pas être vulnérable
Posté par Pinaraf . Évalué à 4.
Heu...
T'as pas compris.
Tu vas sur le site https://www.paysecam.com.
Mais à côté, dans un autre onglet corrompu, t'as un JS qui joue à envoyer des requêtes vers https://www.paysecam.com, lui aussi. Et paf le chien.
Et ça, c'est pas interdit.
[^] # Re: Chrome ne devrait pas être vulnérable
Posté par un_brice (site web personnel) . Évalué à 1.
Toutes mes excuses. J'ai vraiment dit de la m*rde.
La bonne nouvelle est qu'il semble que la version développeur de Chrome intègre malgrès tout un workaround, même si ce n'est pas celui que je croyais.
(Source : the Register, http://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/ )
# En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Zenitram (site web personnel) . Évalué à 9.
Bon, voyons voir, si on veut être super-secure, et interdire TLS 1.0 et n'accepter que des sites avec une version supérieure...
Libre :
Firefox : fail
Chronium : fail
Non libre :
Opera : OK
IE : OK
Rigolo de voir que le non libre a une longueur d'avance sur le libre en matière de sécurité... Si on veut être en environnement secure (entre chez soit et le site), il faut accepter du proprio chez soit, pas mal comme bizarreté... Et moi qui croyait que le libre était sensible à la sécurité, ben non, Microsoft fait mieux!
Eh! 2006 quand même, 5 ans... Et un "standard" fortement documenté (RFC tout ça...)
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Pinaraf . Évalué à -3.
Ouais, enfin... Trouve des sites n'utilisant pas TLS 1.0, c'est beaucoup plus dur...
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Zenitram (site web personnel) . Évalué à 9.
Donc comme en face, c'est difficile, on ne fait pas évoluer le navigateur... super comme argument. Oeuf, poule... Le fait est la : client libre = TLS 1.0, client proprio = TLS 1.2, client proprio > client libre.
Et si je maîtrise le serveur et qu'il est compatible TLS 1.2? ben voila : je dois utiliser du proprio pour être en sécurité. Ca reste un monde bizarre.
Plutôt que de trouver des excuses, il faudrait accepter que parfois le proprio est en avance sur le libre en matière de sécurité, et arrêter avec cette idée que le libre est toujours meilleur en sécurité.
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Pinaraf . Évalué à 10.
Pfff, tu veux argumenter comme ça ?
OpenSSL contrait cette faille avant la sortie de TLS 1.1. Et Konqueror utilise OpenSSL.
Après j'argumenterai pas sur le fait que c'est nul de la part de mozilla, vu que je le pense.
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Zenitram (site web personnel) . Évalué à -8.
Désolé, je m'étais arrêté aux navigateurs ayant plus de 0.1% de part de marché (j'ai zappé Safari, oups, mais la, comme ça, je ne trouve pas la version supportée).
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par tape . Évalué à 2.
Safari : TLS 1.0 (troisième lien de la dépêche). Aussi nul que Firefox et Chrome.
Ce même lien montre bien (selon moi) que le fait que certains navigateurs se soient tournés les pouces pose un vrai problème pour ne plus être sujet à la faille (simplement passer à TLS 1.2 côté serveur signifie se couper d'une bonne partie du monde), et dit aussi un petit mot à propos des navigateurs pour mobiles.
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Zenitram (site web personnel) . Évalué à 8.
Ca m'apprendra à ne pas cliquer sur tous les liens, oups.
Clair. Perso, ce qui me "choque" est qu'on sait depuis 2004 que TLS 1.0 est "faible", mais "on" a laissé traîner les choses. Du moment où il y a une faiblesse détectée, on sait par expérience qu'il y aura quelque années plus tard une exploitation de la faiblesse. Mais "pas grave", jusqu'au moment où ça craint. Espérons que c'est une bonne piqûre de rappel et que les navigateurs vont prendre au sérieux le fait de gérer les protocoles plus récents.
Ce que je trouve vraiment dommage est le fait que les logiciels libristes (à part Konqueror, OK!) ne font finalement pas mieux que les logiciels proprios au niveau importance sur la sécurité (=on laisse traîner). Firefox a été pas mal connu au début car il était accès sur la sécurité ("je te met Firefox, c'est moins troué que IE"), mais maintenant, Microsoft a remis des développeurs sur IE, et il se trouve qu'IE 9 a de sacrés atouts, alors que du côté de Firefox on a laissé la question de sécurité dans un coin, on dirait l'inversion des rôles : Microsoft devient l'outsider qui fait bien évoluer son navigateur alors que les autres se sont un peu trop reposé. Espérons que la concurrence fasse que tout le monde se réveille!
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Philippe F (site web personnel) . Évalué à 4.
Je suis d'accord sur ton raisonnement sur ce cas précis. Maintenant, n'es-tu pas en train de faire une généralisation hâtive ? Tu as d'autres exemples de problèmes de sécurités négligés par des navigateurs (ou OS) libres mais extrêmement bien géré par des OS proprio ?
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par totof2000 . Évalué à 5.
Pour moi, c'est déjà un poblème de trop : chez Mozilla ils auraient du se concentrer sur ce genre de choses plutôt que de passer leur temps à des choses inutiles (style disparition du numéro de version ...).
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Albert_ . Évalué à 8.
Euh la pour une fois il a raison, le libre est a la bourre sur le coup. Il reste konqueror a verifier dans la liste toutefois :)
Et IE c'est tellement bourre de trou que une de plus, une de moins cela ne change pas grand chose mais c'est a noter que pour une fois le libre est pas a jour.
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par wismerhill . Évalué à 4.
Konqueror utilise openssl.
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par BB . Évalué à 1.
Petite question à ce propos, sur un comportement qui m’inquiète. Lorsque je vais sur le site de ma banque (laposte) avec Konqueror j’ai quasi-systématiquement une alerte https lorsque la fenêtre d’identification s’ouvre. Avec Firefox pas de problèmes. D’autres ont constaté ce comportement ? Dois-je m’en inquiéter ? Est-ce lié au fait que les deux logiciels n’utilisent pas la même bibliothèque ?
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par wismerhill . Évalué à 3.
Quelle est l'alerte?
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par BB . Évalué à 1.
J’obtiens ceci :
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par Larry Cow . Évalué à 5.
Peut-être une utilisation de SNI (Server Name Indication - ou comment faire du VirtualHosting par nom en HTTPS) - que Konqueror ne supporte(rait) pas?
[^] # Re: En attendant, chez Microsoft et Opera, ils sont en avance
Posté par wismerhill . Évalué à 4.
Ça, on dirais que c'est un manque d'un root certificate.
Il me semble que les certificats racine distribués par défaut avec konqueror ne sont pas complet et que certaines distributions patchent pour le faire utiliser les certificats installés globalement, peut-être devrais-tu rapporter le problème sur le bugtracker de ta distrib.
# Précisions
Posté par Aris Adamantiadis (site web personnel) . Évalué à 10. Dernière modification le 25 septembre 2011 à 19:15.
Faux.
La faille n'a pas été découverte. Comme expliqué plus loin, c'est connu depuis longtemps. La nouveauté, c'est qu'un vecteur d'attaque a été découvert, et un exploit fonctionnel a été developpé.
Totalement faux. L'exploit ne récupère pas la clef AES (d'ailleurs cette clef change entre chaque session) mais permet de récupérer des morceaux de cleartext, un byte à la fois.
Le principe est le suivant : l'attaquant force la victime, via un JS introduit dans un flux non chiffré, à récupérer des éléments à des URLs précises, sur un site https (le simple fait d'inclure une image est suffisant). En utilisant des URL suffisamment longues et en introduisant des décalages, il est possible de deviner le dernier byte d'un bloc chiffré en AES-CBC.
Il est donc possible de deviner le cookie pour https://www.paypal.com d'une victime, bien que cette victime ne visite pas le site.
Il y a 3 manières de mitiger le problème :
Si TLS était mieux conçu, il aurait suffit d'activer AES256-CTR par défaut comme en SSH.
[^] # Re: Précisions
Posté par ecyrbe . Évalué à 7.
Merci, j'en était arrivé aux même conclusions après avoir lu la publication des chercheurs.
Et encore, le vecteur d'attaque demande de réussir à exploiter beaucoup de failles. Et même une fois le cookie obtenu, il sera difficile à la personne de l'exploiter pour se connecter réellement a un éventuel compte paypal s'il n'y a pas de session active au moment de l'attaque.
Dans la pratique, cette attaque ne me semble réalisable qu'avec des moyens démesurés. Ce n'est pas impossible, cependant.
[^] # Re: Précisions
Posté par Philippe F (site web personnel) . Évalué à 4.
Donc pour une attaque de script-kiddie, ça le fait pas. Par contre, un attaquant expérimenté et persévérant peut venir à bout d'un utilisateur lambda sans trop de difficultés...
[^] # Re: Précisions
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
En gros, cela pousse à l'écriture d'un TLS 1.3 pour contrer tout problème future de mise à jour ? Il semble aussi que TLS 1.1 n'est pas vulnérable, est-ce que y passer est suffisant ?
Est-ce que linuxfr est vulnérable ? :)
"La première sécurité est la liberté"
[^] # Re: Précisions
Posté par bilboa . Évalué à 2.
A noter que TLSv1.1 suffit.
# Test sur LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
(identification du protocole utilisé par Wireshark 1.6.1)
links 2.3 annonce du TLS v1.0.
iceweasel 6.0.2 annonce du TLS v1.0.
konqueror 4.6.5 annonce du TLS v1.0.
Le serveur nginx utilisé propose SSLv2, SSLv3 ou TLSv1 (et dépend d'OpenSSL).
[^] # Re: Test sur LinuxFr.org
Posté par Zenitram (site web personnel) . Évalué à 3.
https://www.ssllabs.com/ssldb/analyze.html?d=https%3A%2F%2Flinuxfr.org
This server supports secure renegotiation
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 Yes
SSL 2.0+ Upgrade Support Yes
SSL 2.0 No
Bon, sécurité de 0 du fait que l'organisme root (CACert) n'est pas accepté par les navigateurs, dommage.
[^] # Re: Test sur LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Ouais, chacun place sa confiance où il veut (cf https://linuxfr.org/aide#aide-autrecertificatssl )
https://www.ssllabs.com/ssldb/analyze.html?d=https%3A%2F%2Fdiginotar.com (dernier scandale en terme de certificat SSL) obtient 100% sur son certificat (!) et une mauvaise note sur le reste (leur boulot donc...).
https://www.ssllabs.com/ssldb/analyze.html?d=comodo.com (scandale précédent) obtient 100% sur son certificat et une bonne note sur le reste (mais moins bonne que celle de LinuxFr.org).
https://www.ssllabs.com/ssldb/analyze.html?d=verisign.com (encore un scandale) obtient 100% sur son certificat et une note pas trop mal sur le reste (mais moins bonne que celle de LinuxFr.org).
[^] # Re: Test sur LinuxFr.org
Posté par Zenitram (site web personnel) . Évalué à 3.
Oui, bon, en gros, un root qui n’intéresse personne, il est secure pas parce qu'il a fait tout ce qu'il fallait pour (comme se faire certifier), juste parce que peu de monde l'utilise. Certes, les root cités ont eu des problèmes, mais c'est aussi parce qu'ils... étaient intéressants pour les crackers. Sans compter le fait d'habituer les gens à se dire que les warnings des navigateurs, c'est pas méchants, allez hop on installe n'importe quel certificat (parce que pour aller chercher le certificat, il faut aller sur le site de CACert, avec un certificat qu'il a généré lui-même, donc je ne vois aucun moyen d'arriver sur linuxfr en milieu hostile sans me faire cracker dans le cas où quelqu'un veut)
La sécurité par le non intérêt, c'est une façon de gérer la sécurité, chacun sa façon... Pas sûr que ce soit déployable à grand échelle.
[^] # Re: Test sur LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 25 septembre 2011 à 22:19.
Dans certains cas, juste parce qu'on pouvait faire pression sur eux pour avoir des certificats génériques de complaisance ou pour avoir la main sur les certificats racine...
Je résume :
Bref on arrive à un des principes classiques en sécurité : à qui faire confiance ? Et si je ne fais confiance à personne, ben je n'ai pas grand chose... Sauf à réécrire tous mes logiciels de zéro et revalider toutes les RFC, les protocoles réseau et de chiffrement, etc.
Globalement en environnement hostile, pour accéder au site (hypersensible :) LinuxFr.org :
Perso, plus ça va, plus j'aurais tendance à accorder ma confiance à un certificat autosigné par quelqu'un de sûr et connu, qu'à une hypothétique autorité de confiance dont je ne connais rien et qui a des consoeurs douteuses.
[^] # Re: Test sur LinuxFr.org
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Tu oublis un point important : je fais confiance à la même personne depuis le début, c'est ce que je sais en voyant que le certificat ne change pas. C'est finalement le plus important : savoir que je discute avec la même entité depuis toujours.
Sa réelle identité importe peu.
"La première sécurité est la liberté"
[^] # Re: Test sur LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Je n'oublie pas, mais ça n'est valable que si tu as un jour été hors de l'environnement hostile... Si tu as un jour déjà utilisé LinuxFr.org en HTTPS dans une zone de confiance, tu as déjà validé le certificat par exemple et donc tout va bien. Si tu utilises LinuxFr.org depuis toujours depuis une zone louche, genre DictatureLand, beh... Quelques pistes : tâcher de se faire confirmer l'info par plusieurs personnes en espérant que..., vérifier sur archive.org et le cache google que le site avait bien la même tête et donnait bien la même signature du certificat il y a quelques mois en espérant que..., utiliser un autre moyen de communication pour avoir l'info (SMS, téléphone, courriel, etc.) en espérant...
[^] # Re: Test sur LinuxFr.org
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'est vrai qu'un système àla "gpg" serait mieux que les certificats :/
"La première sécurité est la liberté"
[^] # Re: Test sur LinuxFr.org
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
C'est fait : http://web.monkeysphere.info/
Reste plus qu'à l'intégrer de standard dans les brouteurs et autres clients SSL. Mort aux certificats X.509 !
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Test sur LinuxFr.org
Posté par Franck Routier (Mastodon) . Évalué à 3.
Ou demander à plusieurs personnes de confiance (le point important est plusieurs, pas de confiance) sur le réseau si ils voient la même chose et confirme le certificat : http://convergence.io/index.html
et ici quelques infos techniques (video en anglais), ou encore http://tech.slashdot.org/story/11/09/08/1454221/Moxie-Marlinspikes-Solution-To-the-SSL-CA-Problem (pour les commentaires des slashdotters).
Les remarques des plus éclairés sont les bienvenues !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Benoît Sibaud (site web personnel) . Évalué à 2. Dernière modification le 02 octobre 2011 à 12:40.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Test sur LinuxFr.org
Posté par lgodard . Évalué à 2.
?????
oui mais encore ?
quelle entrée de http://linuxfr.org/regles_de_moderation a été activée pour ce commentaire ?
Laurent
[^] # Re: Test sur LinuxFr.org
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
La suppression à la demande de l'auteur (moi). En l'occurrence la suppression par l'auteur lui-même, qui a répondu au commentaire en pensant qu'il s'agissait de la dépêche Hadopi et PDF, donc à côté de la plaque.
[^] # Re: Test sur LinuxFr.org
Posté par Barnabé . Évalué à 3.
Peut-être le modérateur Benoît Sibaud devrait-il s'abstenir de corriger les erreurs de l'utilisateur Benoît Sibaud, au moins tant que les autres utilisateurs n'ont pas la même capacité.
[^] # Re: Test sur LinuxFr.org
Posté par Bruno Michel (site web personnel) . Évalué à 1.
Les autres utilisateurs peuvent aussi demander à un modérateur de supprimer un commentaire. D'ailleurs, ça arrive de temps en temps.
[^] # Re: Test sur LinuxFr.org
Posté par Maclag . Évalué à 1.
Mais attention, avec les nouvelles failles de sécurité, je peux peut-être faire supprimer des commentaires appartenant à d'autres! (ou pas, mais vu que j'écrivais ça juste pour troller, pourquoi je devrais en plus vérifier la source de mes FUD?!?)
---------> [ ]
[^] # Re: Test sur LinuxFr.org
Posté par dyno partouzeur de drouate . Évalué à 1.
La moindre des règles dans ce cas c'est de demander à un autre modérateur de le supprimer, et pas de le faire soi même, cf four eyes process.
Enfin bon, c'est une question d'éthique, après moi je m'en fous un peu. Pauvres drosophiles...
[^] # Re: Test sur LinuxFr.org
Posté par Pierre Tramo (site web personnel) . Évalué à 4.
Salut!
Vous pouvez supprimer ce commentaire?
[^] # Re: Test sur LinuxFr.org
Posté par claudex . Évalué à 3.
Je ne comprend pas le rapport avec la sécurité par l'obscurité.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Test sur LinuxFr.org
Posté par Maclag . Évalué à 3.
Oui, ben les virus ont pas été inventés pour animer nos vendredi:
"Un ordinateur sous MS Windows non mis-à-jour et non protégé peut être contaminé en quelques minutes seulement en connexion directe à Internet!
-Pffff... BeOS le faisait il y a 10ans!"
-----------> [ ]
# La guerre des clones a commencé
Posté par Marotte ⛧ . Évalué à 2.
Voilà ce que j'ai lors d'une connexion IMAP chez gmail.com depuis Evolution :
Je vois également que j'ai une palanqué de packages à mettre à jour sur mon Lynx Lucide à cause de révocations de certificats.
Fait chier.
[^] # Re: La guerre des clones a commencé
Posté par Maclag . Évalué à 3.
C'est enfin prouvé: Google, c'est le Mal!™
# Config pour Apache
Posté par Whoo (site web personnel) . Évalué à 2.
Hello,
J'ai trouvé cela pour limiter les dégâts en attendant les mises à jour.
(cela va prendre un peu de temps avec l'histoire de la poule et de l'oeuf)
http://www.g-loaded.eu/2011/09/27/mod_gnutls-rc4-cipher-beast/
SSLHonorCipherOrder on
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL
En tout cas, le test sur SSLlabs semble se calmer avec cela.
linux / linux / linux
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.