"Secure Renegotiation (RFC 5746) Not supported / VULNERABLE (NOT ok)" is displayed even though renegotiation is not supported

[yuki-hirano-dev]

Which version are you referring to
3.0.x or 3.2? (please check also how old your version is compare to the ones here)
3.2

./testssl.sh -b 2>/dev/null | head -4 | tail -2
  testssl.sh version 3.2rc3 from https://testssl.sh/dev/
  (b5ad5bd 2024-12-06 15:03:47)
./testssl.sh -b 2>/dev/null | head -16 | tail -3
  on ubuntu:./bin/openssl.Linux.x86_64
  built: Sep  1 14:03:44 2022, platform: linux-x86_64
  Using bash 5.0.17
uname -a
  Linux ubuntu 5.15.0-125-generic #135~20.04.1-Ubuntu SMP Mon Oct 7 13:56:22 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

what was happening
Our TCP server does not support Secure Renegotiation (RFC 5746) and never reply to renegotiation request.
So I think our TCP server is NOT VULNERABLE but detected as VULNERABLE (NOT ok) by testssl.sh.
TCP server's users may think that our TCP server is not secure and some of them will contact us to know whether this is vulnerable or not.
https://github.com/drwetter/testssl.sh/blob/b5ad5bd859357c8c0eaa986c1fb926bfb7c7df3d/testssl.sh#L17117

what did you expect ?
If the TCP server does not support Secure Renegotiation (RFC 5746) and never reply to renegotiation request then testssl.sh detects as "Secure Renegotiation (RFC 5746) Not supported / not vulnerable (OK)".
In this cace, I prefer that "Grade warning Secure renegotiation is not supported." message is not displayed.

[Tazmaniac]

Please test my branch https://github.com/Tazmaniac/testssl.sh/tree/client-renego-refactoring
Some possible false positives are fixed.

Server which does not implement RFC 5746 could implement (insecure) client initiated renegotiation. So the two are not directly linked and should be independently tested.

[Tazmaniac]

Ok I overlooked your report.
Because client initiated renego is not supported you want to elide the fact that RFC 5746 is not supported.

I think you miss some points. Server initiated renegotiation may still be initiated and will be insecure without RFC 5746.
You could chose to not implement client initiated renegotiation which is great (and no longer exist in TLSv1.3) but it does not prevent you to chose/use a TLSv1.2 stack which is properly "secured" by implementing RFC 5746 even if you do not plan to do server initiated renegotiation.

[drwetter]

@yuki-hirano-dev : A statement like "our server" but not handing over details about the server is like your grandma is telling you "my computer doesn't work". Therefore there's a section in the template which you omitted.

Please disclose the IP here or send it to the contact in the template.

[yuki-hirano-dev]

Thank you for your kind comments.
I have understood, so please close this issue.

@drwetter :

Please disclose the IP here or send it to the contact in the template.

I am sorry, but I cannot disclose the IP here.
So I describe example test steps using wolfssl's echoserver.

1. git clone https://github.com/wolfSSL/wolfssl.git
2. cd wolfssl
3. git checkout -b v5.7.4-stable refs/tags/v5.7.4-stable
4. ./autogen.sh
5. ./configure --enable-renegotiation-indication
6. make
7. ./examples/echoserver/echoserver
8. Launch another terminal and cd (testssl.sh's directory)
9. ./testssh localhost:11111

Result:
Secure Renegotiation (RFC 5746) Not supported / VULNERABLE (NOT ok)
Secure Client-Initiated Renegotiation not vulnerable (OK)

Expected Result:
Secure Renegotiation (RFC 5746) Not supported
Secure Client-Initiated Renegotiation not vulnerable (OK)

@Tazmaniac :

Because client initiated renego is not supported you want to elide the fact that RFC 5746 is not supported.

I mean that "Secure Renegotiation (RFC 5746) Not supported." is OK, but "Secure Renegotiation (RFC 5746) Not supported / VULNERABLE (NOT ok)" is not OK when client/server initiated renegotiation is not supported by the server. In this case, no one can renegotiate in secure/insecure way so I thought "VULNERABLE (NOT ok)" is not correct.

"Server initiated renegotiation may still be initiated and will be insecure without RFC 5746."

I agree with you. I understand that it cannot be detected by client side(testssl.sh) so testssl.sh reports as "VULNERABLE (NOT ok)" on the safe side.