En début d'année, dans le rapport sur les problèmes et l'accessibilité à Internet pour 2018-2019, nous avions déjà écrit que la diffusion de TLS 1.3 est inévitable. Il y a quelque temps, nous avons nous-mêmes déployé la version 1.3 du protocole Transport Layer Security et, après avoir collecté et analysé les données, nous sommes enfin prêts à parler des caractéristiques de cette transition.Les présidents du groupe de travail IETF TLS
écrivent :
«En bref, TLS 1.3 devrait jeter les bases d'un Internet plus sûr et plus efficace pour les 20 prochaines années.»
Le développement de
TLS 1.3 a duré 10 ans. Chez Qrator Labs, avec le reste de l'industrie, nous avons suivi de près le processus de création du protocole à partir du projet initial. Pendant ce temps, il a fallu rédiger 28 versions consécutives du projet pour qu'à la fin, en 2019, le monde ait vu un protocole équilibré et facile à déployer. Le soutien actif de TLS 1.3 par le marché est déjà évident: la mise en œuvre d'un protocole de sécurité éprouvé et fiable répond aux exigences de l'époque.
Selon Eric Rescorla (CTO de Firefox et seul auteur de TLS 1.3)
dans une interview avec The Register :
«Il s'agit d'un remplacement complet de TLS 1.2 utilisant les mêmes clés et certificats, de sorte que le client et le serveur peuvent communiquer automatiquement via TLS 1.3 si les deux le prennent en charge», a-t-il déclaré. "Il existe déjà un bon support de bibliothèque, et Chrome et Firefox incluent TLS 1.3 par défaut."
En parallèle, le groupe de travail IETF TLS finalise la
préparation d'un RFC qui déclare les anciennes versions de TLS (à l'exception de TLS 1.2 uniquement) obsolètes et inutilisables. Très probablement, le RFC final sera publié avant la fin de l'été. C'est un autre signal de l'industrie informatique: la mise à jour des protocoles de chiffrement ne doit pas être différée.
Une liste des implémentations actuelles de TLS 1.3 est disponible sur Github pour tous ceux qui recherchent la bibliothèque la plus appropriée:
https://github.com/tlswg/tls13-spec/wiki/Implementations . De toute évidence, l'adoption et le soutien du protocole mis à jour seront - et sont déjà en cours - des étapes rapides. Comprendre comment le cryptage fondamental est devenu dans le monde moderne s'est largement répandu.
Qu'est-ce qui a changé par rapport à TLS 1.2?
De l'
Internet Society Remarque :
"Comment TLS 1.3 rend le monde meilleur?"
TLS 1.3 inclut certains avantages techniques - comme un processus de prise de contact simplifié pour établir une connexion sécurisée - et permet également aux clients de reprendre les sessions avec les serveurs plus rapidement. Ces mesures sont conçues pour réduire le délai de configuration de la connexion et le nombre de connexions ayant échoué sur les canaux faibles, qui sont souvent utilisés comme excuse pour fournir uniquement des connexions HTTP non chiffrées.
Tout aussi important, la prise en charge de plusieurs algorithmes de chiffrement et de hachage hérités et non sécurisés qui sont toujours autorisés (bien que non recommandés) à être utilisés avec les versions antérieures de TLS, y compris SHA-1, MD5, DES, 3DES et AES-CBC, est supprimée. tout en ajoutant la prise en charge de nouvelles suites de chiffrement. D'autres améliorations incluent davantage d'éléments de négociation chiffrés (par exemple, l'échange d'informations sur les certificats est désormais chiffré) pour réduire le nombre d'indices pour un intercepteur de trafic potentiel, ainsi que des améliorations du secret de retransmission lors de l'utilisation de certains modes d'échange de clés, de sorte que la communication doit à tout moment rester. "sûr, même si les algorithmes utilisés pour le crypter seront compromis à l'avenir."
Développement de protocoles modernes et DDoS
Comme vous l'avez peut-être déjà lu, pendant le développement du protocole
et même après , de
graves contradictions sont apparues au sein du groupe de travail IETF TLS. Il est désormais évident que les entreprises individuelles (y compris les institutions financières) devront changer la façon dont elles sécurisent leur propre réseau afin de s'adapter au
parfait protocole de
secret en amont qui est désormais intégré au protocole.
Les raisons pour lesquelles cela peut être requis sont décrites dans un document
écrit par Steve Fenter . Dans un document de 20 pages, plusieurs exemples sont mentionnés lorsqu'une entreprise peut vouloir décrypter le trafic hors bande (ce que PFS n'autorise pas) afin de surveiller, de se conformer aux exigences réglementaires ou de fournir une protection contre les attaques DDoS au niveau de l'application (L7).
Bien que nous ne soyons certainement pas prêts à parler des exigences réglementaires, notre propre produit pour neutraliser les attaques DDoS appliquées (y compris une solution qui
ne nécessite pas la divulgation d'informations sensibles et / ou confidentielles) a été créé en 2012 avec PFS à l'esprit, il n'y a donc aucun changement à nos clients et partenaires dans Après la mise à niveau de la version côté serveur de TLS, leur infrastructure n'était pas requise.
De plus, depuis la date de mise en œuvre, aucun problème associé au chiffrement du transport n'a été identifié. Officiellement: TLS 1.3 est prêt à l'emploi en production.
Cependant, il reste un problème associé au développement de protocoles de nouvelle génération. Cela consiste en ce que généralement les progrès dans le développement de protocoles dans l'IETF dépendent fortement des résultats de la recherche scientifique, et l'état de la recherche universitaire dans l'industrie de la neutralisation des attaques par déni de service distribuées est très déplorable.
Ainsi, un bon exemple est la
section 4.4 du projet
de l'IETF «QUIC Manageability», qui fait partie de la future suite de protocoles QUIC: elle indique que «les méthodes modernes de détection et de neutralisation [attaques DDoS] incluent généralement une mesure passive utilisant des données sur les flux du réseau. "
Ce dernier, en fait, est très rare dans les environnements d'entreprise réels (et n'est que partiellement applicable aux fournisseurs Internet), et en tout cas ce n'est guère un «cas commun» dans le monde réel - mais il apparaît constamment dans les publications scientifiques, généralement non soutenues par des tests l'ensemble du spectre des attaques DDoS potentielles, y compris les attaques au niveau de l'application. Ce dernier, en raison au moins du déploiement global de TLS, ne peut évidemment pas être détecté par la mesure passive des paquets et des flux du réseau.
De même, nous ne savons pas encore comment les fabricants d'équipements pour la neutralisation des DDoS s'adapteront aux réalités de TLS 1.3. En raison de la complexité technique de la prise en charge du protocole hors bande, la mise à niveau peut prendre un certain temps.
Fixer les bons objectifs pour la recherche est un défi majeur pour les fournisseurs de services de neutralisation DDoS. L'un des domaines où le développement peut commencer est l'
équipe de recherche SMART de l'IRTF, où les chercheurs peuvent travailler avec l'industrie pour affiner leurs connaissances de l'industrie problématique et trouver de nouvelles directions de recherche. Nous sommes également prêts à accueillir chaleureusement tous les chercheurs, le cas échéant - vous pouvez nous contacter pour toute question ou suggestion liée aux études DDoS ou avec le groupe de recherche SMART à
rnd@qrator.net