Rob Dugal <[EMAIL PROTECTED]>: > I believe there is a bug in openssl function RSA_padding_check_SSLv23(). > This function is supposed to verify that the data is padded with > special PKCS #1 padding as described in SSL 3.0 draft/RFC 2246, App. E.2
> Run the server without support for SSL3, and specify only a RSA ciphers. > bash$ openssl s_server -accept 9990 -no_ssl3 -www -cipher RC4-MD5 > > Run the client without support for tls1 > bash$ openssl s_client -connect localhost:9990 -no_tls1 > > > Here is the server output: > Using default temp DH parameters > ACCEPT > 10386:error:04072073:rsa routines:RSA_padding_check_SSLv23:sslv3 rollback > attack:rsa_ssl.c:139: > 10386:error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check > failed:rsa_eay.c:341: > 10386:error:140BB004:SSL routines:SSL_RSA_PRIVATE_DECRYPT:nested asn1 > error:s2_srvr.c:966: > 10386:error:140EC071:SSL routines:SSL2_READ_INTERNAL:bad mac > decode:s2_pkt.c:265: > Since the server cannot negotiate SSL2, but the client has requested SSL3, the > special PKCS #1 padding is required. Exactly, and this is why the handshake *must* fail. The only common protocol in the above case is SSL 2.0, but the special PKCS #1 padding instructs the server to refuse rolling back to SSL 2.0. 'openssl s_server -no_ssl3' (which leaves SSL 2.0 and TLS 1.0 enabled and disables only the intermediate protocol version, SSL 3.0) is a bad choice: Automatical protocol version negotion in SSL/TLS assumes that implementation support consecutive protocol versions. (Had you run the test the other way around ['s_server -no_tls1' and 's_client -no_ssl3'], the handshake would obviously have to fail because it is the server that picks the protocol version for the connection -- SSL 3.0 in this modified scenario, i.e. a protocol not support by the client.) > With the suggested fix the above test can successfully handshake. It is intentional that the handshake fails. Note that the error is detect within the SSL 2.0 implementation (s2_pkt.c, s2_srvr.c). Whenever an SSL/TLS server detects the special padding in a connection for which protocol version SSL 2.0 has been chosen, it must interpret this as a protocol rollback attack unless SSL 2.0 is the only protocol version enabled in the server. Your suggested change would reverse the test condition, which cannot be correct. In those cases where special padding should not abort the SSL 2.0 handshake (because the server supports no newer protocol), the test must be completely disabled. -- Bodo Möller <[EMAIL PROTECTED]> PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
