Je peux me tromper mais il me semble que le système SSL est bien foutu.
1-Etant au milieu tu peux converser en SSL avec le client, comprendre ce qu'il veut, forwarder en SSL au serveur. Jusque là pas de problèmes et un proxy HTTPS qui lit le contenu marche.
client -> proxy , proxy -> serveur
2-Par contre là où ça se corse c'est à cause des signatures. Si il s'agit d'un certificat auto-signé, que le client ne l'a jamais rencontré : pas de différence, il aura un certificat autosigné par ton proxy, il ne verra pas la différence.
3- Si le certificat est signé par Verisign par exemple (comme c'est le cas pour n'importe quel gros site sérieux) alors ton proxy aura bien du mal à faire passer son faux certificat SSL pour un vrai. Le client s'en appercevra car au lieu de naviguer de manière transparente il aura probablement une popup de son navigateur lui disant que le certif n'est pas signé .. louche pour un site connu.
Si l'admin est rusé il devra passer sur les postes clients et dévinir le certificat de son proxy comme un certificat "de confiance" pouvant certifier les autres (pour éviter la popup louche).
4- Si par contre le client est déjà passé sur le site, quel que soit le cas, le navigateur remarquera le changement de certif et sortira une popup louche. L'utilisateur averti comprendra vite qu'il y a un truc anormal (et ira gueuler sur l'admin au nom de la vie privé, blabla ...)
Ce que fait http://www.vroyer.org/sslstripper/(...) c'est qu'ils ont visiblement un certif signé par verisign qui les autorise à signer d'autres sous certif. Ces derniers seront reconnus comme "de confiance" par le navigateur sans toucher à la conf, du coup le (3) passe tout seul. Tu n'as probablement pas cette chance (je doute que ce type de pouvoir soit commun sinon ca foutrait toute la chaine de confiance et le buziness de verisign par terre).
# Re: L'histoire d'un gentil admin et d'un monstrueux https.
Posté par Éric (site web personnel) . En réponse au journal L'histoire d'un gentil admin et d'un monstrueux https.. Évalué à 1.
1-Etant au milieu tu peux converser en SSL avec le client, comprendre ce qu'il veut, forwarder en SSL au serveur. Jusque là pas de problèmes et un proxy HTTPS qui lit le contenu marche.
client -> proxy , proxy -> serveur
2-Par contre là où ça se corse c'est à cause des signatures. Si il s'agit d'un certificat auto-signé, que le client ne l'a jamais rencontré : pas de différence, il aura un certificat autosigné par ton proxy, il ne verra pas la différence.
client -> (proxy avec faux certif ssl), proxy -> serveur (vrai certif ssl)
3- Si le certificat est signé par Verisign par exemple (comme c'est le cas pour n'importe quel gros site sérieux) alors ton proxy aura bien du mal à faire passer son faux certificat SSL pour un vrai. Le client s'en appercevra car au lieu de naviguer de manière transparente il aura probablement une popup de son navigateur lui disant que le certif n'est pas signé .. louche pour un site connu.
Si l'admin est rusé il devra passer sur les postes clients et dévinir le certificat de son proxy comme un certificat "de confiance" pouvant certifier les autres (pour éviter la popup louche).
4- Si par contre le client est déjà passé sur le site, quel que soit le cas, le navigateur remarquera le changement de certif et sortira une popup louche. L'utilisateur averti comprendra vite qu'il y a un truc anormal (et ira gueuler sur l'admin au nom de la vie privé, blabla ...)
Ce que fait http://www.vroyer.org/sslstripper/(...) c'est qu'ils ont visiblement un certif signé par verisign qui les autorise à signer d'autres sous certif. Ces derniers seront reconnus comme "de confiance" par le navigateur sans toucher à la conf, du coup le (3) passe tout seul. Tu n'as probablement pas cette chance (je doute que ce type de pouvoir soit commun sinon ca foutrait toute la chaine de confiance et le buziness de verisign par terre).