9. Security Considerations
- Security Considerations
In order to make the entire body of Security Considerations more accessible, Security Considerations for the transport, authentication, and connection documents have been gathered here.
The transport protocol [SSH-TRANS] provides a confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols.
The authentication protocol [SSH-USERAUTH] provides a suite of mechanisms that can be used to authenticate the client user to the server. Individual mechanisms specified in the authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol.
The connection protocol [SSH-CONNECT] specifies a mechanism to multiplex multiple streams (channels) of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for proxy-forwarding various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure subsystems on the server host.
9.1. Pseudo-Random Number Generation
This protocol binds each session key to the session by including random, session specific data in the hash used to produce session keys. Special care should be taken to ensure that all of the random numbers are of good quality. If the random data here (e.g., Diffie- Hellman (DH) parameters) are pseudo-random, then the pseudo-random number generator should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs) and, furthermore, proper entropy needs to be added to the pseudo- random number generator. [RFC4086] offers suggestions for sources of random numbers and entropy. Implementers should note the importance of entropy and the well-meant, anecdotal warning about the difficulty in properly implementing pseudo-random number generating functions.
RFC 4251 SSH Protocol Architecture January 2006
The amount of entropy available to a given client or server may sometimes be less than what is required. In this case, one must either resort to pseudo-random number generation regardless of insufficient entropy or refuse to run the protocol. The latter is preferable.
9.2. Control Character Filtering
When displaying text to a user, such as error or debug messages, the client software SHOULD replace any control characters (except tab, carriage return, and newline) with safe sequences to avoid attacks by sending terminal control characters.
9.3. Transport
9.3.1. 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 that have been established and accepted within the industry. At the time of this writing, commonly used ciphers include 3DES, ARCFOUR, twofish, serpent, and blowfish. AES has been published by The US Federal Information Processing Standards as [FIPS-197], and the cryptographic community has accepted AES as well. As always, implementers and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementers should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen.
The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. Its cryptographic properties are sufficiently described in [RFC2410], which will show that its use does not meet the intent of this protocol.
The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and [KAUFMAN]. Both of these describe the CBC mode of operation of certain ciphers and the weakness of this scheme. Essentially, this mode is theoretically vulnerable to chosen cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack is deemed difficult and not considered fully practicable, especially if relatively long block sizes are used.
RFC 4251 SSH Protocol Architecture January 2006
Additionally, another CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. Without this technique, a specific attack may be successful. For this attack (commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to work, the attacker would need to know the Initialization Vector (IV) of the next block that is going to be encrypted. In CBC mode that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e., it is in the internal buffers of the SSH implementation or even in the kernel), then this attack will not work. If the last packet has been sent out to the network (i.e., the attacker has access to it), then he can use the attack.
In the optimal case, an implementer 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. Implementers may wish to check if there are any unsent packets awaiting transmission; unfortunately, it is not normally easy to obtain this information from the kernel or buffers. If there are no unsent packets, 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.
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
-
The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment.
-
Record 2 is not at the beginning of the TCP segment and never will be because it gets ACKed.
-
Yet, the attack is possible because Record 1 has already been seen.
RFC 4251 SSH Protocol Architecture January 2006
As this example indicates, it is unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether an empty packet is needed, since when the second write() is performed the buffers will contain the un-ACKed Record 1.
On the other hand, it is perfectly safe to have the following situation:
Client Server
TCP(seq=x, len=500) ----> contains SSH_MSG_IGNORE
TCP(seq=y, len=500) ----> contains Data
Provided that the IV for the second SSH Record is fixed after the data for the Data packet is determined, then the following should be performed:
read from user encrypt null packet encrypt data packet
9.3.2. Data Integrity
This protocol does allow the Data Integrity mechanism to be disabled. Implementers 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.
Because MACs use a 32-bit sequence number, they might start to leak information after 232 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [SSH-TRANS] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 228 packets at the very most.
9.3.3. 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
RFC 4251 SSH Protocol Architecture January 2006
replay of data from prior sessions. For example, the authentication protocol ([SSH-USERAUTH]) uses this to prevent replay of signatures from previous sessions. Because public key authentication exchanges are cryptographically bound to the session (i.e., to the initial key exchange), they cannot be successfully replayed in other sessions. Note that the session id can be made public without harming the security of the protocol.
If two sessions have the same session id (hash of key exchanges), then packets from one can be replayed against the other. It must be stressed that the chances of such an occurrence are, needless to say, minimal when using modern cryptographic methods. This is all the more true when specifying larger hash function outputs and DH parameters.
Replay detection using monotonically increasing sequence numbers as input to the MAC, or HMAC in some cases, is described in [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC4120]. The underlying construct is discussed in [RFC2104]. Essentially, a different sequence number in each packet ensures that at least this one input to the MAC function will be unique and will provide a nonrecurring MAC output that is not predictable to an attacker. If the session stays active long enough, however, this sequence number will wrap. This event may provide an attacker an opportunity to replay a previously recorded packet with an identical sequence number but only if the peers have not rekeyed since the transmission of the first packet with that sequence number. If the peers have rekeyed, then the replay will be detected since the MAC check will fail. For this reason, it must be emphasized that peers MUST rekey before a wrap of the sequence numbers. Naturally, if an attacker does attempt to replay a captured packet before the peers have rekeyed, then the receiver of the duplicate packet will not be able to validate the MAC and it will be discarded. The reason that the MAC will fail is because the receiver will formulate a MAC based upon the packet contents, the shared secret, and the expected sequence number. Since the replayed packet will not be using that expected sequence number (the sequence number of the replayed packet will have already been passed by the receiver), the calculated MAC will not match the MAC received with the packet.
9.3.4. 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. Such usage is vulnerable to man-in-the-middle attacks. This section describes this and encourages administrators
RFC 4251 SSH Protocol Architecture January 2006
and users to understand the importance of verifying this association before any session is initiated.
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. In this case, the attack device is trying to mimic the legitimate server and will offer its public key to the client when the client initiates a session. If it were to offer the public key of the server, then it would not be able to decrypt or sign the transmissions between the legitimate server and the client unless it also had access to the private key of the host. The attack device will also, simultaneously to this, initiate a session to the legitimate server, masquerading itself as the client. If the public key of the server had been securely distributed to the client prior to that session initiation, the key offered to the client by the attack device will not match the key stored on the client. In that case, the user SHOULD be given a warning that the offered host key does not match the host key cached on the client. As described in Section 4.1, the user may be free to accept the new key and continue the session. It is RECOMMENDED that the warning provide sufficient information to the user of the client device so the user may make an informed decision. If the user chooses to continue the session with the stored public key of the server (not the public key offered at the start of the session), then the session-specific data between the attacker and server will be different between the client-to-attacker session and the attacker- to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session-specific data from the server, since he does not have the private key of that server.
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. If the server public keys are not securely distributed, then the client cannot know if it is talking to the intended server. An attacker may use social engineering techniques to pass off server keys to unsuspecting users and may then place a man-in-the-middle attack device between the legitimate server and the clients. If this is allowed to happen, then the clients will form client-to-attacker sessions, and the attacker will form attacker-to-server sessions and will be able to monitor and manipulate all of the traffic between the clients and the legitimate servers. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms are discussed in Section 4.1 and may also include secured Web pages, physical pieces of paper,
RFC 4251 SSH Protocol Architecture January 2006
etc. Implementers SHOULD provide recommendations on how best to do this with their implementation. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, making the host key fingerprint available through a secure DNS lookup, or using Kerberos ([RFC4120]) over GSS-API ([RFC1964]) during key exchange to authenticate the server are possibilities.
In the third man-in-the-middle case, attackers may attempt to manipulate packets in transit between peers after the session has been established. As described in Section 9.3.3, a successful attack of this nature is very improbable. As in Section 9.3.3, this reasoning does assume that the MAC is secure and that it is infeasible to construct inputs to a MAC algorithm to give a known output. This is discussed in much greater detail in Section 6 of [RFC2104]. If the MAC algorithm has a vulnerability or is weak enough, then the attacker may be able to specify certain inputs to yield a known MAC. With that, they may be able to alter the contents of a packet in transit. Alternatively, the attacker may be able to exploit the algorithm vulnerability or weakness to find the shared secret by reviewing the MACs from captured packets. In either of those cases, an attacker could construct a packet or packets that could be inserted into an SSH stream. To prevent this, implementers are encouraged to utilize commonly accepted MAC algorithms, and administrators are encouraged to watch current literature and discussions of cryptography to ensure that they are not using a MAC algorithm that has a recently found vulnerability or weakness.
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. However, it may be necessary in non-security-critical environments, and will still provide protection against passive attacks. Implementers of protocols and applications running on top of this protocol should keep this possibility in mind.
9.3.5. 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. Implementers SHOULD provide features that make this
RFC 4251 SSH Protocol Architecture January 2006
more difficult, for example, only allowing connections from a subset of clients known to have valid users.
9.3.6. Covert Channels
The protocol was not designed to eliminate covert channels. For example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way of verifying whether such information is being sent.
9.3.7. Forward Secrecy
It should be noted that the Diffie-Hellman key exchanges may provide perfect forward secrecy (PFS). PFS is essentially defined as the cryptographic property of a key-establishment protocol in which the compromise of a session key or long-term private key after a given session does not cause the compromise of any earlier session [ANSI-T1.523-2001]. SSH sessions resulting from a key exchange using the diffie-hellman methods described in the section Diffie-Hellman Key Exchange of [SSH-TRANS] (including "diffie-hellman-group1-sha1" and "diffie-hellman-group14-sha1") are secure even if private keying/authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSH does have PFS. However, this property is not commuted to any of the applications or protocols using SSH as a transport. The transport layer of SSH provides confidentiality for password authentication and other methods that rely on secret data.
Of course, if the DH private parameters for the client and server are revealed, then the session key is revealed, but these items can be thrown away after the key exchange completes. It's worth pointing out that these items should not be allowed to end up on swap space and that they should be erased from memory as soon as the key exchange completes.
9.3.8. Ordering of Key Exchange Methods
As stated in the section on Algorithm Negotiation of [SSH-TRANS], each device will send a list of preferred methods for key exchange. The most-preferred method is the first in the list. It is RECOMMENDED that the algorithms be sorted by cryptographic strength, strongest first. Some additional guidance for this is given in [RFC3766].
RFC 4251 SSH Protocol Architecture January 2006
9.3.9. Traffic Analysis
Passive monitoring of any protocol may give an attacker some information about the session, the user, or protocol specific information that they would otherwise not be able to garner. For example, it has been shown that traffic analysis of an SSH session can yield information about the length of the password - [Openwall] and [USENIX]. Implementers should use the SSH_MSG_IGNORE packet, along with the inclusion of random lengths of padding, to thwart attempts at traffic analysis. Other methods may also be found and implemented.
9.4. Authentication Protocol
The purpose of this protocol is to perform client user authentication. It assumes that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session.
Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed.
The server may go into a sleep period after repeated unsuccessful authentication attempts to make key search more difficult for attackers. Care should be taken so that this doesn't become a self- denial of service vector.
9.4.1. 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).
The assumption stated above, that the Authentication Protocol only runs over a secure transport that has previously authenticated the server, is very important to note. People deploying SSH are reminded of the consequences of man-in-the-middle attacks if the client does not have a very strong a priori association of the server with the host key of that server. Specifically, for the case of the Authentication Protocol, the client may form a session to a man-in-
RFC 4251 SSH Protocol Architecture January 2006
the-middle attack device and divulge user credentials such as their username and password. Even in the cases of authentication where no user credentials are divulged, an attacker may still gain information they shouldn't have by capturing key-strokes in much the same way that a honeypot works.
9.4.2. 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 and debug messages, and may want to provide guidance to administrators on ways to keep this information away from unauthorized people. Developers should consider minimizing the amount of sensitive information obtainable by users during the authentication phase, in accordance with the local policies. For this reason, it is RECOMMENDED that debug messages be initially disabled at the time of deployment and require an active decision by an administrator to allow them to be enabled. It is also RECOMMENDED that a message expressing this concern be presented to the administrator of a system when the action is taken to enable debugging messages.
9.4.3. Local Security Policy
The 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. For example, local policy might allow a user to access files on the server, but not start an interactive shell. However, during the authentication protocol, it is not known whether the user will be accessing files, attempting to use an interactive shell, or even both. In any event, where local security policy for the server host exists, it MUST be applied and enforced correctly.
Implementers are encouraged to provide a default local policy and make its parameters known to administrators and users. At the discretion of the implementers, this default policy may be along the lines of anything-goes where there are no restrictions placed upon users, or it may be along the lines of excessively-restrictive, in
RFC 4251 SSH Protocol Architecture January 2006
which case, the administrators will have to actively make changes to the initial default parameters to meet their needs. Alternatively, it may be some attempt at providing something practical and immediately useful to the administrators of the system so they don't have to put in much effort to get SSH working. Whatever choice is made must be applied and enforced as required above.
9.4.4 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.
This risk can be mitigated by the use of passphrases on private keys; however, this is not an enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested.
The server could require both password and public key authentication; however, this requires the client to expose its password to the server (see the section on Password Authentication below.)
9.4.5. 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.
This vulnerability can be mitigated by using an alternative form of authentication. For example, public key authentication makes no assumptions about security on the server.
9.4.6. 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.
RFC 4251 SSH Protocol Architecture January 2006
9.5. Connection Protocol
9.5.1. 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.
If the client has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementers SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be targeted in port-forwarding operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems.
9.5.2. Proxy Forwarding
The SSH connection protocol allows for proxy forwarding of other protocols such as SMTP, 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. Essentially, the forwarding of these protocols may violate site- specific security policies, as they may be undetectably tunneled through a firewall. Implementers SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site-specific security policies may be upheld.
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.
9.5.3. 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. Users and administrators should, as a matter of course, use appropriate X11 security mechanisms to prevent unauthorized use of the X11 server. Implementers, administrators, and users who wish to further explore the security mechanisms of X11 are invited to read [SCHEIFLER] and analyze previously reported
RFC 4251 SSH Protocol Architecture January 2006
problems with the interactions between SSH forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 [CERT].
X11 display forwarding with SSH, by itself, is not sufficient to correct well known problems with X11 security [VENEMA]. However, X11 display forwarding in SSH (or other secure protocols), combined with actual and pseudo-displays that accept connections only over local IPC mechanisms authorized by permissions or access control lists (ACLs), does correct many X11 security problems, as long as the "none" MAC is not used. It is RECOMMENDED that X11 display implementations default to allow the display to open only over local IPC. It is RECOMMENDED that SSH server implementations that support X11 forwarding default to allow the display to open only over local IPC. On single-user systems, it might be reasonable to default to allow the local display to open over TCP/IP.
Implementers 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.
RFC 4251 SSH Protocol Architecture January 2006