Seminar WS 06/07 Computer Security

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

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 262108

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 262108

History of SSH • 1995, SSH-1 ----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 262108

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 262108

Architecture The Secure Shell Protocol Jia Zhu 262108

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 262108

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 262108

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 262108

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 262108

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

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 NOTallow such connections by default The Secure Shell Protocol Jia Zhu 262108

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 262108

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 262108

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-10646 UTF-8 encoding is used. When applicable, a field is also provided for a language tag. The Secure Shell Protocol Jia Zhu 262108

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 262108

uint32 The Secure Shell Protocol Jia Zhu 262108

string The Secure Shell Protocol Jia Zhu 262108

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 262108

mpint The Secure Shell Protocol Jia Zhu 262108

name list The Secure Shell Protocol Jia Zhu 262108

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 262108

Algorithm and Method Naming • Anyone can define additional algorithms or methods by using names in the format name@domainname, e.g., "ourcipher-cbc@example.com". • 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 262108

Message Numbers The Secure Shell Protocol Jia Zhu 262108

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 262108

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 262108

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 262108

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 262108

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 262108

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 262108

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 262108

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 262108

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 262108

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 262108

The Secure Shell Protocol Jia Zhu 262108

Seminar WS 06/07 Computer Security