(Es gab eine Diskussion zu diesem Thema in this question, obwohl es einige Male bearbeitet wurde, so kann es verwirrend sein.)
Der öffentliche Schlüssel im Serverzertifikat nur während des Handshakes verwendet wird. Während des Handshakes verhandeln der Client und der Server einen geheimen gemeinsamen Schlüssel (einen neuen für jede Sitzung), den sie für die eigentliche Verschlüsselung verwenden.
Wie dieses Geheimnis ausgehandelt wird, hängt von der Verschlüsselungssuite ab: RSA or Diffie-Hellman Schlüsselaustausch. Wenn der RSA-Schlüsselaustausch verwendet wird, verschlüsselt der Client das Pre-Master-Secret und sendet es an den Server (der als einziger es entschlüsseln kann). Bei Verwendung von DH überprüft der Client die Signatur der temporären Parameter, die vom Server während der DH-Vermittlung gesendet werden: Das Endergebnis ist auch ein gemeinsames Pre-Master-Secret. Dies wird dann mit den ausgetauschten Zufallswerten von beiden Parteien verwendet, um das Hauptgeheimnis zu berechnen.
Weitere Details finden Sie im TLS-Spezifikationsteil "Handshake Protocol Overview".
Neben Ihrer richtigen Antwort gibt es einen SSL-Modus, bei dem der Server sogar ein neues Schlüsselpaar für jeden Client generiert - er heißt "SSL null auth", weil er keine Authentifizierung des Servers erlaubt. Daher ist es standardmäßig in allen Clients deaktiviert, die ich kenne. – Robert
@Robert Ich denke du sprichst von 'DH_anon' Cipher Suites (der' TLS_NULL_WITH_NULL_NULL' ist ein anderer Fall). Alle TLS-Versionen raten von ihrer Verwendung ab, aber TLS 1.2 ist stärker formuliert ("* Diese Chiffre-Suites dürfen NICHT von TLS 1.2-Implementierungen verwendet werden, es sei denn, die Anwendungsschicht hat ausdrücklich einen anonymen Schlüsselaustausch angefordert. *"). Technisch erzeugen die DHE-Chiffre-Suiten jedes Mal neue (DH) Schlüssel (sogar mit RSA/DSS-Authentifizierung). – Bruno