Secure Client-Initiated Renegotiation: Crudely detect exponential backoff as a mitigation

[Tazmaniac]

Testssl.sh give false positives on target doing sort of exponential backoff between renegotiation tries.
Nothing is provisioned in testssl.sh to detect this mitigation.

Here is a proposed simple but efficient way of detecting such mitigation.

Instead of trying to do precise timing measurement, we count the number of successful renegotiation.
As we separate each try by one second without waiting for any result, some try will be lost in case of aggressive exponential slow down between each try even with the command buffering done by openssl.
On the tested targets, the result are pretty good. With the default number of six of tries , only 4 four success. With ten tries, only five are successful.
As a conservative disposition, we only consider the target mitigated if we lost 1/3 or more of tries.

[drwetter]

Sorry about the delay... see e-mail for hosts to test against.

There are some formal issues in your PR.

• Tabstop is for this project is 5 blanks. Sometimes there were 1 or 2 blanks or a real tab
• grep -a something | wc -l --> grep -ac

Could you fix that?

[Tazmaniac]

Done.
I have more corrections for client-initiated renego test, but I will do a proper branch on my repo an a new PR.