Het certificaat bevat alleen de openbare sleutel - dat zijn openbare gegevens. Het belangrijkste onderdeel is niet het Certificate -bericht dat de klant verstuurt, maar het CertificateVerify -bericht dat de klant ook verstuurt. Dat bericht bevat een digitale handtekening die de klant berekent met zijn privésleutel en over de eerdere handshakeberichten. De aanvaller kan alles ruiken wat hij wil, hij krijgt de privésleutel niet, die niet wordt verzonden, en hij zal geen andere handtekening kunnen berekenen die van toepassing is op een andere SSL-uitwisseling.

Zelfs als het clientcertificaat zichtbaar is, kan de handtekening die is gemaakt met de privésleutel niet worden vervalst. Eerdere antwoorden hebben meer details gegeven over het Certificate Verify -bericht, maar het principe van de publieke / private sleutel is hetzelfde als voor servercertificaten (of asymmetrische cryptografische mechanismen in het algemeen): als u niet over de private key, kunt u zich niet voordoen als de entiteit waaraan het certificaat is uitgegeven.

Een secundair probleem van clientcertificaatverificatie is dat, als dit wordt gedaan tijdens de eerste handshake, het certificaat zelf zichtbaar is voor de afluisteraar duidelijk. In sommige gevallen is dit misschien niet bevredigend, aangezien dit de identiteit van de gebruiker kan onthullen (bijv. CN = Bob Smith ).

Een manier om dit te verhelpen is door client -authenticatie alleen in een heronderhandelde handdruk.

De klant ondertekent zijn bericht met zijn privésleutel die kan worden gedecodeerd met behulp van de openbare sleutel die openlijk wordt gedeeld en wordt vertrouwd als corresponderend met de klant. Omdat de server deze informatie kan decoderen met de openbare sleutel van de client, weet hij dat de informatie van de client afkomstig is. In het geval dat de volgende stap van de onderhandeling RSA is, is de inhoud van het pakket een deel van een sleutel die is gecodeerd met de openbare sleutel van de server, zodat alleen de server het tweede coderingsniveau kan decoderen.

Wat betreft een malafide gebruiker die het certificaat oppikt en probeert de sessie te kapen, de server heeft de openbare sleutel voor de gebruiker en de aanvaller zal geen informatie kunnen genereren die met die openbare sleutel wordt ontsleuteld, dus de verbinding is gegarandeerd dat de veroorzaker van de verbinding blijft de cliënt van de verbinding.

Als het cliëntcertificaat niet vooraf gedeeld is, zou het mogelijk zijn om te voorkomen dat een sessie met de cliënt wordt gevormd en in plaats daarvan een aanvaller te vervangen openbare sleutel, maar op dat moment zou de beoogde gebruiker niet in de sessie zijn en zou hij niet de sleutelinformatie voor de sessie hebben. Dezelfde MITM-preventie is van toepassing als normaal servercertificaat SSL na de eerste handshake, de verstrekking van een clientcertificaat garandeert eenvoudigweg dat de clientidentiteit hetzelfde blijft gedurende een of meer sessies.

Ook iets anders om te overwegen. Om het certificaat van een klant illegaal te maken, hebt u een certificaat nodig dat is ondertekend door een certificeringsinstantie - het is de taak van deze instantie om in te staan ​​voor wie u bent. De klant mag alleen de certificaten vertrouwen die zijn ondertekend door een betrouwbare CA.