Conversation

Replying to

CVE-2021-3450 is kinda delightful because it was introduced by a change that rejects custom curve parameters (which is what broke Windows last year), and it only affects X509_V_FLAG_X509_STRICT mode. Complexity is killer.

Filippo Valsorda

@FiloSottile

Mar 25, 2021

CVE-2021-3449 looks like it could have been found easily if anyone figured out how to fuzz renegotiation, but renegotiation is sadness. Anyway, sounds like you can crash most OpenSSL servers on the Internet today.

Replying to

There's this note for CVE-2021-3449: > A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). Disabling client-initiated renegotiation is a standard security measure checked by internet.nl for web/mail servers.

Replying to

and

Client-initiated renegotiation is disabled by default in nginx since November 2009. It should be disabled elsewhere too and should really be disabled by default in a future major version OpenSSL. It's unnecessary attack surface and has been known to be for a very long time.

Replying to

and

Curious, why does github.com/terorie/cve-20 then crash nginx? I also though that disabling client initiated reneg should be enough, can you shed some light on this

@terorie_dev

github.com

GitHub - terorie/cve-2021-3449: CVE-2021-3449 OpenSSL denial-of-service exploit

CVE-2021-3449 OpenSSL denial-of-service exploit

- GitHub - terorie/cve-2021-3449: CVE-2021-3449 OpenSSL denial-of-service exploit

Richard Patel @ xHack

Replying to

and

I just connected to a modern NGINX server with fairly stock config using “s_client -tls1_2 -connect” and it reports renegotiation is supported. Weird.

Replying to

and

I would suspect that to refer to server renegotiation though. Can you run ssllabs (ssllabs.com/ssltest/) against that instance? I probably looks like the attached photo

Replying to

and

My guess is that to be protected one needs to set SSL_OP_NO_RENEGOTIATION which is not the nginx default. mailman.nginx.org/pipermail/ngin Instead, I think nginx by default cancels renegotiation via SSL_CTX_set_info_callback, which is too late.

github.com

nginx/ngx_event_openssl.c at ef44627852ce831407d54c09d7a100e3ca41b9a6 · nginx/nginx

An official read-only mirror of http://hg.nginx.org/nginx/ which is updated hourly. Pull requests on GitHub cannot be accepted and will be automatically closed. The proper way to submit changes to ...

Replying to

and

There was also this follow up: github.com/nginx/nginx/co So I think every new nginx should have SSL_OP_NO_RENEGOTIATION set by default (if compiled against new enough openssl), which makes me think that there is no way to disable renegotiation in a way that prevents the exploit?

github.com

SSL: disabled renegotiation checks with SSL_OP_NO_RENEGOTIATION. · nginx/nginx@61cec6f

Following 7319:dcab86115261, as long as SSL_OP_NO_RENEGOTIATION is defined, it is OpenSSL library responsibility to prevent renegotiation, so the checks are meaningless. Additionally, with TLSv1.3...

Replying to

Ok, SSL_OP_NO_RENEGOTIATION is probably simply to new for most stable distributions. Gotta check that later.

Replying to

and

Quote Tweet

Replying to @FiloSottile

They disable it via SSL_OP_NO_RENEGOTIATION since hg.nginx.org/nginx/rev/dcab. 3 years ago isn't all that recent. They have a mainline release and an LTS release. The SSL_OP_NO_RENEGOTIATION. It got into mainline in 1.15.4 and the LTS branch in 1.16.0. Current LTS release is 1.18.

1:12 PM · Mar 29, 2021Twitter Web App

Replying to

and

Yes but that is new, your initial comment that it got disabled in 2009 was kinda confusing since it is not enough to prevent that issue...

Replying to

and

I wasn't aware that the implementation of disabling it didn't work until 2018. I tested nginx stable and nginx mainline to confirm it worked the way I remembered and didn't check obsolete versions.