----- Original Message ----- > From: "Kurt Roeckx via RT" <r...@openssl.org> > To: hka...@redhat.com > Cc: openssl-dev@openssl.org > Sent: Saturday, July 23, 2016 2:50:24 PM > Subject: Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in > handling malformed Client Key Exchange > messages in RSA key exchange > > On Fri, Jul 22, 2016 at 10:16:16PM +0000, David Benjamin via RT wrote: > > On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT <r...@openssl.org> > > wrote: > > > > > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote: > > > > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote: > > > > > the issue is present in master 0ed26acce328ec16a3aa and looks to have > > > > > been > > > > > > > > > introduced in commit: > > > > I tried what I thought was a fix for this which is to simply delete the > > > > lines: > > > > > > > > if (decrypt_len < 0) > > > > goto err; > > > > > > > > from ssl/statem/statem_srvr.c > > > > > > > > However your reproducer still indicates errors. I checked the message > > > logs > > > > and it should be now sending as many alerts as the original. The > > > difference > > > > however is that some of them will be sent immediately whereas > > > > originally > > > > they would be at the end of the handshake. > > > > > > > > Could your reproducer possibly not be expecting this? > > > > > > > > > sorry, I copied this part: > > > > > > > when the OpenSSL receives a Client Key Exchange message that has the > > > > encrypted > > > > premaster secret comprised only of zero bytes, or equal to server's > > > modulus, > > > > the server just aborts the connection without sending an Alert message > > > > > > from the DHE/ECDHE bug reports > > > > > > the expected behaviour is to continue the connection, but the server > > > should > > > select a premaster secret that was not provided by the client, instead > > > OpenSSL > > > just closes the connection > > > > > > > I don't believe this test is correct if the encrypted premaster is equal to > > the server's modulus. Such an encrypted premaster is a publicly invalid RSA > > ciphertext. It is perfectly reasonable to reject it early, should unpadded > > RSA_decrypt fail. The timing sensitive portion is the padding check itself, > > which this code should correctly defer failure of, to avoid the padding > > oracle. > > I think that the test suite should allow for either of 2 > behaviours in case of the public failures: > - It continues with a random premaster secret. > - It generates an error. > > From what I understand it now complains that we don't do the first, > so I think it should get changed to allow both behaviours.
I can change it to do that, thing is, that this behaviour will not be shared with NSS or GnuTLS (and likely other implementations), so it makes fingerprinting OpenSSL easier. > > It is true that it no longer sends an alert on public failures. Probably > > worth fixing. Meh. > > I don't care for which behaviour we go, and I guess that if we go > for generating an error we should send an alert. yes, if you opt for aborting early, to quote RFC, you MUST send an alert > I don't see the point in wasting time for what most likely seems > to be an attack. you don't have to actually perform the RSA operation, but IMHO the handshake should continue > What I don't understand currently is that it also rejected a > ciphertext with all 0's? Were it too many 0's? yes, there are few tests with 0's, some of them will have too many 0's :) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4623 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev