Auteur Sujet: Grade F (mais avec 68/100) d'après imirhil (CryptCheck)  (Lu 7254 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 #24 le: 26 septembre 2016 à 11:59:56 »
Comment concrètement tu peux casser en 4 milliards d'essais?
C’est justement l’attaque Sweet32 qui se base sur le paradoxe des anniversaires.

Citer
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.
« Modifié: 26 septembre 2016 à 12:58:46 par TitiDu01 »

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #25 le: 26 septembre 2016 à 22:10:55 »
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?

aeris

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

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #27 le: 28 septembre 2016 à 07:30:00 »
Mais justement, est-ce que tu as des cas où un seul utilisateur va générer 700 Go? :o

aeris

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

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #29 le: 28 septembre 2016 à 10:37:32 »
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.

aeris

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

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #31 le: 28 septembre 2016 à 10:56:40 »
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.

aeris

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

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #33 le: 28 septembre 2016 à 12:32:36 »
Oui, parce que tu tiens à faire ça en bas niveau, alors qu'il faut le faire au sein de la couche TLS!

aeris

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

corrector

  • Invité
Grade F (mais avec 68/100) d'après imirhil (CryptCheck)
« Réponse #35 le: 28 septembre 2016 à 13:23:11 »
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.

 

Mobile View