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

[Rainer Jung <ra...@kippdata.de>]

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.

Regards,

Rainer

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

[Rainer Jung <ra...@kippdata.de>]

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.