-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
Don't recommend weaker crypto #166
Comments
Could you please paste the entire ssh-audit output of a scan that produced this output? That would help me understand what it did exactly, and why. Thanks! |
output:
|
Thanks for posting the output. I see what you're referring to. The tool's recommendations section is simply saying what safe additional algorithms could be enabled on the server. I suppose this messaging could be refined and made more clear. For example, the tool can recommend that unsafe algorithms are removed, then use another section to suggest additional safe algorithms. If anyone wants to work on the PR for this functionality, its up for grabs! |
I have had a look at this on and off for a little while and have made zero progress. I did try to add a few checks in the area of the While these checks certainly suppressed any weaker recommendations they also suppressed removal prompts ( not good ) ; and were very fragile as they relied on "bit checking" in the cipher name ( eg : check 128 exists in aes128-ctr ). This would of tend to break down whenever checking a something with different names; EG : Curve25519SHA256 vs diffie-hellman-group16-sha256 I had another go attempting to update the ssh2_kexdb.py file with a numerical value to each ENC / MAC / KEX and KEY. 'aes128-ctr': [['3.7,d0.52,l10.4.1'], [], [], [], [20]], The thought was to then to If (Value B) is smaller than (Value A) DONT recommend that cipher. This is were I became stuck as (I am not a very well versed programmer ) and am having trouble following the code. |
The spaghetti below attempts to explain my thoughts from my previous comment. In the example code it uses the SSH2_KexDB as provided from the repo. This version of the code returns two algorithm's with the largest weight numbers - it seemed safer than only returning 1x. Notes: aes64-ctr and others are garbage created for testing. If I can manage to make something work that looks sensible I will create a pull request. Feel free to use / modify / destroy as you see fit. CAUTION : Might eat your cat.
|
… exception of always suggesting a _second_ option. jtesta#166
If a server has AES 256 enabled, but not AES 128, don't indicate it as an error, despite AES 128 being considered as modern.
Similarly, if a server has
[email protected]
enabled, but notcurve25519-ssh
, dont' indicate it as an error.The text was updated successfully, but these errors were encountered: