the secure shell protocol jia zhu 2621081 seminar ws 06/07 computer security chair holder ： prof....

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


Agenda

History of SSH Architecture Related Concepts about SSH Protocol Workflow of SSH Connection Potential Security Problems of SSH


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.


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


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


Agenda



Architecture


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


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


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


Agenda



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


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


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


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.


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


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.


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


uint32


string


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


mpint


name list


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


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.


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


Agenda



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.


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.


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.


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.


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.


Workflow of SSH Connection

(6). Opening a Channel

After setting the service type, both sides open a new channel and begin to data transferring.


Agenda



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.



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



(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


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 2621081 seminar ws 06/07 computer security chair holder ： prof....

Documents

secure shell protocol

secure shell protocol

connection protocol

secure transport

transport layer protocol

secure subsystems

user authentication

transport protocol public