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.
