Subject: [TLS] Why does the client has to send a Certificate Verify while the server does not?

From: [email-masked]
Date: Wed, 26 Nov 2008 02:36:56 +0000

Hi!

I've been reading RFCs concerning TLS and I have a question about  
Certificate Verify:

If I am not mistaken, Certificate Verify is a signature over the previous  
handshake messages using the client's private key, and the server
verifies it with the client's public key, which can be extracted from the  
previous client certificate message. If it matches, the server is sure that
the client actually owns the certificate (am I right?).

The above mechanism seems pretty secure to me, therefore, I'm wondering why  
the server is not required to send a verify as well? What if its
certificate is eavesdropped or stolen and someone else can use it as its  
own since there is no way to verify if it does own it? (if it copies its
domain name as well as its public key, etc.)
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Tue, 25 Nov 2008 19:32:42 -0800

> If I am not mistaken, Certificate Verify is a signature over the 
> previous handshake messages using the client's private key, and the server
> verifies it with the client's public key, which can be extracted from 
> the previous client certificate message. If it matches, the server is 
> sure that

The server is sure that the client has the private key associated with
the public key in the client certificate.  This is a good indicator that
the client is the entity named in the certificate.

> The above mechanism seems pretty secure to me, therefore, I'm wondering 
> why the server is not required to send a verify as well? What if its

There is no need for a server verify message since the server is
authenticated in other ways.  In an RSA key exchange, the server must
have the private key to decrypt a message from the client.  Therefore
if the connection is established, the server has the key.  In other
exchanges the server signs some parameters used to establish the
shared secret; the client verifies the signature, which authenticates
the server.

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Nov 2008 16:46:33 +0100 (MET)

> the client actually owns the certificate (am I right?).

It is the proof to the server that the client has access to the
private key associated with the presented client certificate.
Since the ServerHello contains a server random value it might be
considered a sufficiently robust challenge by the server.

> domain name as well as its public key, etc.)

The authentication of the Server in the SSL/TLS protocol is done
in a different fashion, most probably for efficiency; in order to
cut down on the number of public key operations that have to be
performed during the handshake.  The Server authentication is
assumed to be successful if the Server can participate the
encrypted communication i.e. successfully complete the key
exchange, and pass the check of the finished MACs. 

A digital signature by the server over handshake messages
(including the client hello with the clients random to server
as a challenge) would require both, the client and the server
to perform an additonal asymmetric crypto operation.

The regular/plain RSA ciphersuites do actually not provide a
feature that is often called "perfect forward secrecy" (PFS),
which means that an eavesdropper who is able to get his hands
on the servers private(!!) RSA key is able to decrypt the
entire communication (and all communication previously recorded).

AFAIK, this characteristic can be actively (ab)used by wireshark in
order to trace SSL/TLS-encrypted network communication.  If you
provide the servers private RSA key to wireshark, it can trace/visualize
not only the cleartext part of the SSL handshake, but also the
encrypted part for the plain/vanilla RSA ciphersuites (but not the
ones using DHE_RSA or RSA_EXP).

-Martin