La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: turold le 07 septembre 2016 à 22:26:28
-
Salut,
Vivien dit vouloir du A(+) sur tout les tests TLS.
Alors là, j'ai du boulot pour lui!^^
Grade F avec un score global de 68/100 (score le plus faible 50/100 en chiffrement) sur imirhil (alias CryptCheck) : https://tls.imirhil.fr/https/lafibre.info
Par contre, là, pas trouvé de doc...
-
Le test regarde le niveau de sécurité des suites de chiffrements les plus faibles utilisables sur le serveur.
Dans le cas présent, il faudrait virer toutes les suites de chiffrement avec 3DES (cf le récapitulatif en haut à droite : fatal ->DES3) pour obtenir un résultat meilleur (ce qui éliminerait le support d'IE8 sous XP, pas une grande perte) pour avoir un score élevé.
En bonus, on peut aussi supprimer toutes les suites de chiffrement sans échange de clefs de type Diffie-Hellman (on parle de confidentialité persistante), puisque d'après SSL Labs, aucun navigateur de sa liste n'en a besoin ;)
-
On en parlait déjà il y a quelques mois sur ce sujet (https://lafibre.info/cryptographie/quelques-bonnes-pratiques-pour-https-avec-apache2/), et je garde ma position : supprimer TLS 1.0 pose trop de problèmes de compatibilité, supprimer 3DES permet de bannir IE8 sous XP ce qui est plutôt une bonne chose pour la sécurité de ceux qui l'utilisent (surfer sur le web avec ça est dangereux, et ceux qui le gardent pour de l'intranet uniquement ne viennent pas sur ce site)
-
Supprimer Internet Explorer 8, cela me semble problématique, vu le nombre de personnes qui sont forcées d'utiliser ce navigateur en entreprise.
Voici les log du mois d'aout avec Internet Explorer 8 (j'ai supprimé quelques caractères de chaque IP) : 201608_log_lafibre_navigateur_ie8.ods (https://lafibre.info/images/stats/201608_log_lafibre_navigateur_ie8.ods)
Fichier Libre office calc, lisible également avec Microsoft Excel.
Voici les recommandation de Mozilla : https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
Je vise l'intermédiaire.
Voici ma conf, j'ai désactivé le StaplingCache car le site était régulièrement inaccessible avec (pb de renouvellement)
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
#SSLSessionTickets off demande Apache 2.4.11min:
#SSLSessionTickets off
SSLCompression off
#SSLUseStapling on
#SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
-
Voici les log du mois d'aout avec Internet Explorer 8 (j'ai supprimé quelques caractères de chaque IP) : 201608_log_lafibre_navigateur_ie8.ods (https://lafibre.info/images/stats/201608_log_lafibre_navigateur_ie8.ods)
Attention, dans tes logs il y a beaucoup de IE8 sous windows 7, qui lui est compatible (tout comme IE sous windows vista) avec des suites de chiffrement plus modernes. Puis, je n'ai pas l'impression à les lire (à défaut d'écrire un script pour les compter) qu'il y a des masses de visiteurs uniques concernés ;)
-
En détail, cela donne :
- 513 IP uniques pour "Windows NT 6.1" =2009=> Windows 7 et Windows Server 2008 R2
- 59 IP uniques pour "Windows NT 6.0" =2007=> Windows Vista et Windows Server 2008
- 52 IP uniques pour "Windows NT 5.2" =2003=> Windows XP 64 Bits et Windows Server 2003
- 525 IP uniques pour "Windows NT 5.1" =2001=> Windows XP
- 5 IP uniques pour un user agent sans OS ou un autre OS (J'ai un IE8 avec un Win 2000 et un avec un Win 8 et le reste sans info OS)
-
Le test regarde le niveau de sécurité des suites de chiffrements les plus faibles utilisables sur le serveur.
Dans le cas présent, il faudrait virer toutes les suites de chiffrement avec 3DES (cf le récapitulatif en haut à droite : fatal ->DES3) pour obtenir un résultat meilleur (ce qui éliminerait le support d'IE8 sous XP, pas une grande perte) pour avoir un score élevé.
Oui alors si tu peux m'expliquer en quoi proposer 3DES est une vulnérabilité.
Il ne s'agit pas de dire que c'est vieux, que c'est dépassé techniquement, que c'est peu efficace, que n'importe quel autre suite est mieux; en quoi 3DES est "fatal" et fait mériter cette note?
-
en quoi 3DES est "fatal" et fait mériter cette note?
Je ne suis pas spécialiste en cryptographie, je constate juste que des gens plus compétents que moi indiquent que celui-ci, s'il n'est pas publiquement cassé, a une possibilité non négligeable de l'être (et dans ce domaine-là, si on trouve quelque chose, on le garde pour soi), et donc j'explique dans mon message que, pour avoir une meilleure note à ce test, il faudrait supprimer 3DES.
PS : Sachant que les navigateurs ne supportant pas mieux que 3DES sont, à ma connaissance, tous plus mis à jour et avec une sécurité déplorable, en dehors de la sécurité intrinsèque du protocole, ce n'est pas un joli cadeau de continuer à le supporter.
-
3DES était déjà sur la sellette depuis un bout de temps (taille de clé de 112 bits seulement et taille de bloc de 64 bits, quand on recommande au moins 128 bits pour les 2).
Mais récemment, tout ce qui est < 128 bits en taille de bloc (3DES mais aussi IDEA) a été cassé officiellement :
- https://sweet32.info/
- https://www.openssl.org/blog/blog/2016/08/24/sweet32/
Les équipes de OpenSSL conseillent de considérer 3DES au moins aussi moisi que RC4, c’est dire :D
-
Attention, imirhil se définit de lui-même comme étant un extrémiste (https://blog.imirhil.fr/2015/06/02/extremiste-fier-de-letre.html) pour TLS.
Cela influence les notes de son outil ....
-
Sur les notations, non. Elles ne sont basées que sur les recommandations diverses et variées que tu peux trouver sur Internet (ANSSI, NIST…) et sur les failles connues.
En plus, rien aujourd’hui ne peut justifier d’avoir en dessous de A, la compatibilité étant assurée (sauf android 2 et IE sous XP, qui sont des zombis plus qu’autres choses, et facilement compatibles si on utilise Firefox dessus…) avec EECDH+AES (http://"https://tls.imirhil.fr/suite") qui assure A minimum.
La seule vraie différence entre SSLLabs et CryptCheck est que je note la pire des suites disponibles (vous ne pouvez pas avoir moins que ce qui est indiqué) alors que SSLLabs note plus ou moins la meilleure (suppose que tu ne seras pas victime d’une downgrade attack ou que tu utilises un navigateur avec un support décent de TLS, et donc tu peux en pratique tomber sur une suite C ou un D en pratique alors que tu obtiens un A pour ton serveur).
-
Je ne suis pas spécialiste en cryptographie, je constate juste que des gens plus compétents que moi indiquent que celui-ci, s'il n'est pas publiquement cassé, a une possibilité non négligeable de l'être (et dans ce domaine-là, si on trouve quelque chose, on le garde pour soi), et donc j'explique dans mon message que, pour avoir une meilleure note à ce test, il faudrait supprimer 3DES.
On remarquera quand même que DES est très ancien et a pas trop mal résisté au temps. Est-ce que les nouveaux algo ont été suffisamment analysés? 8)
Et beaucoup de recherche en cryptanalyse est universitaire et librement accessible.
PS : Sachant que les navigateurs ne supportant pas mieux que 3DES sont, à ma connaissance, tous plus mis à jour et avec une sécurité déplorable, en dehors de la sécurité intrinsèque du protocole, ce n'est pas un joli cadeau de continuer à le supporter.
Je suis d'accord avec cette approche : se mettre en quatre pour supporter des vieilleries est une mauvaise idée, les vieilleries n'étant généralement plus supportées et pleines de trous.
-
On remarquera quand même que DES est très ancien et a pas trop mal résisté au temps. Est-ce que les nouveaux algo ont été suffisamment analysés? 8)
3DES date de 1999, AES de 2000. C’est équivalent en terme d’ancienneté donc.
AES a été très cryptanalysé (y compris par les plus grands, comme Bruce Schneier) et est considéré comme très fiable à l’heure actuelle.
ECDSA est bien plus ancien (1992), donc de bons retours déjà dessus.
La nouvelle crypto, comme ED25519, POLY1305 ou CHACHA20, est plus récente (2010-2015), mais il y a de bonnes cryptanalyses sur le sujet, et de fortes présomptions que c’est plutôt très robuste.
Le principal (et nouveau !) problème qui se lève est que toutes ces nouveautés sont issues du même et unique cryptologue : Daniel J. Bernstein.
-
3DES était déjà sur la sellette depuis un bout de temps (taille de clé de 112 bits seulement et taille de bloc de 64 bits, quand on recommande au moins 128 bits pour les 2).
Mais récemment, tout ce qui est < 128 bits en taille de bloc (3DES mais aussi IDEA) a été cassé officiellement :
- https://sweet32.info/
- https://www.openssl.org/blog/blog/2016/08/24/sweet32/
Les équipes de OpenSSL conseillent de considérer 3DES au moins aussi moisi que RC4, c’est dire :D
Je suis d'accord pour privilégier quelque chose de plus moderne à 3DES.
Mais l'argument comme quoi une clé de 112 bits réels pourrait être vulnérable, non vraiment, je n'achète pas. Il y aura bien un moyen plus facile d'attaquer n'importe quel système informatique que de cracker une clé de 112 bits!
La taille des blocs est un autre problème, qui dépend de l'utilisation du chiffre.
-
Mais l'argument comme quoi une clé de 112 bits réels pourrait être vulnérable, non vraiment, je n'achète pas. Il y aura bien un moyen plus facile d'attaquer n'importe quel système informatique que de cracker une clé de 112 bits!
C’est tout le soucis des tailles de clé : on connaît la taille théorique, mais on sait que la taille pratique est plus faible sans réellement connaître sa vraie taille.
Par exemple, on sait parfaitement que AES-128 n’est pas réellement en 128 bits, mais plutôte 126.1 bits max (ie une cryptanalyse existe qui casse une clé AES de 128 bits en moins de 2^126.1 tentatives).
Et on sait aussi que 3DES n’est très certainement pas un algo de 112 bits.
Ça cascade 3 tours de 56 bits (donc 168 bits théorique, ramené à 112 à cause des redondances), mais il y a de fortes suspicions que casser 1 des tours facilitera le cassage des 2 autres.
La meilleure cryptanalyse de 3DES le casse en 2^32 message en clair + 2^90 chiffrement DES, ce qui est TRÈS faible.
Sweet32 a par ailleurs montré que la complexité réelle d’un algo basé sur les blocs de 64 bits était en réalité plus proche de 27 bits de sécurité (2^27.6 requêtes de 4kB pour casser la clef).
La taille des blocs est un autre problème, qui dépend de l'utilisation du chiffre
Dans les 2 cas, c’est totalement déconseillé par l’ANSSI pour un usage après 2020 et d’utiliser au minimum des blocs et des clefs de 128 bits minimum pour un usage après 2020, et recommande même l’utilisation de 128 bits minimum dès aujourd’hui (Référentiel Général de Sécurité v2.03 du 21 février 2014, annexe B1, §2.1.2.1)
-
Clairement, 3DES n'est pas l'avenir et pour le présent si on peut éviter tant mieux.
Mais de là à mettre un F, je ne suis pas entièrement convaincu!
-
OpenSSL le considère comme « aussi mauvais que RC4 » et il a d’ailleurs été viré de OpenSSL immédiatement (et risque donc de dégager aussi vite de Firefox).
D’où la note de F actuelle.
Le prochain scoring lui accordera aussi un F : https://mensuel.framapad.org/p/scoring-cryptcheck
(Mais ça ne sera plus la pire note possible, qui deviendra G)
-
Ouais, pas F, mais G!^^
De toute façon, les grades sont incohérents avec les notes, dans cet outil.
Dans les pays où les élèves sont notés par les lettres, 68/100 ne donne jamais F...
-
OpenSSL le considère comme « aussi mauvais que RC4 » et il a d’ailleurs été viré de OpenSSL immédiatement (et risque donc de dégager aussi vite de Firefox).
Pardon, mais c'est pas un peu portnawak?
"2^32 message en clair + 2^90 chiffrement DES, ce qui est TRÈS faible." contre "tout le début est du déchet"????
-
Ouais, pas F, mais G!^^
De toute façon, les grades sont incohérents avec les notes, dans cet outil.
Dans les pays où les élèves sont notés par les lettres, 68/100 ne donne jamais F...
Mettons carrèment Z.
Si ça ne suffit pas, on passe à l'alphabet grec.
-
Ouais, pas F, mais G!^^
De toute façon, les grades sont incohérents avec les notes, dans cet outil.
Dans les pays où les élèves sont notés par les lettres, 68/100 ne donne jamais F...
C’est pour ça que je compte virer le scoring, qui ne sert à rien en pratique, pour ne garder que le ranking.
Pardon, mais c'est pas un peu portnawak?
"2^32 message en clair + 2^90 chiffrement DES, ce qui est TRÈS faible." contre "tout le début est du déchet"????
Respectivement 32 bits et 90 bits de sécurité, désolé mais c’est plus que très faible en 2016.
-
Tu peux préciser les "32 bits" de sécurité?
-
Tu peux préciser les "32 bits" de sécurité?
La meilleure cryptanalyse de 3DES le casse en 2^32 message en clair + 2^90 chiffrement DES, ce qui est TRÈS faible.
La sécu d’un algo est équivalente aux nombres de tentative qu’une attaque mettrait pour casser le chiffrement. Que ce soit du bruteforce pur ou non.
2^32 messages en clair, c’est équivalent à 32 bits de sécu (4 milliards d’essai environ). C’est même pire que du RC4-EXPORT qui fait 40 bits de sécu théorique ><.
-
Comment concrètement tu peux casser en 4 milliards d'essais?
-
Comment concrètement tu peux casser en 4 milliards d'essais?
C’est justement l’attaque Sweet32 (https://sweet32.info/) qui se base sur le paradoxe des anniversaires.
On Firefox Developer Edition 47.0a2, with a few dozen Workers running in parallel, we can send up to 2000 requests per second in a single TLS connection. In our experiment, we were lucky to detect the first collision after only 25 minutes (2^20.1 requests), and we verified that the collision revealed the xor of two plaintexts blocks. As seen previously, the full attack should require 2^36.6 blocks (785 GB) to recover a two-block cookie, which should take 38 hours in our setting. Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.
Impact and Mitigation
We have demonstrated the first concrete attacks on mainstream Internet protocols that exploit block cipher collisions. Our attacks can recover valuable secrets such as HTTP cookies and passwords in under 40 hours.
Mitigation
The obvious way to avoid these attacks is to stop using legacy 64-bit block ciphers.
-
D'accord mais pourquoi on n'a pas les outils pour détecter de telles attaques au moins contre HTTPS?
C'est habituel 785 GB transférés sur une seule connexion TLS?
-
Très difficile à détecter si tu n’as pas les outils adéquats. Outils impossbles à mettre en production partout (analyse de trafic type wireshark, les logs httpd ne suffisent pas car l’attaque a lieu sur la couche TLS et non HTTP) et encore plus sans nécessiter des moyens énormes (700 Go de logs à stocker :D par utilisateur :P) et sans ralentir très fortement tout ton trafic.
Tout au plus l’administrateur du site verra donc beaucoup de trafic passer, sans pouvoir mettre un nom sur ce qui est en train de véritablement se passer.
-
Mais justement, est-ce que tu as des cas où un seul utilisateur va générer 700 Go? :o
-
C’est le genre de détail que tu ne peux justement pas connaître.
Tu vas voir 700Go de trafic sur ton monitoring. Tu n’auras aucune idée si c’est pour 1 connexion ou 1000.
-
C'est évident que si tu ne fais rien pour avoir l'information, ce qui est très facile contrairement à ton assertion absurde, tu risques pas de l'avoir.
-
Ce n’est pas si facile que ça. Ça signifie devoir mettre en place une analyse réseau par IP.
C’est lourd, c’est chiant, ce n’est pas par défaut.
-
Cela implique de faire quelque chose qui n'est pas fait par défaut et qui représente bien un effort supplèmentaire. Idéalement je comprends qu'on préfère l'éviter.
MAIS en aucun cas cela n'implique de conserver l'ensemble des échanges pour analyse. Il suffit de garder une comptabilité du trafic échangé ce qui ne me semble pas insurmontable.
-
Ça nécessiterait du log à un niveau que tu ne VEUX pas sur de la production.
Parce que ça nécessite de mesurer le trafic au niveau applicatif (la mesure du volume d’une IP est difficile à faire avant, par exemple via iptables).
Et d’être capable de distinguer la part TLS handshake de la part TLS applicatif.
Ce qui ralentirait (sûrement fortement) ton trafic et te demanderait une complexité bien supérieure à juste une ligne de log dans ton apache|nginx.log
De stocker tout ça dans une bdd, pour être capable de faire de l’aggrégation sur des fenêtres glissantes.
D’avoir des outils d’analyse pour ressortir les gros consommateurs.
De recroiser pour savoir si c’est normal un tel trafic (par exemple qu’il n’a pas pompé une vidéo HD 4k de chez toi).
Sachant que ce qui se rapproche le plus de ce système est netflow, qui se base uniquement sur de l’échantillonnage du trafic justement pour des raisons de perfs et de faisabilité.
Et risque donc de laisser passer certains morceaux.
Bref, un truc qu’on est pas près d’avoir en production et qu’on aura a priori jamais.
Donc non, ce n’est pas détectable :)
-
Oui, parce que tu tiens à faire ça en bas niveau, alors qu'il faut le faire au sein de la couche TLS!
-
Non justement, je dis bien que c’est impossible à faire en bas niveau et que c’est nécessairement du ressort de l’applicatif.
Et l’IETF cherche déjà à miniser la latence induite par le handshake TLS et toi tu voudrais carrèment y planter un système de log et une base de données ? >< #MayIléfou
Sachant en plus que le handshake est géré par une bibliothèque (généralement OpenSSL) et non par l’applicatif directement (Apache par exemple), donc qu’il serait très difficile d’y faire entrer un système de journalisation sans tout casser.
-
Non justement, je dis bien que c’est impossible à faire en bas niveau et que c’est nécessairement du ressort de l’applicatif.
Ah d'accord, mais comme je n'ai jamais suggéré de le faire en bas niveau, on se demande bien pourquoi tu es allé proposer une idée aussi ridicule pour la démonter.
-
Parce que j’ai démontré après que ce n’est pas plus faisable en middleware (openssl générique) qu’en applicatif (trop de contraintes opérationnelles ou pas assez de détails accessibles).
Et donc que ce type d’exploit restera de toute façon très difficile à détecter.
Sans parler qu’on ne peut décemment pas se permettre de journaliser toutes les attaques TLS possibles, il y en a trop à trop d’endroits.
Bref, on vire les trucs pétés et basta.
Y compris en préventif, comme par exemple le cas de DHE, CBC et HMAC-SHA-1 qui seront les prochains à sauter (et dans cet ordre je pense, DHE a déjà beaucoup de plomb dans les ailes et CBC aussi). Ou en tout cas on anticipe dès à présent leur suppression possible n’importe quand en assurant une compatibilité avec le pas cassé. Actuellement il ne reste que ECDHE et ED25519 pour l’échange de clef, AES-GCM ou CHACHA20 pour le chiffrement, et SHA-2 ou POLY1305 pour les HMAC, on se doit de devenir compatible avec au moins tout ça (oui, ça impose dès à présent d’aller harceler ses utilisateurs pour qu’ils abandonnent Windows XP et IE<10).
-
DHE est sur le point d'être cassé, c'est ce que sous-entend?
-
Oui. Pas mal d’attaques sont apparues dernièrement, toutes sur le même principe. Ce qui montre une faiblesse quelque part.
Et voir aussi https://media.ccc.de/v/32c3-7288-logjam_diffie-hellman_discrete_logs_the_nsa_and_you, en particulier l’attaque par downgrade **MÊME SI TON NAVIGATEUR NE SUPPORTE PAS LA SUITE EN QUESTION** décrite vers 25min dans cette vidéo.
Et DHE pose des problèmes de latence avec des tailles de clé correctes (3072 bits et plus aujourd’hui), ECDHE est plus rapide.
-
Pour CBC, c’est dans le même état que DHE, en pire.
On sait que CBC est fuck de base, en particulier sous TLS<1.3 qui gère mal le padding **PAR DESIGN** (MAC-then-Encrypt au lieu de MAC&Encrypt ou mieux Encrypt-then-MAC).
Les bibliothèques tentent pour le moment de contenir le problème à gros coup de tricks et hacks, mais ça ne tiendra pas longtemps et on en est déjà à la 3ème couche de pansement…
Voir https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/ pour un bon résumé de la situation.
Le problème est plus violent que DHE en l’état, puisque que la compatibilité avec GCM est quasi-inexistante en dehors des toutes dernières versions d’OS ou de navigateur.
Alors que DHE peut être remplacé sans soucis par ECDHE aujourd’hui.
-
Ah ben tient, quand on parle de virer DHE… Chrome m’a grillé l’herbe sous le pied :D
https://www.chromestatus.com/feature/5128908798164992
Viré de Chrome à partir de la version 53. Opera va lui emboîter le pas.
-
Ça nécessiterait du log à un niveau que tu ne VEUX pas sur de la production.
Parce que ça nécessite de mesurer le trafic au niveau applicatif (la mesure du volume d’une IP est difficile à faire avant, par exemple via iptables).
Et d’être capable de distinguer la part TLS handshake de la part TLS applicatif.
Dans mon esprit, il s'agit de faire des statistiques au sein de la couche TLS, pas au dessus, pas en dessous.
Bien sûr il faudra patcher le code TLS. Et pas faire un bricolage dans une autre couche.
Ce qui ralentirait (sûrement fortement) ton trafic et te demanderait une complexité bien supérieure à juste une ligne de log dans ton apache|nginx.log
Je pensais à juste avoir un compteur de volume de données chiffrées dans une session TLS avec une même clef.
De stocker tout ça dans une bdd, pour être capable de faire de l’aggrégation sur des fenêtres glissantes.
Pardon? Je parle d'avoir un compteur!
Il me semble d'ailleurs vaguement me rappeler que CCMP a de tels compteurs!
-
Dans mon esprit, il s'agit de faire des statistiques au sein de la couche TLS, pas au dessus, pas en dessous.
Sauf que tu dois les remonter à la couche applicative, la couche TLS pure (OpenSSH) n’aurait aucun moyen fiable de loguer ce genre d’info (c’est ni plus ni moins qu’une bibliothèque du point de vue du serveur web, donc tu ne sais pas quels droits tu possèdes, quel utilisateur te fait tourner, tu n’as pas de connectivité réseau direct, etc).
Ce qui signifie modifier fortement le code existant et la compatibilité (ajout de whatmille callback de notification pour notifier l’applicatif) et conduira dans tous les cas à de GROSSES baisses de perf.
En prime, à la réflexion un tel système serait contre-productif, puisque serait à lui tout seul une nouvelle porte de DoS.
Et serait inutile, puisqu’au mieux tu pourrais savoir que tu a été attaqué (modulo un paquet de big data, vu que ce n’est pas parce que tu as beaucoup de négociation sur une même session qu’il s’agit d’une attaque, par exemple à cause du mécanisme de reprise de session (http://"https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/")) mais tu n’aurais alors aucun moyen de notifier l’utilisateur en question qu’il a été attaqué (nécessiterait de connaître aussi au pire son IP, au mieux son identifiant applicatif (login/username)) et ça sera dans tous les cas du a posteriori (impossible de bloquer l’attaque en temps réel sauf grosse analyse big data temps réel).
Et il n’y aurait pas qu’un unique compteur à développer, la pile TLS est remplie de merde de ce type (au pif le padding CBC, les downgrade attacks, les attaques par oracle…), le plus safe est donc de désactiver purement et simplement les algorithmes dorénavant non fiables (et se préparer dès maintenant à devoir virer les prochains condamnés).
Ce genre de vérification (analyse TLS + big data real time + chaîne de décision automatique) existe cependant réellement, c’est par exemple ce qui peut être fait sur les plates-formes Tilera (http://"https://www.ovh.com/fr/anti-ddos/tilera.xml") ou Arbor (http://"https://www.ovh.com/fr/anti-ddos/arbor.xml"), mais ça implique du DPI sur ton réseau et des équipements à plusieurs centaines de milliers d’euro pour ne pas introduire de latence notable (Tilera ~30.000€ pièce, idem pour un Arbor) et c’est du matériel à intégrer devant chacune de tes machines à protéger. Bref, hors de portée du grand public et non déployable partout (je doute même que OVH active en pratique le mode DPI TLS tellement les perfs s’en ressentiraient…).
Pardon? Je parle d'avoir un compteur!
Un compteur associé à une session TLS.
Session qui n’a de sens qu’au niveau applicatif (on parle de récupération de cookie par exemple, donc niveau HTTP), en bas niveau ça en a très peu.
Il me semble d'ailleurs vaguement me rappeler que CCMP a de tels compteurs!
Ça se base sur des compteurs, mais ça n’a strictement rien à voir.
Le compteur en question permet uniquement de calculer le chiffrement de bloc (le compteur est là uniquement pour éviter de réutiliser la même clé de chiffrement à chaque bloc tout en évitant la boucle de rétroaction de CBC), donc une fois la session TLS négociée.
On a donc largement dépassé la couche de négociation TLS (handshake) et on est déjà dans la couche de transmission des données (chiffrement).
-
Salut,
Vivien dit vouloir du A(+) sur tout les tests TLS.
Alors là, j'ai du boulot pour lui!^^
Grade F avec un score global de 68/100 (score le plus faible 50/100 en chiffrement) sur imirhil (alias CryptCheck) : https://tls.imirhil.fr/https/lafibre.info
Par contre, là, pas trouvé de doc...
J'ai toujours eu du mal avec l'idée que le fait de proposer des suites de chiffrement faibles devait faire baisser la note de chiffrement!
Intuitivement, la note de chiffrement est le max des suites proposées (qui sont utilisables parce que généralement présentes).
-
J'ai toujours eu du mal avec l'idée que le fait de proposer des suites de chiffrement faibles devait faire baisser la note de chiffrement!
Intuitivement, la note de chiffrement est le max des suites proposées (qui sont utilisables parce que généralement présentes).
Tu intuites mal :P
Sur TLS, le handshake de négociation de la suite de chiffrement qui sera utilisé n’est pas authentifié.
Et donc un attaquant en position de MitM pourra toujours forcer ta connexion (downgrade attack) à utiliser n’importe quelle suite de chiffrement supportée à la fois par le serveur et le client (en vrai c’est même parfois pire que ça, dans le cas de DHE, il suffit que l’un des deux supporte une suite faible). Et bien entendu, il choisira la suite la plus faible à sa disposition, et non pas la plus forte.
D’où ma notation : la sécurité garantie par le handshake est celle de la pire des suites disponibles, et non de la meilleure.