Subspace Clustering based on kNN Algorithm by Lf55N2

VIEWS: 5 PAGES: 39

									          Seminar WS 06/07
          Computer Security


         The Secure Shell Protocol

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   Jia Zhu 262108   1
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   2
 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          3
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   4
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   5
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   6
Architecture




               The Secure Shell Protocol   Jia Zhu 262108   7
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   8
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   9
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   10
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   11
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   12
                                                      SSH
                           Client                                                            Host B
                            A                                                                                  Private Key


                                                      SSH
Host Name and Public Key
                                                                                             Host C
                                                                                                               Private Key




                                              Trust model (1)




Verification                                                    Certification Authority
Request




               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                                 13
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   14
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   15
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   16
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   17
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   18
uint32




         The Secure Shell Protocol   Jia Zhu 262108   19
string




         The Secure Shell Protocol   Jia Zhu 262108   20
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   21
mpint




        The Secure Shell Protocol   Jia Zhu 262108   22
name list




            The Secure Shell Protocol   Jia Zhu 262108   23
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   24
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   25
Message Numbers
       Protocol type               Range                                         Usage

                                                 Transport layer generic (e.g., disconnect, ignore, debug, etc.)
                                    1-19

 Transport Layer Protocol          20-29         Algorithm negotiation

                                                 Key exchange method specific (numbers can be reused for different
                                   30-49              authentication methods)

                                   50-59         User authentication generic

                                                 User authentication method specific (numbers can be reused for
User Authentication Protocol
                                   60-79              different authentication methods)


                                   80-89         Connection protocol generic
    Connection Protocol
                                   90-127        Channel related messages

Reserved for client protocols
                                  128-191        Reserved

      Local extensions            192-255        Local extensions

                                The Secure Shell Protocol   Jia Zhu 262108                                         26
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   27
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   28
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   29
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   30
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   31
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   32
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   33
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   34
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   35
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   36
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   37
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   38
The Secure Shell Protocol   Jia Zhu 262108   39

								
To top