Pour faire simple: en asymetrique, un message signe avec un cle ne peut etre dechifre qu'avec l'autre cle.
Tu peux utiliser ca de deux facons:
- chiffre avec la cle publique, seul le possesseur de la cle prive peut dechiffrer: garantit la confidentialite, personne ne peut lire le contenu.
- chiffre avec la cle prive, tout le monde peut dechiffrer (la cle publique est, ben, publique): garantit l'authenticite (ie celui qui a envoye est bien celui que tu penses).
Partant de la, https fonctionne comme suit:
- requete du client au serveur: salut! Files moi ton cert publique
- reponse du serveur: tiens, voila, et au fait, files moi le tien tant qu'on y est. a ce point, les echanges sont en clair.
- le client verifie le certificat du serveur (cf plus bas), et envoie le sien au serveur, chiffre avec la cle publique du serveur. En https de base, le cert client est genere a la volee.
- le serveur verifie celui du client (ou pas, c'est optionel), et repond "ok, ca roule ma poule, envoie la sauce", chiffre avec la cle publique du client
- le client genere une cle symmetrique (une master key en fait, mais on va faire simple), la chiffre avec la cle publique du serveur et lui renvoie
- le serveur recupere la cle symetrique et ensuite, tous les echanges sont en chiffrage symetrique.
En gros, le protocole utilise:
- le chiffrement par cle prive pour garantir l'authenticite des hotes
- le chiffrement par cle publique pour garantir la confidentialite de l'echange de cle symmetrique.
- une fois le handshake ssl fini, on passe sur une crypto symetrique, vachement moins gourmande en ressources.
Si quelqu'un intercepte les communications pendant le handshake, l'asymetrique garantit que c'est pas lisible sans la cle privee, donc fiable.
De meme apres en symmetrique, c'est considere suffisament fiable sans la cle partagee, cle qui a ete generee a la volee pendant le handshake, et transmise de facon fiable, donc personne ne peut savoir ce qui se dit entre le client et le serveur.
L'idee derriere est en gros:
- on veut etre sur que les hotes sont bien ceux qu'ils pretendent. C'est pour ca qu'un certif pour www.google.com ne marchera pas pour google.fr
- la crypto symetrique marche plutot bien, mais l'echange de cle est tres problematique, donc on utilise de l'asymetrique, vachement plus fort et pratique, pour echanger les cles.
A noter qu'on parle de machines, donc un peu conne. Si tu possedes la cle privee d'un cert en google.com, alors tu es effectivement google.com aux yeux de toutes les machines. C'est pour ca que proteger ses cles prives est tres important.
Qu'est ce qui t'empeche de generer un certif pour google.com donc? La chaine de confiance. On introduit un tiers, dit de confiance, pour garantir que les certifs corrspondent bien aux entites physiques: tu fais confiance a verisign, qui en echange s'engage a verifier l'identite physique des personnes a qui ils delivrent un certificat.
Ces cert sont hashes, puis chiffres avec la cle privee de l'autorite, et ce hash inclu dans le cert.
De son cote, le client a une liste de certificat publique racines. Pour valider un cert: tu le hash, et tu dechiffre le hash inclu dans le cert avec la cle publique de l'autorite. Si ca correspond, le certificat publique est considere comme valide, et le process continue sans alerter l'utilisateur. Si ca match pas, le navigateur gueule comme un putois.
La partie client/serveur est trs robuste, et tres dur a casser, surtout en temps reel (mitm synchrone ou l'homme du milieu reencode tout a la volee).
La partie confiance, ben c'est de la confiance, donc c'est plus du ressort de l'etre humain qu'autre chose. Si verisign deconne a plein tube et files des certs pour google.com aux mechants hackers ukrainien, ca marche plus.
Si verisign se prends une requete de la nsa et doit leur donner leurs master keys privees, ca marche plus non plus, mais aucun protocole ne peut regler un probleme humain a cette echelle.
C'est pour ca aussi que le business de verisign peut etre vu comme douteux: tu paye un fort montant pour un hash de qq centaines de bits. Ca fait cher du bit au final, mais tu payes surtout pour l'infrastructure de verification derriere. D'aucuns diront que c'est des clampins, perso je m'engage pas sur cette pente savonneuse.
C'est l'avantage de ssl, c'est que ca passe tres tres bien a l'echelle d'un point de vue technique, et c'est aussi tres facile de revoquer des certificats si quelqu'un se met a deconner.
[^] # Re: Toujours pas clair pour un néophyte
Posté par groumly . En réponse au journal Scandale de la NSA et cryptographie, le vrai du faux. Évalué à 7.
Pour faire simple: en asymetrique, un message signe avec un cle ne peut etre dechifre qu'avec l'autre cle.
Tu peux utiliser ca de deux facons:
- chiffre avec la cle publique, seul le possesseur de la cle prive peut dechiffrer: garantit la confidentialite, personne ne peut lire le contenu.
- chiffre avec la cle prive, tout le monde peut dechiffrer (la cle publique est, ben, publique): garantit l'authenticite (ie celui qui a envoye est bien celui que tu penses).
Partant de la, https fonctionne comme suit:
- requete du client au serveur: salut! Files moi ton cert publique
- reponse du serveur: tiens, voila, et au fait, files moi le tien tant qu'on y est. a ce point, les echanges sont en clair.
- le client verifie le certificat du serveur (cf plus bas), et envoie le sien au serveur, chiffre avec la cle publique du serveur. En https de base, le cert client est genere a la volee.
- le serveur verifie celui du client (ou pas, c'est optionel), et repond "ok, ca roule ma poule, envoie la sauce", chiffre avec la cle publique du client
- le client genere une cle symmetrique (une master key en fait, mais on va faire simple), la chiffre avec la cle publique du serveur et lui renvoie
- le serveur recupere la cle symetrique et ensuite, tous les echanges sont en chiffrage symetrique.
En gros, le protocole utilise:
- le chiffrement par cle prive pour garantir l'authenticite des hotes
- le chiffrement par cle publique pour garantir la confidentialite de l'echange de cle symmetrique.
- une fois le handshake ssl fini, on passe sur une crypto symetrique, vachement moins gourmande en ressources.
Si quelqu'un intercepte les communications pendant le handshake, l'asymetrique garantit que c'est pas lisible sans la cle privee, donc fiable.
De meme apres en symmetrique, c'est considere suffisament fiable sans la cle partagee, cle qui a ete generee a la volee pendant le handshake, et transmise de facon fiable, donc personne ne peut savoir ce qui se dit entre le client et le serveur.
L'idee derriere est en gros:
- on veut etre sur que les hotes sont bien ceux qu'ils pretendent. C'est pour ca qu'un certif pour www.google.com ne marchera pas pour google.fr
- la crypto symetrique marche plutot bien, mais l'echange de cle est tres problematique, donc on utilise de l'asymetrique, vachement plus fort et pratique, pour echanger les cles.
A noter qu'on parle de machines, donc un peu conne. Si tu possedes la cle privee d'un cert en google.com, alors tu es effectivement google.com aux yeux de toutes les machines. C'est pour ca que proteger ses cles prives est tres important.
Qu'est ce qui t'empeche de generer un certif pour google.com donc? La chaine de confiance. On introduit un tiers, dit de confiance, pour garantir que les certifs corrspondent bien aux entites physiques: tu fais confiance a verisign, qui en echange s'engage a verifier l'identite physique des personnes a qui ils delivrent un certificat.
Ces cert sont hashes, puis chiffres avec la cle privee de l'autorite, et ce hash inclu dans le cert.
De son cote, le client a une liste de certificat publique racines. Pour valider un cert: tu le hash, et tu dechiffre le hash inclu dans le cert avec la cle publique de l'autorite. Si ca correspond, le certificat publique est considere comme valide, et le process continue sans alerter l'utilisateur. Si ca match pas, le navigateur gueule comme un putois.
La partie client/serveur est trs robuste, et tres dur a casser, surtout en temps reel (mitm synchrone ou l'homme du milieu reencode tout a la volee).
La partie confiance, ben c'est de la confiance, donc c'est plus du ressort de l'etre humain qu'autre chose. Si verisign deconne a plein tube et files des certs pour google.com aux mechants hackers ukrainien, ca marche plus.
Si verisign se prends une requete de la nsa et doit leur donner leurs master keys privees, ca marche plus non plus, mais aucun protocole ne peut regler un probleme humain a cette echelle.
C'est pour ca aussi que le business de verisign peut etre vu comme douteux: tu paye un fort montant pour un hash de qq centaines de bits. Ca fait cher du bit au final, mais tu payes surtout pour l'infrastructure de verification derriere. D'aucuns diront que c'est des clampins, perso je m'engage pas sur cette pente savonneuse.
C'est l'avantage de ssl, c'est que ca passe tres tres bien a l'echelle d'un point de vue technique, et c'est aussi tres facile de revoquer des certificats si quelqu'un se met a deconner.