diff options
Diffstat (limited to 'PROTOCOL')
-rw-r--r-- | PROTOCOL | 42 |
1 files changed, 41 insertions, 1 deletions
@@ -51,6 +51,46 @@ and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic | |||
51 | curve points encoded using point compression are NOT accepted or | 51 | curve points encoded using point compression are NOT accepted or |
52 | generated. | 52 | generated. |
53 | 53 | ||
54 | 1.5 transport: Protocol 2 Encrypt-then-MAC MAC algorithms | ||
55 | |||
56 | OpenSSH supports MAC algorithms, whose names contain "-etm", that | ||
57 | perform the calculations in a different order to that defined in RFC | ||
58 | 4253. These variants use the so-called "encrypt then MAC" ordering, | ||
59 | calculating the MAC over the packet ciphertext rather than the | ||
60 | plaintext. This ordering closes a security flaw in the SSH transport | ||
61 | protocol, where decryption of unauthenticated ciphertext provided a | ||
62 | "decryption oracle" that could, in conjunction with cipher flaws, reveal | ||
63 | session plaintext. | ||
64 | |||
65 | Specifically, the "-etm" MAC algorithms modify the transport protocol | ||
66 | to calculate the MAC over the packet ciphertext and to send the packet | ||
67 | length unencrypted. This is necessary for the transport to obtain the | ||
68 | length of the packet and location of the MAC tag so that it may be | ||
69 | verified without decrypting unauthenticated data. | ||
70 | |||
71 | As such, the MAC covers: | ||
72 | |||
73 | mac = MAC(key, sequence_number || packet_length || encrypted_packet) | ||
74 | |||
75 | where "packet_length" is encoded as a uint32 and "encrypted_packet" | ||
76 | contains: | ||
77 | |||
78 | byte padding_length | ||
79 | byte[n1] payload; n1 = packet_length - padding_length - 1 | ||
80 | byte[n2] random padding; n2 = padding_length | ||
81 | |||
82 | 1.6 transport: AES-GCM | ||
83 | |||
84 | OpenSSH supports the AES-GCM algorithm as specified in RFC 5647. | ||
85 | Because of problems with the specification of the key exchange | ||
86 | the behaviour of OpenSSH differs from the RFC as follows: | ||
87 | |||
88 | AES-GCM is only negotiated as the cipher algorithms | ||
89 | "aes128-gcm@openssh.com" or "aes256-gcm@openssh.com" and never as | ||
90 | an MAC algorithm. Additionally, if AES-GCM is selected as the cipher | ||
91 | the exchanged MAC algorithms are ignored and there doesn't have to be | ||
92 | a matching MAC. | ||
93 | |||
54 | 2. Connection protocol changes | 94 | 2. Connection protocol changes |
55 | 95 | ||
56 | 2.1. connection: Channel write close extension "eow@openssh.com" | 96 | 2.1. connection: Channel write close extension "eow@openssh.com" |
@@ -291,4 +331,4 @@ link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message. | |||
291 | This extension is advertised in the SSH_FXP_VERSION hello with version | 331 | This extension is advertised in the SSH_FXP_VERSION hello with version |
292 | "1". | 332 | "1". |
293 | 333 | ||
294 | $OpenBSD: PROTOCOL,v 1.17 2010/12/04 00:18:01 djm Exp $ | 334 | $OpenBSD: PROTOCOL,v 1.20 2013/01/08 18:49:04 markus Exp $ |