certificat électronique

par **sunshine** » 15 Fév 2006 16:37

Bonjour,
Comment le certificat électronique résout le problème de "the man in the middle attack"?

par **S0l0** » 15 Fév 2006 17:50

Si le client est deja venu sur le serveur telechargez le certificat (ou s'il possede deja le certificat) un message d'erreur disant que le certificat est peut etre un faux apparait.
Il est possible aussi au serveur de mettre fin a la communication quand ce genre d'attaque est detecter (tres difficile a implementer).
Un certificat apporte une (pseudo) securite de plus car difficile a brute forcer ou casser par rapport a un mot de passe (ne pas oublier que la securite d'un element se mesure par rapport a l'element qui a la plus faible securite :: la chose entre le clavier et la chaise).

par **sunshine** » 15 Fév 2006 18:26

Merci S0l0, mais je suis dans le cas suivant :
deux personnes A et B veulent échanger des données et une personne C intercepte cette communication. S'il n'y a pas de certificat, C peut lire et modifier les données échangées par A et B. Avec les certificat, il ne peut plus modifier mais il peut comme même lire les données. Donc les certificats n'assurent-ils pas la confidentialité?

par **sunshine** » 15 Fév 2006 18:32

Autre question s'il vous plait: si les clés publiques sont diffusées dans des annuaires publiques, alors n'importe qui peut les acquérir et intercepter les messages de leurs propriétaires, non?

par **S0l0** » 16 Fév 2006 18:21

sunshine a écrit: si les clés publiques sont diffusées dans des annuaires publiques, alors n'importe qui peut les acquérir

oui tout a fait

sunshine a écrit:et intercepter les messages de leurs propriétaires, non?

Oui on peut les intercepter et ce meme si on n'a pas les certificats .
Mai dans le cas des certifs dans 99 % des cas ils utilisent la methode asymetrique cad : un certificat pour crypter et un autre (qui generalenment n'a rien avoir avec l'autre) pour decrypter; voir dans certains cas ils peuvent utiliser la methode diffie hellman cad un challenge defi-reponse (jamais vue)

par **sunshine** » 16 Fév 2006 18:33

merci
j'ai trouvé ma réponse :
il faut crypter le message à envoyer 2 fois : la première avec la clé privée de l'émetteur et la deuxième avec la clé publique du récepteur.
Au décryptage, il faut aussi déchiffrer le message reçu 2 fois : avec la clé privée du récepteur puis avec la clé publique de l'émetteur.
Si le message est lisible alors l'authentification et l'intégrité du message sont garanties car même s'il est intercepté, personne ne pourras le lire ou le modifier.

par **Walkyrie_II** » 16 Fév 2006 21:29

En plus il ne faut pas enployer SSLv1 et SSLv2 mais TSL ou SSL3

et SSH prendre uniquement la version 2

car meme avec des certicats ces proto (SSH 1.5, SSL1 SSL2) son vulnérable au "man in the midle" lors du handshake

par **sunshine** » 17 Fév 2006 09:15

Bonjour,
SSL 3.1 = TLS :wink:

en effet, IETF (Internet Engineering Task Force) a acheté le brevet SSL de Netscape et l'a rebaptisé TLS

par **Walkyrie_II** » 17 Fév 2006 19:49

d'ou mon smilley ... mais l'implementation n'est pas 100% compatible.

par **sunshine** » 18 Fév 2006 09:13

Bonjour,
comment elle n'est pas compatible?

par **Walkyrie_II** » 18 Fév 2006 21:38

RFC 2246 § 3

This document and the TLS protocol itself are based on the SSL 3.0
Protocol Specification as published by Netscape. The differences
between this protocol and SSL 3.0 are not dramatic, but they are
significant enough that TLS 1.0 and SSL 3.0 do not interoperate
(although TLS 1.0 does incorporate a mechanism by which a TLS
implementation can back down to SSL 3.0).

Tu peux le verifier avec un postfix et un thunderbird comme client (avec le tls_loglevel à 4) Pour le tunnel avec STARTTLS tu es en TLSv1 des 2cotés, pour une authentification via certificat tu passe en SSL3

certificat électronique

certificat électronique

Qui est en ligne ?