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.

 



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.





 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

 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.

 





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.



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