Find out how to configure Akamai to confirm the renegotiation vulnerability discovered by the Security Rating.
Summary :
- Initiated renegociation functionality
- Akamai Configuration
- Security Rating
- Using customer certificates
Initiated renegociation functionality
Initiated renegotiation is a historical feature of the SSL/TLS protocol, which was needed to initiate renegotiation to more secure cipher suites, when encryption was strictly regulated in many countries, with RSA keys limited to 56bit.
It was maintained for some time with the argument of constrained environments (CPU / RAM), which could by default use a lighter method, and voluntarily switched to a more secure method for the transmission of information considered more sensitive.
Today, it is totally obsolete, and has disappeared from the TLSv1.3 specification. In almost all cases, disabling it for TLSv1.2 and below has no operational consequences.
With its widespread use for denial-of-service operations (renegotiating encryption keys / redoing a diffie-helman exchange can represent a substantial CPU cost and undermine the entropy of random number generators, but is also 15 times more costly for the server than the client), it is recommended by default to disable it, or to implement countermeasures, such as limiting renegotiations to fewer than 10 in a single session, or an exponential pause between each renegotiation attempt.
Akamai Configuration
There is a problem with vhosts exposed by Akamai devices, called "Secure Client-Initiated Renegociation".
The following options are available in the Akamai profile settings:
- "Secure" Corresponds to the initial functionality, which is the subject of the test. There was also a version that was considered unsecured, which was succeeded by the "secured" version.
- "Warning" corresponds to the historical unsecured version. The latter is to be banned, and all f5 or other equipment is supposed to support the "secure" version.
- "Disallow" corresponds to the deactivation of renegotiation.
The Akamai documentation recommends using the "disallow" parameter to have a mode with countermeasures (limiting to less than 5-10 renegotiations, for example).
Security Rating
The Security Rating uses a combination of analysis tools, including a corrected version of testssl.sh / sslyse for this test.
Testssl.com uses an uncorrected version of testssl.sh.
You can find the patch in branch 3.0 or 3.2 on github, but it has not been released.
If you pull version 3.0 or 3.2 directly from github, you'll get a bug-free version of the tool that confirms the Security Rating diagnosis. The sslyse tool will also confirm the same diagnosis.
Using customer certificates
The server can, at any time, initiate a renegotiation to require a client certificate when accessing URLs protected by certificate authentication. Only certain poor implementations or client and/or server histories force the use of client renegotiation for client certificate use.
All modern client/server applications using certificate-based authentication support TLSv1.3.
Under this version, client renegotiation does not exist, so compatibility with such a setting does not arise.
Qualification tests must be carried out to confirm that you are not in a situation where renegotiation on the customer's initiative is necessary, and therefore whether additional adjustments/work is required to get you out of it.