1
$\begingroup$

Assume the same key pair is securely installed on a server and a single client and that the private key exists nowhere else. Can someone eavesdropping on a TLS handshake between the client and server learn anything about the private key or the session key that they wouldn't be able to learn if the client and server were using separate keys?

$\endgroup$
  • 2
    $\begingroup$ Do you mean the ephemeral DH keys used for the key exchange, ord the long term stataic keys of the server- and client-certificate? $\endgroup$ – mat May 11 '17 at 8:53
  • 1
    $\begingroup$ Or are you talking about TLS-PSK which is a special mode for use with pre-shared keys (like you have)? $\endgroup$ – SEJPM May 11 '17 at 13:45
  • 1
    $\begingroup$ I mean the same static private key and certificate. So the certificate the server uses to identify itself is the same one the client uses for authentication. $\endgroup$ – user695022 May 11 '17 at 14:27
1
$\begingroup$

No, there shouldn't be any weaknesses. The server key and client key don't interact within the protocol in such a way that relationships between the two matter.

Key exchange is done either using the server key (EG:TLS_(server key algo)_WITH_(cipher suite) modes) with the client encrypting a secret which only the server key can decrypt. Or with ephemeral keys (EG:TLS_(DHE/ECDHE)_(server key algo)_(cipher suite)). In both cases, relationships between the server and client keys do not matter.

Client certificate authentication is done separately from key exchange(step 5). The client signs a digest created from messages previously sent in the protocol.

  • An attacker with access to a client cannot get the client to perform the private operation on arbitrary data. They only control messages which contribute to the hash which the client signs.

  • An attacker with access to a server cannot use the server as a decryption oracle. They can submit arbitrary encrypted messages to the server as an "encrypted session key" the server will perform the private operation and attempt to use the result to derive a session key. The intermediate result, the result of the private operation is not accessible to the attacker in any useful way.

  • If TLS is configured to use an ephemeral key exchange, the client authentication is the same but the server is completely useless to an attacker since it just signs an ephemeral public key which the attacker does not influence.

In all cases, the keys never interact in the way you worry about (EG:DH mixing)

SSH is similarly immune. It uses ephemeral keys and client and server keys are used differently so that the client cannot hand back the signature supplied by the server.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.