Open unbeatable-101 opened 10 months ago
Hello @unbeatable-101 👋
Thank you so much for reaching me out 🙏
All "-etm@" MACs are vulnerable to Terrapin-attack :
Supports chacha20-poly1305@openssh.com or any -etm@openssh.com algorithm.
Have you a custom configuration server to share with me?
I can provide a way to enable -etm@ again with a configuration on WebSSH side. Would you like?
From https://terrapin-attack.com I see
the connection must be secured by either ChaCha20-Poly1305 or CBC with Encrypt-then-MAC
so it’s not the MACs themselves that are vulnerable (and as far as I know, etm MACs are considered more secure than non-etm MACs), but using them in combination with ChaCha20-Poly1305 or a CBC cipher, neither of which my server support. Here is the output of ssh-audit
on my server:
# general
(gen) banner: SSH-2.0-OpenSSH_9.6
(gen) software: OpenSSH 9.6
(gen) compatibility: OpenSSH 8.5+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)
# key exchange algorithms
(kex) sntrup761x25519-sha512@openssh.com -- [info] available since OpenSSH 8.5
(kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
`- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
`- [info] default key exchange since OpenSSH 6.4
(kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
`- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) ext-info-s -- [info] pseudo-algorithm that denotes the peer supports RFC8308 extensions
(kex) kex-strict-s-v00@openssh.com -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)
# host-key algorithms
(key) rsa-sha2-512 (4096-bit) -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (4096-bit) -- [info] available since OpenSSH 7.2
(key) ssh-ed25519 -- [info] available since OpenSSH 6.5
# encryption algorithms (ciphers)
(enc) aes256-gcm@openssh.com -- [info] available since OpenSSH 6.2
(enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr -- [info] available since OpenSSH 3.7
# message authentication code algorithms
(mac) hmac-sha2-256-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com -- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com -- [info] available since OpenSSH 6.2
# fingerprints
(fin) ssh-ed25519: SHA256:jYq59AodueeNOHR9JXlB8HpG7Z80NJawaQ0rWccftd8
(fin) ssh-rsa: SHA256:M/6Xq9dc5Lah+pLrK8Sn+HivdlhxWBrjVSlUiGH10BQ
An option to enable them again would be good, but I think a better solution would be to automatically enable them if the server declares it supports kex-strict-s-v00@openssh.com
, or if ChaCha20-Poly1305 and CBC ciphers were not declared.
I agree @unbeatable-101 that I need to improve WebSSH to automatically enable them on conditions you written.
Before I can work on this enhancement, you can now use WebSSH 24.8.1244 : https://testflight.apple.com/join/QSrBK59z
And add the following to your ssh_config in order to enable HMAC-ETM again :
Could you give it a try?
Thanks! That works.
This works for me too, testflight not necessary -- thanks. I'm using the default SSH server config on NixOS 23.10, I'm surprised suitable ciphers are not offered -- though I suppose the terrapin attack was known after the major NixOS release.
Bug description
Every version since the 24.7 beta leaves me unable to connect to my sever due to no matching MAC algorithms. I suspect this is due to the Terrapin attack fix in WebSSH, but none of these MAC algorithms were vulnerable (or at least
ssh-audit
says they’re all fine).Log