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…).
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).