Fix SSL 4.0.1 handshake bug

[Paul Guyot]

Hello,

There is a bug in SSL 4.0.1 handshake from the client side. When a client certificate is used, SSL 4.0.1 filters ciphers to only send those compatible with the certificate (e.g. of the same algorithm dsa/rsa, and in the case of RSA, it depends on the key usage extension of the certificate).

This behavior differs from common implementations (e.g. openssl s_client) and from what the TLS 1.0 specification says.

RFC2246 mentions filtering cipher suites based on the *server* certificate (7.4.2). The public key in the server certificate is sent to the client to encrypt the pre-master.

However, RFC2246 does not say clients should do the same with the client certificate. The key in the client certificate is never used to encrypt any key (therefore, there is no reason to filter on keyEncipherment usage), it is only used to sign the exchange so far *if the certificate has signing capability* (7.4.6, 7.4.8). As a result, the client should send all the ciphers it is capable of using (this is what openssl s_client as well as {ssl_imp, old} does).

Since openssl blindly sends all the cipher suites, this is what I suggest and what is implemented in the patch.

However, I am not sure if the client should refuse to send the certificate verify message if the certificate usage extension does not include digitalSignature (and the critical bit is set ?).

A patch with a non-regression test is available here:

git fetch git://github.com/pguyot/otp.git pg/fix-ssl-handshake-client-certificate
http://github.com/pguyot/otp/commit/0975941a5b2684158ec8e94107a531f12827ca66

Paul
-- 
Semiocast                    http://semiocast.com/
+33.175000290 - 62 bis rue Gay-Lussac, 75005 Paris