git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: t/security/CVE-2009-3555.t fails in 2.4.37 with TLS 1.3 - also false positive?


Can anyone comment on the below, especially whether this test should be disabled when used with TLS 1.3 (modern access) and whether it is OK (a wrong test definition) for 1.3 to actually handle the prefix attack request?

Regards,

Rainer

Am 20.10.2018 um 08:16 schrieb Rainer Jung:
Test t/security/CVE-2009-3555.t (hardening against MITM SSL-renegotiation) fails in 2.4.37 when actually using TLS 1.3.

It is not that easy to use TLS 1.3 for this test. The test uses a raw SSL socket created by Net::SSL, but that module is outdated and does not support TLS 1.3.

I patched TestRequest.pm to use IO::Socket::SSL instead and can see, that it actually uses TLS 1.3 and the test fails at the critical last check. With TLS 1.2 the request that triggers a reneg but also has a pipelined request behind it triggers a "Connection: close" and that is tested in this last test. With 1.3 the server handles both the request that triggers the reneg as well as the pipelined on after it. That one fails with 400, because it does not have a host header, but it I add the host header, it results in a 404 not found due to the garbage URL.

What I am not sure about: CVE-2009-3555 ist mostly about a MITM attack for SSL renegotiations. The fix should have gone into OpenSSL itself, at least as far as I understand it. So it seems that our CVE-2009-3555.t test only checks, whether we have our workaround for non-safe OpenSSL in place. Because I expect TLS1.3 and any OpenSSL version supporting it not being affected by CVE-2009-3555, that would be a false positive as well.

Does that sound reasonable?

I will commit my TLS 1.3 patches for the test framework. I hope I doesn't break stuff, but it seems important to be able to run tests with the new protocol.