The Secure Shell Protocol Jia Zhu Seminar WS 06/07 Computer Security Chair holder ： Prof. Dr. Joachim von zur Gathen Tutor: Michael Nüsken, Daniel Loebenberger Name ： Jia Zhu Student ID ： Date: The Secure Shell Protocol

The Secure Shell Protocol Jia Zhu Agenda History of SSH Architecture Related Concepts about SSH Protocol Workflow of SSH Connection Potential Security Problems of SSH

The Secure Shell Protocol Jia Zhu  Goal of Secure Shell (SSH) Protocol - a protocol for secure remote login and other secure network services over an insecure network.  Usage login a remote machine and execute commands by using public-key cryptography to authenticate both remote server and local client support tunneling, forwarding arbitrary TCP ports and X11 connection transfer files using the associated SFTP or SCP protocols.

The Secure Shell Protocol Jia Zhu History of SSH  1995, SSH Tatu Ylönen Helsinki University of Technology, Finland SSH Communications Security Corp. Attachmate organization, which markets Reflection for Secure IT

The Secure Shell Protocol Jia Zhu History of SSH  1996, SSH-2 (incompatible with SSH-1) - RFC (Request of Comments) memorandum - Proposed as a new Internet standard by the Internet Engineering Task Force (IETF) working group - security and feature improvements over SSH-1

The Secure Shell Protocol Jia Zhu Agenda History of SSH Architecture Related Concepts about SSH Protocol Workflow of SSH Connection Potential Security Problems of SSH

The Secure Shell Protocol Jia Zhu Architecture

The Secure Shell Protocol Jia Zhu Transport Layer Protocol performs connection setup, (DH) key exchange, encryption and data integrity protection may optionally provide compression derive a unique session id that may be used by higher-level protocols run over a TCP/IP connection or other reliable data stream service request

The Secure Shell Protocol Jia Zhu User Authentication Protocol provide a suite of mechanisms to authenticate the client to the server Individual mechanism specified in the authentication protocol uses the session id provided by the transport layer protocol and also depend on the security and integrity guarantees of the transport protocol Public Key, Password and Host-Based Authentication

The Secure Shell Protocol Jia Zhu Connection Protocol multiplex the encrypted tunnel into several logical channels of data over the confidential and authenticated transport specify channels for accessing an interactive shell, for proxy-forwarding various external protocols over the secure transport and secure subsystems on the server host provide them to higher network application protocols

The Secure Shell Protocol Jia Zhu Agenda History of SSH Architecture Related Concepts about SSH Protocol Workflow of SSH Connection Potential Security Problems of SSH

The Secure Shell Protocol Jia Zhu Host keys host server : host key  1:1 ; 1:N ; N:1 used to verify that the client is really talking to the correct server during key exchange

The Secure Shell Protocol Jia Zhu Verification Request Trust model (2) SSH Client A Host Name and Public Key Host B Host C Private Key Trust model (1) Certification Authority Client AClient BClient C Root Key from CA

The Secure Shell Protocol Jia Zhu A problem from host-key association host key association not checked when connecting to the host for the first time allow communication without prior communication of host keys or certification vulnerable to activate man-in-the-middle attacks Solution: normally NOT allow such connections by default

The Secure Shell Protocol Jia Zhu Security Properties (1). All encryption, integrity, and public key algorithms used are well-known, well-established algorithms (2). All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest attacks (3). 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.

The Secure Shell Protocol Jia Zhu Packet Size and Overhead the increase in packet size due to new headers, padding, and the Message Authentication Code (MAC). The minimum packet size is 28 bytes (depending on negotiated algorithms).

The Secure Shell Protocol Jia Zhu Localization and Character Set Support For the most case, not directly pass text that would be displayed to the user However, some places where such data might be passed. When applicable, the character set for the data must be explicitly specified. In most places, ISO UTF-8 encoding is used. When applicable, a field is also provided for a language tag.

The Secure Shell Protocol Jia Zhu Data Type Representations Byte: an arbitrary 8-bit value (octet) Boolean: stored as a single byte. 0 represents FALSE, 1 represents TRUE uint32: a 32-bit unsigned integer uint64: a 64-bit unsigned integer string: Arbitrary length binary string, a uint32 containing its length

The Secure Shell Protocol Jia Zhu uint32

The Secure Shell Protocol Jia Zhu string

The Secure Shell Protocol Jia Zhu Data Type Representations (cont.) mpint: multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the MSB of the first byte of the data partition. If the MSB would be set 1 for a positive number, the number must be preceded by a zero byte. The value zero must be stored as a string with zero bytes of data. name-list: A string containing a comma-separated list of names, represented as a uint32 containing its length

The Secure Shell Protocol Jia Zhu mpint

The Secure Shell Protocol Jia Zhu name list

The Secure Shell Protocol Jia Zhu Algorithm and Method Naming Names that do not contain an at-sign comma (","), white space, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL) are reserved to be assigned by IETF CONSENSUS. only valid if they are first registered with the IANA case-sensitive, and must NOT be longer than 64 characters. Examples include "3des-cbc", "sha-1", "hmac-sha1", and "zlib".

The Secure Shell Protocol Jia Zhu Algorithm and Method Naming Anyone can define additional algorithms or methods by using names in the format e.g., "ourcipher- The format of the part preceding the at-sign is not specified; however, these names must be printable US-ASCII strings, and must NOT contain the comma character (","), white space, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). They must have only a single at-sign in them. The part following the at-sign must be a valid, fully qualified domain name controlled by the person or organization defining the name. Names are case-sensitive, and must NOT be longer than 64 characters. It is up to each domain how it manages its local namespace.

The Secure Shell Protocol Jia Zhu Message Numbers Protocol typeRangeUsage Transport Layer Protocol 1-19 Transport layer generic (e.g., disconnect, ignore, debug, etc.) 20-29Algorithm negotiation Key exchange method specific (numbers can be reused for different authentication methods) User Authentication Protocol 50-59User authentication generic User authentication method specific (numbers can be reused for different authentication methods) Connection Protocol 80-89Connection protocol generic Channel related messages Reserved for client protocols Reserved Local extensions Local extensions

The Secure Shell Protocol Jia Zhu Agenda History of SSH Architecture Related Concepts about SSH Protocol Workflow of SSH Connection Potential Security Problems of SSH

The Secure Shell Protocol Jia Zhu Workflow of SSH Connection (1). Protocol Version Exchange When the connection has been established, both sides must send an identification string to exchange SSH protocol version. The maximum length of the string is 255 characters, including the Carriage Return and Line Feed. The part of the identification string preceding the Carriage Return and Line Feed is used in the Diffie- Hellman key exchange. Key exchange will begin immediately after sending this identifier. All packets following the identification string shall use the Binary Packet Protocol.

The Secure Shell Protocol Jia Zhu Workflow of SSH Connection (2). Key Exchange(kex): Using Binary Packet Protocol, key exchange begins by each side sending name-lists of supported algorithms. Each side has a preferred algorithm in each category. Each side may guess which algorithm the other side is using, and may send an initial key exchange packet according to the algorithm, if appropriate for the preferred method.

The Secure Shell Protocol Jia Zhu Workflow of SSH Connection (3). Output from Key Exchange: (a). a shared secret K (b). an exchange hash H Encryption and authentication keys are derived from these two values. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged.

The Secure Shell Protocol Jia Zhu Workflow of SSH Connection (4). Service Request: After the key exchange, the client requests a service. The service is identified by a name. When the service starts, it may have access to the session identifier generated during the key exchange. If the server supports the service (and permits the client to use it), it must respond with message numbers and service name. After a key exchange with implicit server authentication, the client must wait for a response to its service request message before sending any further data.

The Secure Shell Protocol Jia Zhu Workflow of SSH Connection (5). Authentication Request: The server drives the authentication by telling the client which authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server. The server should have a timeout for authentication and disconnect if the authentication has not been accepted within the timeout period. When the server accepts authentication, it must respond with the authentication success message.

The Secure Shell Protocol Jia Zhu Workflow of SSH Connection (6). Opening a Channel After setting the service type, both sides open a new channel and begin to data transferring.

The Secure Shell Protocol Jia Zhu Agenda History of SSH Architecture Related Concepts about SSH Protocol Workflow of SSH Connection Potential Security Problems of SSH

The Secure Shell Protocol Jia Zhu Potential Security Problems (1). Since SSH-1 has inherent design flaws which make it vulnerable to, e.g., man-in-the-middle attacks, it is now generally considered obsolete and should be avoided by explicitly disabling fallback to SSH-1. (2). It is important to verify unknown public keys before accepting them as valid. Accepting an attacker's public key as a valid public key has the effect of disclosing the transmitted password and allowing man in the middle attacks.

The Secure Shell Protocol Jia Zhu Potential Security Problems (3). Man-in-the-middle, Covert Channels, etc. (4). Backdoors exists for hackers to execute any code using interactive authentication and can cause service not to function.

The Secure Shell Protocol Jia Zhu Potential Security Problems (5). When client first login the server, it accept host key without examining if the host key belongs to the right server. (6). Can not improve any security for server. If server is attacked or controlled, SSH transferring can not be safe anymore (7). Above the TCP/IP Layer, and can not avoid DoS attack (8). Can not avoid hidden channels problems

The Secure Shell Protocol Jia Zhu Potential Security Problems (9). Debug message may reveal server or client information without protection. (10). Port forwarding may bypass the firewall since the data in the channel is encrypted. (11). Have to know server’s IP and port, know which software can be used and how to configure the software, not transparent for users (12). manually manage host key for user authentication, not flexible and secure enough. (13). Client can find server quickly but server can not find client easily, can not bidirectional communication.

The Secure Shell Protocol Jia Zhu