SSH by yaoyufang


									Transport Layer Security

              IT Security
Note: This set of slides should be read in
conjunction with Chapter 7 of the textbook
 (Stallings, Network Security Essentials)
>   Web Security Threats (book, §7.1)
>   Secure Socket Layer (book, §7.2)
>   Secure Shell (not in book)
Web Security Threats
 Like email, the Web is another very widely
  used application
 Again, the basic protocols (e.g. HTTP) do
  not provide security

   See Table 7.1 for (slightly dated) list of web
     This   expands all the time
Threats on the Web (Table 7.1)
                  Threats                              Consequences                Countermeasures
Integrity         Modification of user data            Loss of information         Cryptographic
                  Trojan horse browser                 Compromise of machine       checksums
                  Modification of memory               Vulnerabilty to all other
                  Modification of message traffic in   threats
Confidentiality   Eavesdropping on the Net             Loss of information         Encryption, web
                  Theft of info from server            Loss of privacy             proxies
                  Theft of data from client
                  Info about network configuration
                  Info about which client talks to
Denial of Service Killing of user threads              Disruptive                  Difficult to prevent
                  Flooding machine with bogus          Annoying
                  requests                             Prevent user from getting
                  Filling up disk or memory            work done
                  Isolating machine by DNS
Authentication    Impersonation of legitimate          Spoofing of user            Cryptographic
                  users                                Belief that false              techniques
                  Data forgery                         information is valid
Reminder: TCP/IP (Internet) Protocol Stack

   Variation on OSI model

               Application    e.g. HTTP, FTP, Email

                Transport     e.g. TCP, UDP

               Internetwork   e.g. IP

             Network Access   e.g. Ethernet, WiFi, PPP (modem)

                Physical      e.g. copper cable, radio spectrum
Q. So do you secure Internet traffic

   at the Application layer?
     e.g.   PGP or S/MIME
   at the Transport layer?
     e.g.   SSL/TLS
   at the Internetwork layer
     e.g.   IPsec
   at lower layers?
     e.g.   WEP (for wireless access points)
   at all layers?
     for   maximum security
A. It depends…
   on users
     Do you want it all to be transparent to users?
     Application layer security normally involves the

   on the importance of speed
     Encrypting the same data multiple times slows
      things down

   on security needs
     Hide   traffic pattern, etc

   on network topology
Web approach
   Communication on the web means web
    browsers talking to web servers using HTTP
   The web approach involves
     Leaving HTTP as it is
     Adding security just above the transport layer

   This is variously known as
     Secure    Socket Layer (SSL)
          Originated by Netscape
     Transport   Layer Security (TLS)
          Vendor-neutral standard
   SSL and TLS are practically the same
Uses of SSL
   Encrypting sensitive data sent between
    browser and web server
     Creditcard numbers
     Reading web email
     Online banking

   Authenticating participants
     To verify that web server is genuine (not spoof)
     To verify that user/browser is genuine (optional)
   Recognising an SSL page
URL   begins
 with https:
 rather than
 letting you
Closed lock
 icon on
SSL Protocol Overview
   SSL has 2 layers of protocols:
   One layer is a set of protocols for setting up a
    session, changing parameters, etc
     SSL Handshake Protocol
     SSL Change Cipher Spec Protocol
     SSL Alert Protocol

   The other is the “workhorse”, doing the
    encryption and authentication
     SSL   Record Protocol
SSL Architecture   “normal” mode
SSL Architecture
   SSL session
     Association     between client & server
         At [host, port] level
     Created by the SSL Handshake Protocol
     Defines algorithms, key size, etc
     May be shared by multiple SSL connections

   SSL connection
     Transient,peer-to-peer, communications link
     Associated with one SSL session
     SSL Handshake Protocol
                                      CLIENT                              SERVER
1.   Agree SSL version
2.   Select algorithms                             SSL version no./
                                               1,2 Cipher settings
3.   Authenticate each other using
                                                     Server Certificate
4.   Client generates shared
     secret session key (KS)and                 3
     sends to server encrypted with                  Client Certificate
     its public key (from its cert)                     (if required)

5.   Client and server now                         Session Key KS
     communicate using generated                4 (encrypted with
     shared secret keys (symmetric               server‟s public key)
                                               Secure Communication
Fig 7.6 has more detail
                                                     using KS

SSL Change Cipher Spec
   Change Cipher Spec Protocol
     Updates   cipher suite (algorithms, keys, etc)
      for current connection
     Very    simple message
          A single byte with the value 1
     Causes  the pending state (CipherSpec) to be
      copied into the current state
SSL Alert Protocol
   Alert Protocol
     Signals  warning or fatal alerts
     Fatal alert examples:
        unexpected_message
        bad_record_mac

        decompression_failure

     Warning   alert examples:
        no_certificate
        bad_certificate (e.g. signature does not verify)

        certificate revoked

        certificate expired
SSL Record Protocol
SSL Record Protocol Provides:
   Confidentiality
     using   symmetric encryption (shared secret

   Message integrity
     using   a MAC (again with shared secret key)

   Compression (optional)
     Compression     before encryption for
     e.g. Lempel-Ziv (ZIP) algorithm
Secure Shell (SSH)
   Initially designed for remote login applications
      e.g. in WIT, you can use it to log into pqlinux

   Uses TCP port 22

   Can also do encrypted file transfer

   Increasingly used to transport other applications
      This is called SSH port forwarding or tunnelling
SSH - Architecture
   SSH has a simple client-server architecture.
   An SSH server program listens on a computer‟s TCP
    port 22
   An SSH client program then connects to the SSH server
    program as required, a dialogue takes place, and it
    disconnects when finished

             SSH                         SSH
             Client             22

           e.g. on d04pc15            e.g. on pqlinux
SSH - Software
   Several SSH implementations exist, mostly free.
   Linux:
       Client: most popular is OpenSSH Client
          Run at the command line with the command “ssh”

       Server: most popular is OpenSSH Server
          Normally started automatically with Linux; can be started
            manually with command “sshd”

   Windows:
       Client: most popular is PuTTY
          Nice graphical interface

       Server: can also get OpenSSH Server for Windows
          Not common though to have SSH server on desktop machine
SSH – Software usage
   Linux client – typical usage:
           ssh –l jsheppard
              how I log in to read my email from home

   Windows client (PuTTY):
SSH for Remote Login
   Original purpose of ssh was to provide
    secure access to remote machines
     i.eto replace rlogin and telnet, which are both
      insecure (poor authentication; no encryption)

 SSH provides a secure virtual terminal,
  allowing the user to interactively execute
  commands on a remote computer as if it
  were local
 All transmitted data is encrypted
Typical Remote Login Session
SSH for Remote Command Execution
   SSH allows a command to be executed on a
    remote computer without the need to start an
    interactive terminal session
     Intendedto replace the rsh command that exists on
      many systems

   Usage :
    ssh –l username hostname command
    e.g. ssh –l jsheppard ‘rm
     deletes   a file from my account on the host
SSH for File Transfer
   The SSH protocol allows files to be transferred
    securely between clients and servers
     Insteadof FTP, which files in the clear, as well as
      username & password
   This use of SSH is usually called SCP (secure
   Implemented on client side with OpenSSH scp
    command (or pscp for Windows)
     Also   Windows graphical version called WinSCP
   typical usage (at DOS Command Prompt):
    pscp \docs\
     copying   a file from the WIT mail server to my home
SSH for Port Forwarding
 Port forwarding is one of the most
  powerful uses of SSH
 Uses:
     to provide secure transport for insecure
      TCP/IP applications (like email, web
      browsing, DB access, etc.)
     to bypass firewalls
SSH Port Forwarding – the problem
   Consider the following example:
     You  work for a company but you are currently away
      from the office
     You want to connect from outside to an internal
      host on the corporate network to access IMAP
     The IMAP port (143) is blocked by the corporate

   Normally, attempts to read your email would be
SSH Port Forwarding – the solution
   But say the following is the case:
      The SSH port (22) is open on the firewall
      You have an account on some machine (not necessarily the mail
       server) inside the network that runs an SSH server

   With SSH, you can set up a “SSH tunnel” from a local port on your
    client PC, through the SSH server within the company network, and
    on to the desired application (in this case the mail server, port 143).

   Then you get your mail client to connect to the local port on your
    client (from which you have set up an SSH tunnel to port 22) and
    that connection is forwarded to the desired application (the mail
SSH Port Forwarding

   In the diagram shown, the SSH server is on the
    same machine as other application servers, though
    this need not necessarily be the case.
Port Forwarding – WIT examples
   Reading newspapers and academic journals on the web from home:
      WIT has an institutional subscription to several websites (e.g.
       The Irish Times), where authentication is based on WIT‟s IP
       address range
      Thus only people within WIT can get access
      However, even if you‟re outside WIT, by forwarding a local port
       to WIT‟s web proxy ( via a WIT SSH server that is
       accessible from outside (e.g., you can appear to
       websites to be coming from within WIT.

   Access to pqlinux (login, FTP, web pages, etc)
      pqlinux is hidden behind the WIT firewall
      However, you can access it by forwarding a local port
       to the relevant pqlinux port (via another SSH server)
SSH Port Forwarding – detailed example(1)
     Objective: Read IMAP email from internal
      host called mailserver from outside company
       No  ports on host mailserver visible through
        company firewall
       Port 22 (SSH) on host is
        visible through firewall
            Say you have an account jbloggs on sshserver
SSH Port Forwarding – detailed
example (1) - cont.
   Solution: Use SSH port forwarding
     Select  a free port on your local PC, say 1143
     Link this to port 143 (email server) on mailserver by
      SSH port forwarding technique
     Any attempt to connect to port 1143 on your local
      PC is automatically redirected to port 143 on
     This is done via an SSH tunnel, connecting port
      1143 on the client PC to port 22 on and onwards to port 143
      on mailserver
SSH Port Forwarding – detailed
example (1) - cont.
Set   up command (also possible in PuTTY)
 ssh –l jbloggs –L 1143:mailserver:143
 (user is prompted for password)   Firewall
                                                     WIT Network

        Port          Internet                Port      Port
        1143                                   22       143

               Secure SSH Tunnel
SSH Port Forwarding – detailed
example (1) - cont.
   To use it: In your email client settings, set your incoming mail server
    to and port number for IMAP email to 1143:
      Note that host name localhost or IP address refer to
        the local machine
SSH Port Forwarding – detailed
example (2)
   Objective: Read web page on pqlinux from
    outside WIT
     (e.g.
     No ports on pqlinux visible through WIT firewall
     Port 22 (SSH) of is visible through
          Say you have an account jbloggs on
SSH Port Forwarding – detailed
example (2) - cont.
   Solution: Use SSH port forwarding
     Select  a free port on your local PC, say 8880
     Link this to port 80 (web server) on pqlinux by SSH
      port forwarding technique
     Any attempt to connect to port 8880 on your local
      PC is automatically redirected to port 80 on pqlinux
     This is done using an SSH tunnel, connecting port
      8880 on the client PC to port 22 on and
      onwards to port 80 on pqlinux

   To use it: In web browser, type:
SSH Port Forwarding – detailed
example (2) - cont.
Set   up command (also possible in PuTTY)
 ssh –l jbloggs –L 8880:pqlinux:80
 (user is prompted for password)
                                                     WIT Network

        Port          Internet                Port      Port
        8880                                   22        80

               Secure SSH Tunnel
SSH Port Forwarding – security
   Secure access to insecure services
     Can transport anykind of application –
      email, web browsing, file transfer, etc
   Firewall bypass
     Good:  forces users to only access internal services in
      a secure manner
     Bad: gives users (& thus potentially attackers) means
      to access arbitrary internal services.
     Bad: If only password authentication is used, all
      attacker needs is password of any user on SSH
      server to, for example, browse company Intranet.
SSH Protocol Basics
   User Authentication (by server)
     RSA/DSA Public             Key Authentication
         Server maintains copy of user‟s public key.

         Method 1: signed session id: The client signs a session id.
          The server tries to verify it with the corresponding public key.

         Method 2: challenge-response: Server encrypts a random
          number with the user‟s public key; Client proves identity by
          decrypting it

     Password        Authentication
         The user enters a username and password (encrypted)
SSH Protocol Basics
   User/Host Authentication (by server)
    Uses .rhosts file
       Simply  a list of usernames and hosts from
        which they can connect (without further
       Effectively a list of trusted hosts

       Insecure and not recommended (danger of
PuTTY Key Generation
1.   select which type of key you want to generate, and also
     select the strength of the key
2.   press the „Generate‟ button, to actually generate the
3.   select a comment field and a passphrase
4.   save the private key to disk; press the „Save private
     key‟ button, you could also use Pageant so that your
     decrypted key is only held in memory rather than on
5.   You may also want to copy the public key to your
Configuring the server to accept
your public key for authentication
   If your server is using the SSH 1 protocol,
    you should change into the .ssh directory
    and open the file authorized_keys with
    your favourite editor

   Then switch to the PuTTYgen window,
    select all of the text in the „Public key for
    pasting into authorized_keys file‟
Configuring the server to accept
your public key for authentication
   Then, switch back to the PuTTY window and insert the
    data into the open file, making sure it ends up all on one
    line. Save the file.

   Use the command

chmod go-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

to ensure that your home directory, your .ssh directory, and
    any other files involved are not group-writable or world-
Configuring PuTTY to attempt
authentication using your private key
   Select the private key in PuTTY's configuration.

   Specify the key file on the command line with the
    -i option

   Load the private key into Pageant. In this case
    PuTTY will automatically try to use it for
    authentication if it can.
Pageant Benefits
   Able to open multiple SSH sessions
    without having to type a passphrase every

   Gives you the security benefit of never
    storing a decrypted private key on disk.
Pageants Disadvantages
   Windows unfortunately provides no way to protect pieces of memory
    from being written to the system swap file. So if Pageant is holding
    your private keys for a long period of time, it's possible that
    decrypted private key data may be written to the system swap file,
    and an attacker who gained access to your hard disk later on might
    be able to recover that data

   Windows prevents programs from accidentally accessing one
    another's memory space, it does allow programs to access one
    another's memory space deliberately, for special purposes such as
    debugging. This means that if you allow a virus, trojan, or other
    malicious program on to your Windows system while Pageant is
    running, it could access the memory of the Pageant process, extract
    your decrypted authentication keys, and send them back to its
SSH Key Types
   An RSA key for use with the SSH 1 protocol.
   An RSA key for use with the SSH 2 protocol.
   A DSA key for use with the SSH 2 protocol.

   DSA has an intrinsic weakness which makes it
    very easy to create a signature which contains
    enough information to give away the private key!
Key Fingerprint
   The „Key fingerprint‟ box shows you a
    fingerprint value for the generated key

   Computationally infeasible for someone to
    invent a second key with the same
SSH Protocol Basics
   Data Confidentiality
     Achieved as usual with conventional encryption
      using generated session key
          Algorithm choices include AES, 3DES, Blowfish, …

   Data Integrity
     MAC-based
          Choice of algorithms
Critical Web Application Security
   Non-validated input -- Attackers can use information not
    validated before used by a Web application to reach
    backend components

   Broken access control -- Results from improper
    enforcement of restrictions on what authenticated users
    are allowed to do; attackers exploit to access other
    accounts or use unauthorized functions

   Broken authentication and session management --
    Account credentials and session tokens not properly
    protected, allowing attackers to compromise passwords,
    keys, session cooker or tokens, and assume the
    identities of other users
Critical Web Application Security
   Cross site scripting -- The Web application is used as a mechanism
    to transport an attack to the end user's browser. A successful attack
    can disclose the end user's session token or spoof content to fool
    the user

   Buffer overflows -- Web application components written in
    languages that do not properly validate input can crash and in some
    cases, be used to take control of a process. These components can
    include CGI, libraries, drivers and Web application server

   Injection flaws -- Web applications pass parameters when they
    access external system or the local OS. If an attacker embeds
    malicious commands in the parameters, the external system may
    execute those commands on behalf of the Web application
Critical Web Application Security
   Improper error handling -- Refers to error conditions that
    occur during normal operations that are not handled
    properly. Attackers can use these to gain detailed
    system information, deny service, and cause security
    mechanisms to fail or crash the server

   Insecure storage -- Web applications that use
    cryptographic functions to protect information and
    credentials have proven difficult to code properly,
    resulting in weak protection
Critical Web Application Security
   Denial of service -- attackers consume Web
    application resources to the point where other
    legitimate users can no longer access or use the
    application. Attackers can also lock users out of
    their accounts or cause an application to fail

   Insecure configuration management -- Web
    servers have many configuration options that
    effect security and are not secure out of the box.
    Having a strong configuration standard is critical

To top