Joined: 18 Feb 2022
|Posted: Wed Aug 17, 2022 3:39 am Post subject:
|According to websites like StackExchange, the worst that could happen would be data leaks.
But the CVE (vulnerability report number) is from 2009, and there has been so many security updates to OpenSSL since then.
So I got no doubt that the OpenSSL developers fixed that vulnerability long ago already.
So with the worst put aside, the client renegociation & the secure client renegociation seem to only be capable of enabling DoS attacks.
DoS attacks that use it are basically malicious TLS clients that spam your server with tons of TLS renegociation messages.
The server when renegociating does more work than the client, so the client could spam faster than the server is able to complete renegociation requests.
The worst that could happen is your server no longer being able to hande so many TLS renegociations, and no longer serving TLS sessions to other legitimate visitors.
It's also possible for the servers to refuse renegociation requests from the TLS clients.
Servers can decide to only allow renegociation when they themselves want to do it.
If you're behind a frontend like Cloudflare, or if you don't usually get DoS traffic, you should be fine.
However it might be a good idea to mail Aprelium to ask what the developers think of adding a 'server-only renegociation' option - to refuse client-initiated renegociation requests.
I don't know what would happen if renegociation was directly disabled, but it could perhaps cause problems with Reverse-Proxy over HTTPS like random disconnects & reconnects if a new TLS session has to be made instead of renewing the existing one? (like Abyss on PC-A to Abyss on PC-B kinds of Reverse-Proxying).
So, what I've read is that this could make a server vulnerable to DoS attacks to consume all your available TLS processing power for lots of useless renegociations (legitimate visitors would not be able to connect).
Whether you should be worried about DoS attacks depends on whether the availability of your service is critical.
Parcel delivery services will probably treat DoS attacks against their servers as a serious threat, when the job is to work against the clock with nearly-constant availability.
Otherwise, a simple hardware monitoring like CPU temperature & things that can physically be affected by that kind of DoS incidents should work well enough.