ChaCha20-Poly1305 now vulnerable to Mitm "Terrapin" attack.

[KoenDG]

https://terrapin-attack.com/

I was reading Secure Secure Shell, and found this near the end:

After some debate and going back and forth between including GCM or not, it’s now back again. The reason for dropping it was that SSH doesn’t encrypt packet sizes when using GCM. The reason for bringing it back is that SSH does the same with any EtM algorithms. There is no way around this unless you can live with chacha20-poly1305 only. Also, the leaked documents don’t sound like they can figure out the lengths or confirm presence of some things, more like straight up “send it to us and we’ll decrypt it for you”. Wrapping SSH in a Tor hidden service will take care of any traffic analysis concerns.

Well, chacha20-poly1305 has been proven hackable, it seems?

[stribika]

This looks really bad. It also affects all the etm cbc algos too. Thanks for letting me know ,i'll update it today.

[KoenDG]

SSH has been updated, claiming to address it: https://www.openssh.com/releasenotes.html#9.6p1

[askeuhd]

@KoenDG

The recent update introduces an additional mitigation measure, strict key exchange, which necessitates updating both the client (any client) and server to ensure compatibility. In light of this, I think it is wise to advise against using chacha20-poly1305@openssh.com, unless a particular need for this specific cipher is clearly established.

[KoenDG]

Indeed. And I find their explanation a bit... handwavy.

I mean, for this part:

While cryptographically novel, the security impact of this attack is fortunately very limited as it only allows deletion of consecutive messages, and deleting most messages at this stage of the protocol prevents user user authentication from proceeding and results in a stuck connection.

Sounds to me like this can be used to stop you from reaching your network. Which, for any company with remote hosts, is potentially catastrophic, in the correct scenario.

So yeah, I'd disable it, if not explicitly needed.

Which leaves us with:

  - aes256-ctr
  - aes192-ctr
  - aes128-ctr

From what I understand.

[miki2119]

The idea of disabling ChaCha20 because of this issue is kinda ironic.

If you set the remaining ciphers in your sshd_config, you have manually put yourself into a position that is equal to the worst case an attacker could cause. This is a downgrade attack and as long as you don't have anything like DES ciphers in your list it hardly matters in practice (which is probably why the OpenSSH developers reaction to this seemed almost indifferent) The best defense against this is already in this guide, namely to manually set only the more trusted algorithms in your config. Current versions of OpenSSH do not seem to have any weak/legacy ciphers enabled by default anyway, so this issue is mostly relevant to implementations that do (e.g. Cisco devices with their ancient ciphers)

Also note that the actual cipher ChaCha20 is in no way the issue here, it is merely that the use of this mode in SSH allows to trigger the issue which lies in the actual SSH protocol.

[KoenDG]

Current versions of OpenSSH do not seem to have any weak/legacy ciphers enabled by default anyway

I honestly don't keep track. Are they still using NIST?

Regardless, a lot of people are stuck with the version their server came with when it installed, and whatever maximum the OS version can upgrade to.

Hardening your setup is a good idea either way, and this guide helps with that.

[miki2119]

Current versions of OpenSSH do not seem to have any weak/legacy ciphers enabled by default anyway

I honestly don't keep track. Are they still using NIST?

If you are referring to the NIST curves then yes and there is still no reason to assume those to be weak or broken. As of today there seems to be no respected cryptographer who supports any related conspiracy theories either and the main reason to avoid those curves is still the difficulties in implementing them safely https://safecurves.cr.yp.to/

Regardless, a lot of people are stuck with the version their server came with when it installed, and whatever maximum the OS version can upgrade to.

Hardening your setup is a good idea either way, and this guide helps with that.

For older versions of OpenSSH hardening can make sense and I agree that this guide still serves a good purpose in those cases. In regards to the Terrapin vulnerability I would worry more about other SSH implementations.

[rhyven]

Caveat: I've read most of the Terrapin technical paper, and even understood lots of it. I'm not a cryptographer though, so if DJB or any other cryptowizard makes a statement regarding Terrapin, take their word over mine.

Terrapin hasn't demonstrated a cryptographic weakness in ChaCha20-Poly1305. In fact, the authors themselves have taken care to clarify that their work doesn't suggest ChaCha20-Poly1305 is hackable: "Note that the fault is not with ChaCha20-Poly1305 as an AEAD encryption scheme, but with its integration into the SSH secure channel construction"

What Terrapin does is demonstrate that the very early phase of the SSH Binary Packet Protocol has a weakness where an active MiTM can compromise how your crypto is negotiated. So, it doesn't break the crypto suite itself, but it can potentially trick the SSH implementation into assuming modern crypto options are unavailable and thus selecting a bad suite.

The other angle is that the MiTM can effectively manipulate the session counter's sequence number, by throwing an arbitrary number of 'ignore' packets. This is important because ChaCha20-Poly1305 "directly uses the sequence number in its key derivation" (from 4.3.2 of Terrapin's technical paper). This means your MiTM can manipulate part of the original state used to create the keys for the session, and that is always gonna give you ants.

In terms of Terrapin being "bad" - this attack requires not just any MiTM, but one with the ability to drop or fabricate packets within your connection in real-time. That dramatically narrows the number of people who need to care, but it does still leave high-risk people in authoritarian states potentially vulnerable. The best answer is to update SSH on both the client and the server, though - not drop one of the strongest and fastest cipher suites available today.

[KoenDG]

Thanks for the summary. It's very nuanced, it seems.

[gunzy83]

Thanks for the summary @rhyven. I didn't have the time to read the paper but the mention of a MitM did make me think this is going to be highly dependent on your threat model... which for most of us we should patch regularly but not get too hung up about this issue.