When neither chacha nor cbm-EtM ciphers are supported by the server the report misleadingly states Terrapin mitigations are in place
hellt opened this issue · 1 comments
hellt commented
Thank you for the scanner tool!
It might be that the report message should be different when neither of vulnerable ciphers are supported by the server; e.g.:
❯ ./Terrapin_Scanner_Linux_amd64 --connect clab-sros-sros
================================================================================
==================================== Report ====================================
================================================================================
Remote Banner: SSH-2.0-OpenSSH_8.9
ChaCha20-Poly1305 support: false
CBC-EtM support: false
Strict key exchange support: false
The scanned peer supports Terrapin mitigations and can establish
connections that are NOT VULNERABLE to Terrapin. Glad to see this.
For strict key exchange to take effect, both peers must support it.
Since neither cipher is supported it might be not desirable to say that scanned peer supports Terrapin mitigations since strict kex is not in place?
I can see how disabled ciphers can be considered as a mitigation action, but still it feels like the message might be more precise in that case
hellt commented
After reading more on this I think my proposal is not legit.