TLS 1.3 enfin est validé par l'Internet Engineering Task Force

TLS 1.3 enfin est validé par l’Internet Engineering Task Force

Par Sébastien Gavois

Le 26 Mars 2018 à 09h17
Internet
1 min 23

TLS 1.3 enfin est validé par l'Internet Engineering Task Force

Cet accord arrive après quatre ans de discussions et pas moins de 28 brouillons. Le protocole de sécurisation des échanges TLS 1.3 apporte plusieurs changements par rapport à la mouture 1.2, dont la fin de certains vieux algorithmes, comme MD5 ou SHA-224.

Il permet également d'accélérer les premiers échanges (handshake), réduisant ainsi la latence des connexions. D'autres nouveautés comme Zero Round Trip Time Resumption (0-RTT) et TLS False Start sont également de la partie. Tous les détails de TLS 1.3 sont disponibles par ici.

Durant les discussions, certains (principalement des banques et des entreprises) voulaient intégrer une porte dérobée afin de pouvoir analyser le trafic, officiellement pour se prémunir d'attaque. Une proposition accueillie plus que froidement par la communauté et non retenue.

L'intégration dans les navigateurs modernes ne devrait pas poser de problème puisque Chrome, Edge et Firefox supportent déjà TLS 1.3 depuis quelques mois (via des versions préliminaires du protocole de sécurité).

Commentaires (23)


jb18v
Le 26/03/2018 à 08h30



Durant les discussions, certains (principalement des banques et des entreprises) voulaient intégrer une porte dérobée afin de pouvoir analyser le trafic, officiellement pour se prémunir d’attaque.





ahah mais allez vous faire <img data-src=" /><img data-src=" /><img data-src=" />


John Shaft Abonné
Le 26/03/2018 à 08h46

En attandant les implémentations dans les bibliothèques usuelles (OpenSSL, GnuTLS…) :)


tpeg5stan
Le 26/03/2018 à 10h26

Bonne nouvelle !


spidermoon
Le 26/03/2018 à 10h58

Encore faudra-t-il que cela soit utilisé, d’ici une dizaines d’années en entreprise.


ragoutoutou Abonné
Le 26/03/2018 à 11h29

Les entreprises qui ne savent pas évoluer au niveau cryptographie est un problème qui se règlera de lui-même.


Cclaudic Abonné
Le 26/03/2018 à 12h05

<img data-src=" /> J’ai bien ri avec la porte dérobée.


Triton Abonné
Le 26/03/2018 à 12h22

OpenSSL 1.1.1 est en beta pour commencer l’intégration. Pour GnuTLS, je ne sais pas.


wanou Abonné
Le 26/03/2018 à 12h25

Les entreprises déploient déjà des faux certificats en configurant les navigateurs ie des postes de travail pour les accepter. Ils peuvent ainsi faire du DPI sur tout le traffic (une attaque “man in the middle” en somme). Je ne vois pas ce qu’ils veulent de plus.

Pour les banques, je ne comprend pas ce qu’ils attendent d’une porte dérobée ni quels échanges ils veulent espionner ainsi.


ragoutoutou Abonné
Le 26/03/2018 à 13h02

Si j’ai bien compris, l’idée est qu’avec les versions de TLS précédentes, ce man-in-the-middle était débrayable et plus léger pour les proxys filtrants qui pouvaient laisser une partie des flux retomber en pass-trough sans plus faire de gymnastique cryptographique, alors qu’avec TLS 1.3, la charge pour les proxys filtrants est beaucoup plus lourde car le proxy est obligé de maintenir le décodage-réencodage&nbsp; …



Bref, ce que veulent les sponsores du ‘visualization plugin’, c’est de pouvoir analyser un max de sessions à moindre coût, avec comme cerise sur le gâteau la possibilité d’activer le m-i-t-m sur n’importe quel navigateur au lieu de devoir spécifiquement configurer ses certificats locaux (pratique pour mettre de l’écoute de masse en place chez un opérateur télécom)


CUlater
Le 26/03/2018 à 14h06



(0-RTT)

Macron approuve&nbsp;<img data-src=" />



/humour


Carpette
Le 26/03/2018 à 14h31

Tu veux dire en passant par un proxy qui lui va faire une vraie connexion HTTPS vers le site distant ? Autrement je ne vois pas comment c’est techniquement faisable.

Et de toute maniere ca doit se voir dans le navigateur qui au moins indiquera que le certificat ne correspond pas au site (sans etre necessairement invalide).


barbach Abonné
Le 27/03/2018 à 07h22

J’ai trouvé ça un peu dur aussi… <img data-src=" />


yvan Abonné
Le 27/03/2018 à 07h32







wanou a écrit :



Pour les banques, je ne comprend pas ce qu’ils attendent d’une porte dérobée ni quels échanges ils veulent espionner ainsi.





Quand tu as un management défaillant incapable de donner des objectifs rationnels aux équipes tu peux au moins pourrir la vie des gens en les empêchant de faire du surf de loisir et pratiquer le management par la terreur “à la Française”. Ouf les apparences sont sauves <img data-src=" />



wanou Abonné
Le 28/03/2018 à 18h57







Carpette a écrit :



Tu veux dire en passant par un proxy qui lui va faire une vraie connexion HTTPS vers le site distant ? Autrement je ne vois pas comment c’est techniquement faisable.

Et de toute maniere ca doit se voir dans le navigateur qui au moins indiquera que le certificat ne correspond pas au site (sans etre necessairement invalide).







Oui, cela se voit si ton navigateur est configuré comme à la maison.



Dans les sociétés qui pratiquent ce sport, les navigateurs clients officiels de la boite (IE en général), sont configurés pour accepter les pare-feux comme autorité de certification racine.



Dans firefox, il faut configurer une variable qui autorise cela en désactivant la vérification poussée des certificats.



Carpette
Le 29/03/2018 à 08h53

Ah ouais donc OCSP est desactive et un certficat racine est ajoute pour accepter tous les fake certificats crees a la volee par&nbsp; le routeur/pare-feu/autre c’est ca?


tpeg5stan
Le 29/03/2018 à 12h27

Tu as un article de 01net qui te propose quelques étapes pour vérifier rapidement :&nbsphttp://www.01net.com/actualites/votre-patron-espionne-t-il-vos-flux-ssl-faites-l…



Mais oui, l’idée c’est de faire du faux certificat de façon massive, même si cela engendre une baisse de la sécurité :&nbsphttp://www.bortzmeyer.org/killed-by-proxy.html


Carpette
Le 29/03/2018 à 13h14







tpeg5stan a écrit :



Tu as un article de 01net qui te propose quelques étapes pour vérifier rapidement :&nbsp;http://www.01net.com/actualites/votre-patron-espionne-t-il-vos-flux-ssl-faites-l…



Mais oui, l’idée c’est de faire du faux certificat de façon massive, même si cela engendre une baisse de la sécurité :&nbsp;http://www.bortzmeyer.org/killed-by-proxy.html





Apres pourquoi pas, je veux dire la machine appartient a l’employeur, il en fait ce qu’il en veut.

En tout cas c’est interessant je ne savais meme pas que ce type de technologie etait au point commercialement.

Il semble que le nom est DPI-SSL chez sonicwall par contre je n’ai pas trouve de traces chez les autres.



En tout cas, la machine physique qui l’implemente a interet d’avoir les reins solides, parce que generer du certif a la volee plus chiffrer/dechiffre 2 flux en temps reel * X connections, ca doit faire mal.



tpeg5stan
Le 29/03/2018 à 13h22







Carpette a écrit :



Apres pourquoi pas, je veux dire la machine appartient a l’employeur, il en fait ce qu’il en veut.&nbsp;



&nbsp;oui, enfin avec ce genre de raisonnement on sait aller très loin…

Normalement, même si l’employeur a le droit de stocket les connections, il faut que ce soit un tiers assermenté ou quelqu’un de ce genre qui regarde dedans, sinon ça compte comme une violation de la vie privée



Carpette a écrit :



En tout cas, la machine physique qui l’implemente a interet d’avoir les reins solides, parce que generer du certif a la volee plus chiffrer/dechiffre 2 flux en temps reel * X connections, ca doit faire mal.





c’est le défi avec TLS 1.3, avant si tu cassais un paquet, c’était plus facile pour décrypter les autres, là il faudra casser chaque paquet séparément, les machines ne sauront pas faire ça efficacement (si j’ai bien compris)



Carpette
Le 29/03/2018 à 13h30

Pour le premier point, c’est un probleme politique, personnellememnt je considere qu’au taf on taffe et que faire du prive est inapproprie (meme si je le fais massivement). Argumentation parfaitement attaquable, je n’ai pas d’avis definitif la dessus.



Pour le deuxieme point, je ne suis pas sur de comprendre, en quoi ca changerait quelque chose a la methode dont nous parlons ?

De plus, le DPI-SSL doit avoir des limites dans la mesure ou le certificat genere a la volee doit correspondre a un NDD bien precis, mais que celui-ci ne peut etre connu du routeur/pare-feu/autre que si le paquet transportant le “HTTP/1.1 GET blabla.fr” a ete dechiffre.



Je vais approfondir cette histoire, ca m’intrigue.


Carpette
Le 29/03/2018 à 15h50







Carpette a écrit :



De plus, le DPI-SSL doit avoir des limites dans la mesure ou le certificat genere a la volee doit correspondre a un NDD bien precis, mais que celui-ci ne peut etre connu du routeur/pare-feu/autre que si le paquet transportant le “HTTP/1.1 GET blabla.fr” a ete dechiffre.



Je vais approfondir cette histoire, ca m’intrigue.





Pour ceux que ca interesse, j’ai trouve la solution, c’est tout con.

Dans l’implementation actuelle de TLS 1.2⁄1.1 et probablement les vieilles versions (dont SSL), a chaque handshake SSL, le certificat est envoye en clair par le serveur, il suffit donc pour un parefeu/routeur/autre de le recuperer, lire le common-name (+ eventuellement les subject alt name) et reproduire un certificat avec les memes valeurs.



Je suis etonne, je trouve ca beaucoup plus sein d’etablir une connexion chiffre PUIS de demander un site donne et ensuite recevoir le certificat (ou potentiellement une reponse negative) que de recevoir directement un ou plusieurs certificats.



NSACloudBackup
Le 01/04/2018 à 09h57







Carpette a écrit :



Apres pourquoi pas, je veux dire la machine appartient a l’employeur, il en fait ce qu’il en veut.





Oui mais l’usage, lui, est privé. Si cette machine est utilisé par un employé pour consulté sa messagerie personnelle ainsi que son compte bancaire (et pourquoi pas son interface d’achat de cryptomonnaie) pendant sa pause (ce qui est attaquable j’en conçoit) et que le trafic est enregistré en clair via les méthodes énoncées plus haut, on se retrouve avec une foule d’information (mots de passes d’accès compris) en la possession de l’employeur (ce que je n’hésite pas à qualifier de vole par piratage). C’est un peu comme si je louai une voiture chez un professionnel et que tout ce que je fait monter dedans (famille comprise) appartenait à l’entreprise de location. Pas glop.

&nbsp;



Carpette a écrit :



Je suis etonne, je trouve ca beaucoup plus sein d’etablir une connexion chiffre PUIS de demander un site donne et ensuite recevoir le certificat (ou potentiellement une reponse negative) que de recevoir directement un ou plusieurs certificats.





&nbsp;Le problème est que la sécurisation d’un échange ne repose pas uniquement sur le chiffrement des données. Un élément tout aussi important est l’authentification des paires (ceux à quoi sert le certificat). Si tu chiffre avant d’envoyer le certificat, cela ne changerai rien au problème puisque tu ne saurai pas avec qui tu chiffre (donc potentiellement un attaquant - ton patron - ce qui revient au même que de ne pas chiffrer, les performances en moins). De manière générale, pour qu’un échange soit définit comme sécurisé, il faut réunir 4 éléments:

-La confidentialité

-L’intégrité

-La non-répudiation

-L’authentification

&nbsp;Tu peux te permettre d’envoyer le certificat en clair puisque il contient une signature in-reproductible validée par une autorité de certification déjà présente dans le navigateur client (donc non envoyé sur le réseau et donc infalsifiable par un attaquant). Une fois le pair authentifié, tu es sûr de pouvoir chiffrer avec la bonne personne. C’est pour cela que l’échange se produit dans cette ordre et non dans ce que tu trouvais plus logique.

&nbsp;





Carpette a écrit :



&nbsp;

De plus, le DPI-SSL doit avoir des limites dans la mesure ou le certificat genere a la volee doit correspondre a un NDD bien precis, mais que celui-ci ne peut etre connu du routeur/pare-feu/autre que si le paquet transportant le “HTTP/1.1 GET blabla.fr” a ete dechiffre.



À savoir que le nom de domaine du serveur avec lequel on échange en TLS transite bien en clair sur le réseau. Il est possible de le voir dans le champ “Extension: server_name” du paquet “Client Hello” au moment de la poignée de main TLS (handshake). Ce qui est chiffré, c’est l’URL complète (inutile pour l’authentification), soit ce qu’il y a après le .fr, .com, .org, etc… Cette information est donc récupérable sans trop de mal par un équipement intermédiaire.



Carpette
Le 01/04/2018 à 10h08

Ouais j’ai vu que c’était en clair via le SNI. Ca m’a surpris mais en fait c’est assez logique.

A savoir qu’il y a une proposition pour chiffrer ce champ


Fermer