Auteur Sujet: Grade F (mais avec 68/100) d'après imirhil (CryptCheck)  (Lu 7125 fois)

0 Membres et 1 Invité sur ce sujet

aeris

  • Client OVH
  • *
  • Messages: 19
    • Imirhil
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #36 le: 28 septembre 2016 à 13:34:17 »
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).

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #37 le: 28 septembre 2016 à 13:38:37 »
DHE est sur le point d'être cassé, c'est ce que sous-entend?

aeris

  • Client OVH
  • *
  • Messages: 19
    • Imirhil
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #38 le: 28 septembre 2016 à 14:33:45 »
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 clef correctes (3072 bits et plus aujourd’hui), ECDHE est plus rapide.

aeris

  • Client OVH
  • *
  • Messages: 19
    • Imirhil
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #39 le: 28 septembre 2016 à 15:10:38 »
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.

aeris

  • Client OVH
  • *
  • Messages: 19
    • Imirhil
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #40 le: 28 septembre 2016 à 20:34:51 »
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.

corrector

  • Invité
Vulnérabilité d'un chiffrement par bloc de 64 bits
« Réponse #41 le: 01 octobre 2016 à 18:08:47 »
Ç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!

aeris

  • Client OVH
  • *
  • Messages: 19
    • Imirhil
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #42 le: 01 octobre 2016 à 21:16:49 »
Citer
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) 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 ou Arbor, 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…).

Citer
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.

Citer
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 clef 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).

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #43 le: 24 mai 2017 à 06:21:53 »
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).

aeris

  • Client OVH
  • *
  • Messages: 19
    • Imirhil
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #44 le: 24 mai 2017 à 10:27:47 »
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.

 

Mobile View