3

I recently found out, that according to the RFC, SSH can negotiate two different cipher (and MAC) algorithms for server-to-client-encryption and for client-to-server-encryption (check section 7.1. for reference).

In section 6.3 this is also asserted:

The ciphers in each direction MUST run independently of each other. Implementations MUST allow the algorithm for each direction to be independently selected, if multiple algorithms are allowed by local policy. In practice however, it is RECOMMENDED that the same algorithm be used in both directions.

I am now wondering:

  1. Why was this allowed? Has there been a use-case for this odd behaviour back in 2006 when the RFC was published?
  2. Is there any SSH server out there which actually implements this? OpenSSH appears not to do so.
Improve this question
3
  • There are two-channels, incoming, and outgoing. Do you expect that the two channels use the same key and nonce? That can cause (Key, nonce) reuse problem. That is the reason for independence. The crucial point is independence!.
    – kelalaka
    Dec 5, 2020 at 16:02
  • @kelalaka: I'm not talking about the keys but about the algorithms. You can have AES-128-CBC from client to server but use RC4 from server to client. That's what's really weird and different from other protocols like TLS.
    – mat
    Dec 5, 2020 at 16:05
  • 1
    This rather reminds me of the earlier pre-CredSSP versions of MS Remote Desktop, which (in "Low" security mode) encrypted your keyboard input with RC4, but received the graphics on-screen as cleartext.
    – user1686
    Dec 5, 2020 at 19:55

1 Answer 1

Reset to default
1
  1. Why was this allowed? Has there been a use-case for this odd behaviour back in 2006 when the RFC was published?

It is mentioned in the RFC 4521

4.3. Policy Issues

The protocol allows full negotiation of encryption, integrity, key exchange, compression, and public key algorithms and formats. Encryption, integrity, public key, and compression algorithms can be different for each direction.

The following policy issues SHOULD be addressed in the configuration mechanisms of each implementation:

  • Encryption, integrity, and compression algorithms, separately for each direction. The policy MUST specify which is the preferred algorithm (e.g., the first algorithm listed in each category).

I haven't seen an attack to consider the separation. The RFC only uses the SHOULD. This is high probably a conservative approach so that in a future attack instead of updating the standard in a bulk, replacing the SHOULD to MUST will suffice.

  1. Is there any SSH server out there which actually implements this? OpenSSH appears not to do so.

I've looked at some of them and couldn't see one.

Improve this answer
2
  • That RFC statement is just asserting the fact that you are allowed to use multiple algorithms again, but it doesn't really explain why this would be a good idea.
    – mat
    Dec 5, 2020 at 23:12
  • 1
    @mat Yes, I've looked and couldn't see. I've written the answer to discuss more. The only explanation is the extensibility and the conservative approach. The extensibility section doesn't mention either.
    – kelalaka
    Dec 5, 2020 at 23:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.