Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False positive when testing for client-initiated renegotiation DoS attack #473

Closed
FallenHero66 opened this issue Jan 13, 2021 · 9 comments
Closed

Comments

@FallenHero66
Copy link

As Issue #38 states, there are some cases where one renegotiation attempt is not a safe factor for a vulnerability against client-initiated renegotiation attempts DoS.
Running into this issue with BIG-IP for example, I suggest the addition of a flag which allows for setting a certain amount of retries.
This flag would probably have to be capped to a maximum (suggestions?) though, as otherwise it would allow for carrying out the actual attack.

@FallenHero66
Copy link
Author

I started working on this, but am somewhat lost at the cli interface - the flag itself is working, but when I set it only the renegotiation job is executed...

@nabla-c0d3
Copy link
Owner

Thanks for the bug report. I ended up updating the check to try 10 client renegotiations in a row, in order to be sure 100% sure.

I think this should be enough to fix this problem?

@nabla-c0d3
Copy link
Owner

I bumped it to 15 based on your message in #38:

F5 allows a certain (configurable) amount of renegotiations until it kills the connection, so this has caused some false positives for me aswell. [...] (F5 allows 10 by default as far as I know).

@nabla-c0d3 nabla-c0d3 changed the title Flag for amount of client-initiated renegotiation attempts False positive when testing for client-initiated renegotiation DoS attack Jan 18, 2021
@nabla-c0d3
Copy link
Owner

The fix was released as part of v4.0.0.

@nabla-c0d3
Copy link
Owner

@FallenHero66 Please re-open this issue if I missed something or if my fix wasn't correct. Thanks!

@FallenHero66
Copy link
Author

FallenHero66 commented Jan 19, 2021

Hello @nabla-c0d3, and thank you for looking into this!
Unfortunately, I feel there is a problem with your approach: When testing a server that slows down on each renegotiation attempt (this was the case for a client's server), sslyze will run into a socket timeout before hitting the 15 attempts, and the result will be "not vulnerable", although this behaviour is quite strange and should probably be investigated.

I hope this information was helpful!

EDIT: I cannot reopen this issue by the way, as you closed it

@nabla-c0d3 nabla-c0d3 reopened this Jan 20, 2021
@nabla-c0d3
Copy link
Owner

@FallenHero66 would you be able to send me the server where this behavior is happening?

@FallenHero66
Copy link
Author

FallenHero66 commented Jan 20, 2021

@nabla-c0d3 is there a way to contact you privately? As it is the server of a customer, I would like to avoid disclosing it publicly

EDIT: I will send it to your e-mail, if you do not mind.

@nabla-c0d3
Copy link
Owner

After looking into this I think the current approach works, so this is indeed fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
4.0.0
Done
Development

No branches or pull requests

2 participants