I can't seem to make any sense out of the following vulnerability in OpenSSL:
DH client certificates accepted without verification [Server] (CVE-2015-0205) ============================================================================= Severity: Low An OpenSSL server will accept a DH certificate for client authentication without the certificate verify message. This effectively allows a client to authenticate without the use of a private key. This only affects servers which trust a client certificate authority which issues certificates containing DH keys: these are extremely rare and hardly ever encountered. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team.
The reason why the above does not make sense is that when a DH certificate is used by the client, the client is not expected to send a Certificate Verify message, a per RFC 5246, section 7.4.8:
This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters).
And here is what RFC 5246, section F.1.1.3 says:
When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSA or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server. If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange. Note that in this case the client and server will generate the same Diffie-Hellman result (i.e., pre_master_secret) every time they communicate. To prevent the pre_master_secret from staying in memory any longer than necessary, it should be converted into the master_secret as soon as possible. Client Diffie-Hellman parameters must be compatible with those supplied by the server for the key exchange to work.
Moreover, I fail to see how one could impersonate the client (i.e. compute the pre_master_secret) without knowing the client's secret key.
I can see how a bug in OpenSSL could allow an attacker to bypass authentication, for example if OpenSSL would accept DH parameters in the Client Key Exchange message, i.e. if OpenSSL did not properly enforce this part of RFC 5246, section 7.4.7:
When the client is using an ephemeral Diffie-Hellman exponent, then this message contains the client's Diffie-Hellman public value. If the client is sending a certificate containing a static DH exponent (i.e., it is doing fixed_dh client authentication), then this message MUST be sent but MUST be empty.
But the fix does not support this interpretation. Indeed, it appears to require a Certificate Verify message!
Can anyone make sense of this?