The Secure Shell Protocol Jia Zhu 262108 1
Seminar WS 06/07Computer Security
Chair holder : Prof. Dr. Joachim von zur GathenTutor: Michael Nüsken, Daniel LoebenbergerName : Jia ZhuStudent ID: 262108Date: 30.10.2006
The Secure Shell Protocol
The Secure Shell Protocol Jia Zhu 262108 2
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 3
Goal of Secure Shell (SSH) Protocol - a protocol for secure remote login and other secure network services over an
insecure network.
Usagelogin 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 4
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 5
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 6
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 8
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 9
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 10
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 11
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 12
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 13
VerificationRequest
Trust model (2)
SSH
SSH
Client A
Host Name and Public Key
Host B
Host C
Private Key
Private Key
Trust model (1)
Certification Authority
Client A Client B Client C
Root Key from CA Root Key from CARoot Key from CA
The Secure Shell Protocol Jia Zhu 262108 14
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 262108 15
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 16
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 17
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 18
Data Type Representations
Byte: an arbitrary 8-bit value (octet) Boolean: stored as a single byte. 0 represent
s 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 21
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 24
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 ch
aracters.
Examples include "3des-cbc", "sha-1", "hmac-sha1", and "zlib" .
The Secure Shell Protocol Jia Zhu 262108 25
Algorithm and Method Naming Anyone can define additional algorithms or methods by using
names in the format name@domainname, e.g., "[email protected]".
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 d
omain 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 26
Message NumbersProtocol type Range Usage
Transport Layer Protocol
1-19Transport layer generic (e.g., disconnect, ignore, debug, etc.)
20-29 Algorithm negotiation
30-49Key exchange method specific (numbers can be reused for different
authentication methods)
User Authentication Protocol
50-59 User authentication generic
60-79
User authentication method specific (numbers can be reused for different authentication methods)
Connection Protocol80-89 Connection protocol generic
90-127 Channel related messages
Reserved for client protocols128-191 Reserved
Local extensions 192-255 Local extensions
The Secure Shell Protocol Jia Zhu 262108 27
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 28
Workflow of SSH Connection (1). Protocol Version Exchange When the connection has been established, both sid
es 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 29
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 30
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 31
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 32
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 33
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 34
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 35
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 36
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 37
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 38
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.