Notes for Lecture-36

MCA 206: Advanced Computer Networks

Secure Shell (SSH) Protocol

The Secure Shell (SSH) provides a remote login service and is intended to replace the less secure
Telnet and rlogin programs. SSH is most often used to provide strong client/server
authentication—where the SSH client runs on the user’s desktop machine and the SSH server
runs on some remote machine that the user wants to log into—but it also supports message
integrity and confidentiality.

The latest version of SSH, version 2, consists of three protocols:

■ SSH-TRANS: a transport layer protocol
■ SSH-AUTH: an authentication protocol
■ SSH-CONN: a connection protocol

SSH-TRANS protocol provides an encrypted channel between the client and server machines. It
runs on top of a TCP connection. The first step is to set up an SSH-TRANS channel between
those two machines. The two machines establish this secure channel by first having the client
authenticate the server using RSA. Once authenticated, the client and server establish a session
key that they will use to encrypt any data sent over the channel. The SSH-TRANS protocol
includes a negotiation of the encryption algorithm the two sides are going to use. For example,
3DES is commonly selected. Also, SSH-TRANS protocol includes a message integrity check of
all data exchanged over the channel.

The next step is for the user to actually log onto the machine, or more specifically, authenticate
him- or herself to the server. SSH-AUTH allows three different mechanisms for doing this.
1. Since the two machines are communicating over a secure channel, it is OK for the user to
simply send his or her password to the server.

2. The second mechanism uses public key encryption.

3. The third mechanism, called host-based authentication, basically says that any user claiming to
be so-and-so from a certain set of trusted hosts is automatically believed to be that same user on
the server.

Finally, to support other insecure TCP-based applications, such as sending and receiving e-mail,
SSH uses the SSH-CONN protocol. The idea is illustrated in Figure 8.15, where we see a client
on host A indirectly communicating with a server on host B by forwarding its traffic through an
SSH connection. The mechanism is called port forwarding because when messages arrive at the
well-known SSH port on the server, SSH first decrypts the contents, and then “forwards” the
data to the actual port at which the server is listening.
 Transport Layer Security (TLS, HTTPS)

As the World Wide Web became popular and commercial enterprises began to take interest in it,
it become clear that some level of security would be necessary for the transactions on the Web.
Web Transactions Transport layer Security was designed to provide security at the transport
layer. It was derived from a security protocol called Secure Sockets Layer (SSL), designed by
Netscape to provide security on the WWW. TLS is a nonproprietary version of SSL designed by
IETF. Although SSL and TLS are unfortunately not interoperable, they differ in only minor
ways, so nearly all of this description of TLS applies to SSL.

Position of TLS

TLS lies between the application layer and the transport layer, (TCP) as shown in figure.

The reason for calling this “transport layer security” is that, from the application’s perspective,
this protocol layer looks just like a normal transport protocol, except for the fact that it is secure.
By running the secure transport layer on top of TCP, all of the normal features of TCP
(reliability, flow control, congestion control, etc.) are also provided to the application.

When HTTP is used in this way, it is known as HTTPS (Secure HTTP). In fact, HTTP itself is
unchanged. It simply delivers data to and accepts data from the TLS layer rather than TCP. For
convenience, a default TCP port has been assigned to “HTTPS” (443). That is, if you try to
connect to a server on TCP port 443, it’s likely that you will find yourself talking to the TLS
protocol, which will pass my data through to HTTP provided all goes well with authentication
and decryption.

Basic Concept

TLS allows two parties to exchange messages in a secure environment. To accomplish this goal,
a pair of TLS participants negotiates at runtime which cryptography to use. The two parties agree
on three protocols: an entity authentication protocol (Diffie-Hellman), message authentication
protocol (MD5, SHA-1) and an encryption / decryption protocol (DES, 3DES, AES).
TLS has two layers. The top layer includes three protocols, one for session setup, one for alerting
other party of an unusual situation and one for informing the establishment of security
parameters. The lower layer is used to encapsulate messages from the upper layer and the
application layer. The figure shown below depicts the layers of the TLS protocol.
Handshake protocol

The handshake protocol can be thought of as the means to get enough shared state to both ends
of a connection to enable secure communication to proceed. The components of this shared state
are the set of agreed-upon cryptographic algorithms and parameters for these algorithms such as
session keys, initialization vectors, and so on. The handshaking is done in four phases:

Phase I: In this phase, the client and the server announce their security capabilities and choose
those that are agreeable to both .Also, a session ID is established in this phase.

Phase II: Here, the server authenticates itself. The server may send its certificate, its public key
and may also request a certificate from the client.

Phase III: This is designed to authenticate the client if required by the server. Depending on the
selection of the cipher suite, the client may send a secret number called a pre-master secret to be
used for calculating the session keys.

Phase IV: In this last phase, the client and server send messages to establish cipher
specifications, which allow them to start using the keys and parameters.

Change Cipher Spec Protocol

This protocol is designed to activate the security services after all of the agreements are
confirmed in the handshake protocol. After exchanging the one message defined in this protocol,
the two parties can use the services.

Alert Protocol

The alert protocol is used to signal an error to other party. The packet exchanged defines the
severity level of the condition and the description of the alert.

Record Protocol
The record protocol defines a set of formats and procedures by which messages handed down
from the application layer are -
 fragmented or coalesced into blocks of a convenient size for the following steps
 optionally compressed
 integrity protected using a hash such as MD5
 encrypted
 passed to the lower layer (e.g., TCP) for transmission