I am trying to verify whether I am vulnerable to the OpenSSL TLS renegotiation vulnerability CVE-2021-3449 (fixed in OpenSSL 1.1.1k).

When I connect to the website using openssl s_client -tls1_2 -connect example.com:443, it says "Secure Renegotiation IS supported". When I then send the request for renegotiation, it disconnects:

$ openssl s_client -tls1_2 -connect example.com:443
GET / HTTP/1.1
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <my domain>
verify return:1

I first tried without sending data first, but figured it might want some data before accepting the renegotiation. Either way, though, it disconnects. In Wireshark I see three encrypted handshake messages: first me to server, then server to me, then me to server. Before the last one, the server already sent me a FIN+ACK and so I get a RST packet back in the end, though my system also sends a FIN+ACK.

When I ran a test on it from SSL Labs, it says:

  • Secure Renegotiation Supported
  • Secure Client-Initiated Renegotiation No
  • Insecure Client-Initiated Renegotiation No

Does that mean I am safe since since Client-Initiated Renegotiation is disabled? I don't know when or why my web server would ever choose to renegotiate of its own accord. A PoC that I can test against my server would also be appreciated.

  • 1
    "I don't know when or why my web server would ever choose to renegotiate of its own accord." - this is used for client certificate based access restriction, when the restriction is to a path and not the full domain. In this case initially a TLS handshake w/o CertificateRequest is done, then on the established TLS connection the HTTP request is retrieved and if client certificate authentication is required for this path the server will trigger a renegotiation with a CertificateRequest. – Steffen Ullrich Mar 25 at 17:34
  • I've been looking into to this as well, as far as I can see you can only check to see if Client Renegotiation is enabled (using the method you posted) and check the version of Openssl if this is the case. At least this gives a shortlist of servers to check manually, but a more complete (automated) test would be nice indeed :) – BadSkillz Mar 30 at 11:57

This seems like a good potential test package that you can use https://github.com/terorie/cve-2021-3449

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.