Et bien, de toute évidence, le proxy de ton entreprise déchiffre le flux SSL pour analyser le contenu comme il le fait pour des connexions non sécurisées. En pratique, lorsque tu établis une connexion HTTPS, le proxy se fait passer pour le serveur distant en générant un certificat SSL signé par l'AC de l'entreprise. Le certificat racine de cette AC étant poussé dans les magasins SSL sur les postes des utilisateurs via des procédure internes de l'entreprise, les navigateurs qui utilisent ce magasin (IE mais peut-être aussi Chrome) n'y voient que du feu. Ensuite, le proxy communique avec le serveur distant en SSL (HTTPS). La communication est donc chiffrée entre ton poste et le proxy ainsi qu'entre le proxy et le serveur distant mais le flux est bien en clair sur le proxy (c'est d'ailleurs bien le but : appliquer les mêmes règles de filtrage aux sites HTTPS et HTTP).
Normalement, l'entreprise doit vous signaler ce mode de fonctionnement.
Il est possible (c'est le cas là où je travaille) que certains sites, dans une liste de confiance, soient accessibles sans ce déchiffrement intermédiaire (chez nous, cela concerne la plupart des sites bancaires, les gros fournisseurs de messagerie, comme gmail, les sites gouvernementaux [impots.gouv.fr ;-)], etc). On peut vérifier cela en regardant l'émetteur du certificat SSL : s'il s'agit de l'AC de l'entreprise (xxxInfrastructureProxyCA) c'est déchiffré, sinon le flux reste bien confidentiel de bout en bout.
Note tout de même que ce procédé, mis en place pour augmenter la sécurité et protéger l'entreprise (sa responsabilité est-elle engagée en cas d'accès, depuis son réseau, à des sites "non légaux" ?) soulève aussi d'autres problèmes. En particulier, il devient compliqué de laisser l'utilisateur final choisir comment réagir en cas de certificat non valide : le certificat du serveur HTTPS n'étant pas transmis jusqu'au navigateur, on peut difficilement choisir d'accepter ou pas un certificat périmé, auto-signé ou signé par une AC autre que celles que l'on accepte habituellement (soit le proxy accepte tout, soit il n'accepte que ce qui est strictement valide par rapport à sa liste d'AC, soit, beaucoup plus rarement, il essaie de générer un certificat imitant le certificat final [périmé, auto-signé, ...]).
Au final, et dans le doute, considère que les administrateurs de ton entreprise peuvent intercepter tout ce qui passe, y compris quand l'accès au site se fait en HTTPS.
# Déchiffrement SSL
Posté par JJD . En réponse au message Certificats et autorités de certification proxy d'entreprise. Évalué à 10.
Salut,
Et bien, de toute évidence, le proxy de ton entreprise déchiffre le flux SSL pour analyser le contenu comme il le fait pour des connexions non sécurisées. En pratique, lorsque tu établis une connexion HTTPS, le proxy se fait passer pour le serveur distant en générant un certificat SSL signé par l'AC de l'entreprise. Le certificat racine de cette AC étant poussé dans les magasins SSL sur les postes des utilisateurs via des procédure internes de l'entreprise, les navigateurs qui utilisent ce magasin (IE mais peut-être aussi Chrome) n'y voient que du feu. Ensuite, le proxy communique avec le serveur distant en SSL (HTTPS). La communication est donc chiffrée entre ton poste et le proxy ainsi qu'entre le proxy et le serveur distant mais le flux est bien en clair sur le proxy (c'est d'ailleurs bien le but : appliquer les mêmes règles de filtrage aux sites HTTPS et HTTP).
Normalement, l'entreprise doit vous signaler ce mode de fonctionnement.
Il est possible (c'est le cas là où je travaille) que certains sites, dans une liste de confiance, soient accessibles sans ce déchiffrement intermédiaire (chez nous, cela concerne la plupart des sites bancaires, les gros fournisseurs de messagerie, comme gmail, les sites gouvernementaux [impots.gouv.fr ;-)], etc). On peut vérifier cela en regardant l'émetteur du certificat SSL : s'il s'agit de l'AC de l'entreprise (xxxInfrastructureProxyCA) c'est déchiffré, sinon le flux reste bien confidentiel de bout en bout.
Note tout de même que ce procédé, mis en place pour augmenter la sécurité et protéger l'entreprise (sa responsabilité est-elle engagée en cas d'accès, depuis son réseau, à des sites "non légaux" ?) soulève aussi d'autres problèmes. En particulier, il devient compliqué de laisser l'utilisateur final choisir comment réagir en cas de certificat non valide : le certificat du serveur HTTPS n'étant pas transmis jusqu'au navigateur, on peut difficilement choisir d'accepter ou pas un certificat périmé, auto-signé ou signé par une AC autre que celles que l'on accepte habituellement (soit le proxy accepte tout, soit il n'accepte que ce qui est strictement valide par rapport à sa liste d'AC, soit, beaucoup plus rarement, il essaie de générer un certificat imitant le certificat final [périmé, auto-signé, ...]).
Au final, et dans le doute, considère que les administrateurs de ton entreprise peuvent intercepter tout ce qui passe, y compris quand l'accès au site se fait en HTTPS.