SSH ( Secure Shell Protocol )

• The Transport Layer Protocol [SSH-TRANS] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream.


• The User Authentication Protocol [SSH-USERAUTH] authenticates the client-side user to the server. It runs over the transport layer protocol.


• The Connection Protocol [SSH-CONNECT] multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol.

• Host Keys

Each server host SHOULD have a host key. The server host key is used during key exchange to verify that the client is really talking to the correct server.

Two different trust models can be used:

• The client has a local database that associates each host name (as typed by the user) with the corresponding public host key.


• The host name-to-key association is certified by some trusted certification authority (CA).



• Extensibility

We believe that the protocol will evolve over time, and some organizations will want to use their own encryption, authentication and/or key exchange methods. Central registration of all extensions is cumbersome, especially for experimental or classified features. On the other hand, having no central registration leads to conflicts in method identifiers, making interoperability difficult.


• 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.


• Public key algorithms and key exchange method to be used for host authentication. The existence of trusted host keys for different public key algorithms also affects this choice.


• The authentication methods that are to be required by the server for each user.


• The operations that the user is allowed to perform using the connection protocol.



• Security Properties

The primary goal of the SSH protocol is to improve security on the Internet. It attempts to do this in a way that is easy to deploy, even at the cost of absolute security.

• All encryption, integrity, and public key algorithms used are well-known, well-established algorithms.


• All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest cryptanalytic attacks for decades.


• All algorithms are negotiated, and in case some algorithm is broken, it is easy to switch to some other algorithm without modifying the base protocol.



• Localization and Character Set Support

For the most part, the SSH protocols do not directly pass text that would be displayed to the user. However, there are some places where such data might be passed. When applicable, the character set for the data MUST be explicitly specified. In most places, ISO 10646 with UTF-8 encoding is used [RFC 3629]. When applicable, a field is also provided for a language tag [RFC 3066].

• Byte

A byte represents an arbitrary 8-bit value (octet).


• Boolean

A boolean value is stored as a single byte. The value 0 represents FALSE, and the value 1 represents TRUE.


• Uint32

Represents a 32-bit unsigned integer.


• Uint64

Represents a 64-bit unsigned integer.).


• String

Arbitrary length binary string. Strings are allowed to contain arbitrary binary data, including null characters and 8-bit characters. Strings are also used to store text. In that case, US-ASCII is used for internal names, and ISO-10646 UTF-8 for text that might be displayed to the user.


• Name-list

A string containing a comma-separated list of names. A name-list is represented as a uint32 containing its length (number of bytes that follow) followed by a comma-separated list of zero or more names.

• Transport layer protocol:


1 to 19 Transport layer generic (e.g., disconnect, ignore, debug, etc.)
20 to 29 Algorithm negotiation
30 to 49 Key exchange method specific (numbers can be reused for different authentication methods)


• User authentication protocol:


50 to 59 User authentication generic
60 to 79 User authentication method specific (numbers can be reused for different authentication methods)


• Connection protocol:


80 to 89 Connection protocol generic
90 to 127 Channel related messages


• Reserved for client protocols:


128 to 191 Reserved


• Local extensions:


192 to 255 Local extensions

• Service Names


Authentication Methods
Connection Protocol Channel Names
Connection Protocol Global Request Names
Connection Protocol Channel Request Names


• Key Exchange Method Names



• Assigned Algorithm Names


Encryption Algorithm Names
MAC Algorithm Names
Public Key Algorithm Names
Compression Algorithm Names

• Confidentiality

It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones which have been established and accepted within the industry.

In the optimal case an implementor would need to add an extra packet only if the packet has been sent out onto the network and there are no other packets waiting for transmission. Implementors may wish to check to see if there are any unsent packets awaiting transmission, but unfortunately it is not normally easy to obtain this information from the kernel or buffers. If there are not, then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream every time the attacker knows the IV that is supposed to be used for the next packet, then the attacker will not be able to guess the correct IV, thus the attack will never be successful.


• Data Integrity

This protocol does allow the Data Integrity mechanism to be disabled. Implementors SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" MAC is enabled. So long as the "none" MAC is not used, this protocol provides data integrity.


• Replay

The use of a MAC other than "none" provides integrity and authentication. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent replay of data from prior sessions.
If two sessions happen to have the same session ID (hash of key exchanges) then packets from one can be replayed against the other.


• Man-in-the-middle

This protocol makes no assumptions or provisions for an infrastructure or means for distributing the public keys of hosts. It is expected that this protocol will sometimes be used without first verifying the association between the server host key and the server host name.

There are three cases of man-in-the-middle attacks to consider. The first is where an attacker places a device between the client and the server before the session is initiated. The second case that should be considered is similar to the first case in that it also happens at the time of connection but this case points out the need for the secure distribution of server public keys. In the third man-in-the-middle case, attackers may attempt to manipulate packets in transit between peers after the session has been established.

In summary, the use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED.


• Denial-of-service

This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type ("wire cutter") are almost impossible to avoid.

In addition, this protocol is vulnerable to Denial of Service attacks because an attacker can force the server to go through the CPU and memory intensive tasks of connection setup and key exchange without authenticating.


• Covert Channels

The protocol was not designed to eliminate covert channels.

• Weak Transport

If the transport layer does not provide confidentiality, authentication methods that rely on secret data SHOULD be disabled. If it does not provide strong integrity protection, requests to change authentication data (e.g., a password change) SHOULD be disabled to prevent an attacker from modifying the ciphertext without being noticed, or rendering the new authentication data unusable (denial of service).


• Debug Messages

Special care should be taken when designing debug messages. These messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during user authentication phase) if high security is required. Administrators of host machines should make all attempts to compartmentalize all event notification messages and protect them from unwarranted observation. Developers should be aware of the sensitive nature of some of the normal event messages and debug messages and may want to provide guidance to administrators on ways to keep this information away from unauthorized people.


• Local Security Policy

Implementer MUST ensure that the credentials provided validate the professed user and also MUST ensure that the local policy of the server permits the user the access requested. In particular, because of the flexible nature of the SSH connection protocol, it may not be possible to determine the local security policy, if any, that should apply at the time of authentication because the kind of service being requested is not clear at that instant.


• Public Key Authentication

The use of public-key authentication assumes that the client host has not been compromised. It also assumes that the private-key of the server host has not been compromised.


• Password Authentication

The password mechanism as specified in the authentication protocol assumes that the server has not been compromised. If the server has been compromised, using password authentication will reveal a valid username / password combination to the attacker, which may lead to further compromises.


• Host Based Authentication

Host based authentication assumes that the client has not been compromised. There are no mitigating strategies, other than to use host based authentication in combination with another authentication method.

• End Point Security

End point security is assumed by the connection protocol. If the server has been compromised, any terminal sessions, port forwarding, or systems accessed on the host are compromised. There are no mitigating factors for this.


• Proxy Forwarding

The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location.In addition, a reverse proxy forwarding functionality is available, which again can be used to bypass firewall controls.

As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise all data passed over proxy forwarding.


• X11 Forwarding

Another form of proxy forwarding provided by the SSH connection protocol is the forwarding of the X11 protocol. If end-point security has been compromised, X11 forwarding may allow attacks against the X11 server.

Implementors of the X11 forwarding protocol SHOULD implement the magic cookie access checking spoofing mechanism as described in [SSH-CONNECT] as an additional mechanism to prevent unauthorized use of the proxy.

Confidentiality



As an example, consider the following case:

          Client                                                  Server

          ------                                                  ------

          TCP(seq=x, len=500)             ---->

           contains Record 1



                              [500 ms passes, no ACK]



          TCP(seq=x, len=1000)            ---->

           contains Records 1,2



                                                                    ACK

    

1. The Nagle algorithm + TCP retransmits mean that the two records get coalesced 

into a single TCP segment.

2. Record 2 is *not* at the beginning of the TCP segment and never will be, since 

it gets ACKed.

3. Yet, the attack is possible because Record 1 has already been seen.



As this example indicates, it's totally unsafe to use the existence of unflushed data 

in the TCP buffers proper as a guide to whether you need an empty packet, since 

when you do the second write(), the buffers will contain the un-ACKed Record 1.

■ Parent layer
■ Child layer

TCP/UDP

SSH