Revoir une session SSL/TLS.
Le
Hercule POIROT
Bonjour,
Je cherche à revoir des surfs sur le WEB, y compris leur partie
sécurisée par SSL/TLS (exemple : mon CCP, ma BAL, ).
Connaissez-vous un navigateur ou un module externe d'émulation de carte
cryptographique qui permette d'enregistrer (dans un fichier log) le
secret et/ou la clé de session utilisé(e) dans une communication SSL/TLS ?
Sans doute dois-je utiliser un client WEB ecrit en PHP, Perl ou Java
pour intercepter les paramètres cryptographiques d'une telle session ?
A moins que de tels clients n'utilisent en fait qu'une librairie SSL/TLS
e C (compilée) qui garde "en elle" ces paramètres ; dans quel cas je
devrai me fournir une version avec symboles débogguage pour tracer une
session, non ?
Merci de m'aiguiller.
Cordialement,
H.P.
Je cherche à revoir des surfs sur le WEB, y compris leur partie
sécurisée par SSL/TLS (exemple : mon CCP, ma BAL, ).
Connaissez-vous un navigateur ou un module externe d'émulation de carte
cryptographique qui permette d'enregistrer (dans un fichier log) le
secret et/ou la clé de session utilisé(e) dans une communication SSL/TLS ?
Sans doute dois-je utiliser un client WEB ecrit en PHP, Perl ou Java
pour intercepter les paramètres cryptographiques d'une telle session ?
A moins que de tels clients n'utilisent en fait qu'une librairie SSL/TLS
e C (compilée) qui garde "en elle" ces paramètres ; dans quel cas je
devrai me fournir une version avec symboles débogguage pour tracer une
session, non ?
Merci de m'aiguiller.
Cordialement,
H.P.
Poser une question
implémente une attaque man-in-the-middle sur SSL/TLS avec un
certificat bidon. Le problème de cette solution réside dans les
avertissements multiples des navigateurs qui détectent l'attaque...
Whaouou !
Je vais tout de suite me renseigner sur cette méthode pour en comprendre
le fondement, les échanges entre le navigateur, le proxy, le VRAI site
WEB et la VRAIE ou FAUSSE C.A. (Certificate Authority) ; et notemment
comprendre à quel vrai certificat se substitue le certificat bidon.
Merci beaucoup.
Cordialement,
H.P.
OKAY, merci beaucoup.
Bien que je n'ai pas réussi à le faire marcher (2 tentatives seulement),
je comprend bien en quoi il peut m'aider à revoir les document échangés
lors de sessions SSL/TLS.
Toutefois, ça n'est pas vraiment ce que je voulais faire.
En effet, je souhaite conserver les avantages de SSL/TLS
(authentification, confidentialité, ...) tout en conservant la trace des
éléments clé (?clef?) déterminants pour décrypter a posteriori des
connexions tcp enregistrées par [t]ethereal ; flux que je 'visualiserai'
avec ssldump au lieu de tcpdump.
Ainsi, j'imagine que moi, utilisateur final qui utilise un navigateur
WEB et veux revoir de telles sessions SSL/TLS, je dois utiliser un
navigateur qui loggue les éléments clé - normalement volatiles - qui
fournissent la confidentialité aux sessions SSL/TLS.
n.b. : Il est bien évident que dans ce cas là, l'utilisateur ne peut
plus être duppé sur l'identité du serveur WEB, que la réciproque est
vraie (à cause de l'identification login/mot-de-passe), et que leur
communication demeurera confidentielle - sauf si l'utilisateur égare son
log d'éléments clé.
Si vous aviez des pistes pour cette fonctionnalité, ça m'intéresserai
beaucoup.
Merci d'avance.
Cordialement,
H.P.
connection-id), et il me semble qu'il faut avoir la clé privée du
serveur pour pouvoir décrypter le traffic avec ssldump...
Oh !!!
Mais non : cette protection sert juste à empêcher le Spoofing et les
D-o-S en 'live'. (C'est-à-dire pendant que le client et le serveur
communiquent)
Quant à l'utilisation de ssldump, voilà mon avis :
Sur un base disons Diffie-Hellmann, les deux extrémintés choisissent
chacune un secret (chacune à le sien), puis en utilisant leurs paires de
clef (elles s'échangent seulement leurs clés publiques), fabriquent une
première clef symétrique éphémère ; c'est une clef unique qui est
calculée aux deux bouts, et C'EST CETTE CLEF que je voudrais que mon
CLIENT WEB SAUVEGARDE - ainsi que les futures clefs de session. Pour le
reste des communications (de la couche application), les deux bouts
créent immédiatement une ou deux clés symétriques pour couvrir les deux
sens de communication avec une même clef ou deux clefs différentes : ce
sont de vraies clefs de session.
Donc, il doit suffire que le client sauvegarde son SECRET et
éventuellement les clés de session (pour ne pas avoir à les recalculer,
surtout qu'elees peuvent être changées assez souvent) pour déchiffrer
les flux avec ssldump, non ?
Merci de me dire où je me suis trompé, le cas échéant.
Cordialemen,
H.P.