Revoir une session SSL/TLS.

Sauf erreur de ma part, il suffit de passer par un proxy qui
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...

Sauf erreur de ma part, il suffit de passer par un proxy qui
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.

Sauf erreur de ma part, il suffit de passer par un proxy qui
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...

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.

SSL est protégé contre les attaques "replay" (par le biais d'un
connection-id), et il me semble qu'il faut avoir la clé privée du
serveur pour pouvoir décrypter le traffic avec ssldump...

SSL est protégé contre les attaques "replay" (par le biais d'un
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.

Ca marche peut-etre... Mais puisque l'attaque est si proche du texte en
clair, quel est l'avantage de sauver ces clés et non l'information en
clair ? Limiter l'information capturée côté client et privilégier
la capture réseau ?

Ca marche peut-etre... Mais puisque l'attaque est si proche du texte en
clair, quel est l'avantage de sauver ces clés et non l'information en
clair ? Limiter l'information capturée côté client et privilégier
la capture réseau ?

Ah, le voici l'avantage :

L'avantage est de pouvoir conserver les messages échangés en assurant la
pérennité de la preuve de l'authentification des entités qui dialoguent,
de l'authenticité, de la confidentialité et de la non répudiation de ces
messages.

Une telle preuve gardera sa valeur jusqu'au où la clé privée du serveur,
invoquée dans son certficat par auto-signature, sera cassée.

Bien sûr, on ne saura jamais à l'avance quand un quelconque hacker
(oubien L' / un utilisateur qui veut produire une fausse preuve) aura
cassé cette clé, mais on peut estimer 'extrèmement faible' la
probabilité qu'il la casse en moins de disons 3 mois.

Ainsi, notons S_0 (Esse zéro) la session SSL/TLS initiale, celle dont on
veut prouver indéfiniment avoir eu certains échanges avec un certain
serveur 'de confiance' un jour J.

Il suffit tous les trois mois d'avoir dans une session SSL/TLS S_N+1 un
dialogue avec un 'serveur d'echo' qui est 'de confiance' à qui on envoie
un condensat de la session S_N - il nous le renverra chiffré avec la
clef de session qu'on aura négotié sur la base se son [/ nos]
certificat(s) - et d'enregistrer cette session et le SECRET du client
pour garantir pour encore 3 mois un probabilité 'très très faible'
d'avoir pu imiter la preuve. Bien sûr, il faut que la confiance que l'on
ait dans notre serveur d'écho soit toujours 'au top', quitte à en
changer à chaque itération.

Ainsi, soit p_Trim la probabilité d'avoir pu falsifier la preuve au bout
de 3 mois alors, la probalilité p_An d'avoir pu la falisifier au bout
d'un an se calcule ainsi :

p_An = 1 - ( ( 1 - p_Trim ) ^ 4 )

Il y aura toujours moyen de choisir un p_Trim très faible pour avoir un
p_An ou un p_Decen suffisamment faible pour l'usage souhaité de preuve
juridique numérique, par exemple.

Pour rendre le procédé encore plus fiable, on peut utiliser dialoguer
avec deux serveurs SSL/TLS d'écho à chaque itération :

S_0 -> CONDENSAT(S_0)

CONDENSAT(S_0) -> S_1_A via serveur d'écho A
CONDENSAT(S_0) -> S_1_B via serveur d'écho B

S_1_A -> CONDENSAT(S_1_A)
S_1_B -> CONDENSAT(S_1_B)

CONDENSAT(S_1_A) et CONDENSAT(S_1_B) -> équivalent CONDENSAT(S_1) par
concaténation par example

CONDENSAT(S_1) -> S_2_C via serveur d'écho C
CONDENSAT(S_1) -> S_2_D via serveur d'écho D

S_2_C -> CONDENSAT(S_2_C)
S_2_D -> CONDENSAT(S_2_D)

CONDENSAT(S_2_C) et CONDENSAT(S_2_D) -> équivalent CONDENSAT(S_2) par
concaténation par example

...

CONDENSAT(S_N) -> S_N+1_Y via serveur d'écho Y
CONDENSAT(S_N) -> S_N+1_Z via serveur d'écho Z

S_N+1_Y -> CONDENSAT(S_N+1_Y)
S_N+1_Z -> CONDENSAT(S_N+1_Y)

CONDENSAT(S_N+1_Y) et CONDENSAT(S_N+1_Z) -> équivalent CONDENSAT(S_N+1)
par concaténation par example

Voilà.

Ainsi, au bout d'un an, on n'a utilisé que trois fois la continuation de
la preuve par une paire de serveurs d'écho, et on a :

p_An = 1 - ( ( 1 - p_Trim ) * ( 1 - ( p_Trim ^ 2 ) ) ^ 3 )

Car pour falsifier la preuve au delà de ses trois mois d'age, il faut
casser simultanément les clés privées de deux serveurs d'écho
indépendants pour falsifier la preuve.

On constate que cet idée, méthode et algorithme permet en outre de
choisir un p_Trim moins infinitésimal - donc plus facile à utiliser -
pour garder un p_An ou un p_Decen suffisamment faible pour l'usage
souhaité de preuve juridique numérique, par exemple.

Bien entendu, rien n'empêche d'utiliser simultanément d'avantage de
serveurs SSL/TLS d'écho.

Qu'on en utilise simultanément 2 ou plus, le premier maillon de notre
chaîne d'itérations est un peu faiblard : la connexion SSL/TLS
d'origine, avant la première continuation par serveurs SSL/TLS d'écho.

C'est pourquoi on pourrai imaginer, pour ce premier maillon et en
partenariat obligatoire avec le serveur 'de confiance' impliqué, avoir
une session SSL_Plus/TLS_Plus qui serai une session du genre SSL/TLS qui
authentifie et signe simultanément N fois le dialogue en utilisant N
paires de clés privées/publiquer associées à N certificats de N entités
réputées 'de confiance'. Mais une seule entité ne pouvant détenir, par
raison de sécurité, plusieurs clés privées, elle délèguerai les N
authentifications/signatures à N entités bien distinctes et 'de
confiance' via une connexion SSL/TLS classique.

Si toutefois cette session SSL_Plus/TLS_Plus était très difficile à
mettre en place, il suffirai provisoirement d'utiliser une sipmle
session SSL/TLS avec des algorithmes et des clés extrèmement forts pour
ce premier maillon uniquement.

Ainsi, notre chaîne aurait une solidité à toute épreuve de bout en bout.

---

Que pensez-vous de cette idée, méthode et algorithme pour pérenniser
durant des décennies une preuve numérique de l'authentification,
l'auhenticité, l'intégrité et la non répudiation de messages échangés
entre une société 'de confiance' et un de ses 'clients' ?

Tout commentaire sera le bien venu.

Cordialement,
H.P.

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-1903590565-1145655634=:18657
Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 20 Apr 2006, Hercule POIROT wrote:

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.

Pas moyen de faire ça avec un ssldump classique, faudra le patcher lui
aussi.

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.

Il faut modifier la couche SSL, pour qu'elle conserve le pre-master secret
(qui sert de pool d'aléa au client et au serveur). Sans vérifier plus
avant, je dirais qu'un simple tcpdump (ou équivalent) permettra de rejouer
la session en la déchiffrant. Dans les traces réseaux, tu as le traffic
SSL chiffré, et les messages de (re)négociations SSL. De cette manière,
ton "rejoueur" saura à quel moment il devra piocher dans le pool
d'entropie pour changer de clé.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
SM> Désolé (c'est quand-même terrible cette société oû l'on doit
SM> s'excuser d'être doué, vraiment...)
Si en + tu devais t'excuser d'être crétin t'aurais un job a plein temps
-+- RM in http://neuneu.ctw.cc - Là, ya indubitablement consensus -+-
---559023410-1903590565-1145655634=:18657--

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-33463914-1145655736=:18657
Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 21 Apr 2006, Hercule POIROT wrote:

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 ?

Ca ne se fera pas avec un ssldump standard, pas plus que ton avigateur ne
sera standard, puisqu'en standard, cette fonctionnalité n'existe pas.

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Subject: les torfousiens parlent aux tephalliens
Salut jean claude
Demain mardi, je t'emmène à 7h50 ?
-+- OB in Guide du neuneu usenet : dis manu, tu descends ? -+-
---559023410-33463914-1145655736=:18657--

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-1254324197-1145656677=:18657
Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT

Bonsoir,

On Fri, 21 Apr 2006, Hercule POIROT wrote:

L'avantage est de pouvoir conserver les messages échangés en assurant la
pérennité de la preuve de l'authentification des entités qui dialoguent, de
l'authenticité, de la confidentialité et de la non répudiation de ces
messages.

[...]

Que pensez-vous de cette idée, méthode et algorithme pour pérenniser durant
des décennies une preuve numérique de l'authentification, l'auhenticité,
l'intégrité et la non répudiation de messages échangés entre une société 'de
confiance' et un de ses 'clients' ?

C'est bien tordu, tout ça, pour finalement éviter une signature côté
client. Vous savez qu'une PKI, faite proprement, avec des HSM qui tiennent
la route, ça ne coûte pas si cher que ça? Et si vous voulez la faire vous
même, à coup d'OpenSSL, j'ai pondu en quelques heures un truc que j'ai
baptisé "La PKI du goret", ça s'interface avec un annuaire LDAP, ça
produit des CRL comme il faut, ça génère des numéros de série aléatoires
et garantis uniques (merci Thomas), et ça peut même utiliser un token pour
la clé privée de l'AC (pour ça, il faut un petit peu plus de temps, mais
pas des masses non plus).

Mis à part le fait qu'en France, la validité d'un contrat dans le BtoC
dépasse rarement les 10 ans (sauf pour le bancaire), et 5 pour le BtoB,
avez vous réellement une utilité pratique à tout ça, ou est-ce simplement
un sujet sur lequel vous réfléchissez, en espérant le vendre plus tard?

Enfin, dernier point, on sait protéger des secrets pendant 10 voire 20 ans
en utilisant de la crypto, mais au delà, bof. C'est pas le côté
cryptographique, tailles de clés, toussa qui gène, c'est le fait de donner
une assurance, une garantie, une preuve... Au delà de 20 ans, j'ai du mal
à conseiller mes clients avec uniquement de la crypto. Et comme je ne
serai pas à la retraite dans 20 ans, j'hésite :)
*Des* décennies, vous dites?

--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----

Et puis qu'est-ce-que tu viens faire sur fufe ?
Tenter de discuter avec des gens un peu iontelligents. Mais ils sont

rares sur fufe.
-+- Dr B in GNU : Ion fait s'qu'ion peut avec s'qu'ion a. -+-
---559023410-1254324197-1145656677=:18657--