Certificate Verify Message

Question

Experts,

The last message sent from a client in an SSL handshake with client certificate authentication is the Certificate Verify message.

Here are my questions.

How is the Certificate Verify message constructed in an SSL Handshake?

How does a server validate the Certificate Verify message?

The information I have found is from the SSL 3.0 RFC.

https://tools.ietf.org/html/rfc6101#section-5.6.8

From my understanding, this is how the Certificate Verify is constructed and validated.

2 seperate SHA1 and MD5 hashes are generated from Client Hello and Server Hello Messages.
A digest is generate with the hashed data and the Private Key associated with the client certificate sent to the server in previous messages.
The server validates the Certificate Verify by calculating a digest using the client certificate and a hash of the Client Hello and Server Hello messages.
If the verification is successful from the server's perspective, then the client is authenticated.

If an SSL proxy exists between the client and the server, then this could break client certificate authentication. This is because the hashed data that is generated from the Client Hello and Server Hello would be different.

Any corrections on my understanding and guidance on client certificate authentication is appreciated.

Thanks for the help in advance.

Brooks

Accepted Answer

SSL 3.0 must not be used, refer to RFC 5246 (TLS 1.2) - 7.4.8. Certificate Verify for a more up-to-date specification.

How is the Certificate Verify message constructed in an SSL Handshake?

The Certificate Verify message is constructed by the client. It contains the signed hash of the handshake messages.

RFC 5246, section 7.4.8 about the handshake messages:

handshake_messages refers to all handshake messages sent or received, starting at client hello and up to, but not including, this message, including the type and length fields of the handshake messages. This is the concatenation of all the Handshake structures (as defined in Section 7.4) exchanged thus far.

RFC 5246, section 4.7 describes the digitally-signed attribute, section 7.4.1.4.1 describes the available signature types. Basically you will have this form:

    SignatureAndHashAlgorithm algorithm, consisting of:
        HashAlgorithm hash (4 for SHA-256 for example)
        SignatureAlgorithm signature (1 for RSA for example)
    Signature (a byte stream for a RSA signature for example)

How does a server validate the Certificate Verify message?

The server will buffer the handshake messages and should then obtain the same hash as the one supplied by the client. In order to authenticate the hash, the server must validate the signature.

This can be done by using the public key from the certificate that was provided by the client in the Client Certificate handshake message.

A MitM SSL proxy can indeed not authenticate itself against the server since it does not posess the client key and therefore cannot sign the parameters exchanged in the handshake.