Transport Level

Security
unit4
Transport Level Security
1. Web Security Considerations
2. Secure Socket layer
3. HTTPS
4. Secure Shell (SSH)
 1.Web Security Considerations
• The World Wide Web is fundamentally a client/server application running over
the Internet and TCP/IP intranets.
• Web presents new challenges:
1.The Internet is two-way. Unlike traditional publishing environments—even
electronic publishing systems involving teletext, voice response, or fax-back— the
Web is vulnerable to attacks on the Web servers over the Internet
2. The Web is increasingly serving as a highly visible outlet for corporate and
product information and as the platform for business transactions. Reputations
can be damaged and money can be lost if the Web servers are subverted
3.Although Web browsers are easy to use and Web servers are easy to configure
and manage, and Web content is increasingly easy to develop: the underlying
software is complex which may hide many potential security flaws.
 1.Web Security Considerations
4.A Web server can be subverted and an attacker may be able to gain access
to data and systems not part of the Web itself but connected to the server at
the local site.
5. Casual and untrained (in security matters) users are common clients for
Web-based services who are not aware of the security risks that exist and do
not have the tools or knowledge to take effective countermeasures
 1.Web Security Considerations

• Web Security Threats

• Web Traffic Security Approaches
1.Web Security Threats
Types of security threats faced when using the Web:
1. One way to group these threats is in terms of passive and active
attacks. Passive attacks include eavesdropping on network traffic
between browser and server and gaining access to information on a
Web site that is supposed to be restricted. Active attacks include
impersonating another user, altering messages in transit between
client and server, and altering information on a Web site.
2. Another way to classify Web security threats is in terms of the
location of the threat: Web server, Web browser, and network traffic
between browser and server
 2.Web Traffic Security
Approaches
• The various approaches considered are similar in the services but they differ
with respect to their scope of applicability and their relative location within
the TCP/IP protocol stack.
• Figure 16.1 illustrates this difference.
1. One way to provide Web security is to use IP security (IPsec)Fig
16.1a .The advantage of using IPsec is that it is transparent to end users
and applications and provides a general-purpose solution.It includes a
filtering capability so only selected traffic need incur the overhead of IPsec
processing.
2. Another general-purpose solution is to implement security just above
TCP (Figure 16.1b). Example of this approach is the Secure Sockets Layer
(SSL) and the follow-on Internet standard known as Transport Layer
Security (TLS).
2.Web Traffic Security Approaches
• For full generality, SSL (or TLS) could be provided as part of the
underlying protocol suite and therefore be transparent to applications.
• Alternatively, SSL can be embedded in specific packages. For example,
Netscape and Microsoft Explorer browsers come equipped with SSL,
and most Web servers have implemented the protocol.
3.Application-specific security services are embedded within the
particular application. Figure 16.1c shows examples of this architecture.
The advantage of this approach is that the service can be tailored to the
specific needs of a given application.
2.Web Traffic Security Approaches
2.Web Traffic Security
Approaches
2.Secure Socket layer
1. SSL Architecture
2. SSL Record Protocol
3. Change Cipher Spec Protocol
4. Alert protocol
5. Handshake Protocol
1.SSL Architecture
• SSL is designed to make use of TCP to provide a reliable end-to-end
secure service.
• SSL is not a single protocol but rather two layers of protocols, as
illustrated in Figure 16.2.
• The SSL Record Protocol provides basic security services to various
higher layer protocols. In particular, the Hypertext Transfer Protocol
(HTTP), which provides the transfer service for Web client/server
interaction, can operate on top of SSL.
• Three higher-layer protocols are defined as part of SSL: the Handshake
Protocol,The Change Cipher Spec Protocol, and the Alert Protocol.
 1.SSL Architecture
• SSL session and the SSL connection:
Connection:
A connection is a transport that provides a suitable type of service.
 For SSL, such connections are peer-to-peer relationships.
The connections are transient. Every connection is associated with one session.
• Session: An SSL session is an association between a client and a server.
Sessions are created by the Handshake Protocol.
Sessions define a set of cryptographic security parameters which can be shared
among multiple connections.
Sessions are used to avoid the expensive negotiation of new security
parameters for each connection.
 1.SSL Architecture
A session state is defined by
• Session identifier: An arbitrary byte sequence chosen by the server to
identify an active or resumable session state.
• Peer certificate: An X509.v3 certificate of the peer.
• Compression method: algorithm used to compress data before encryption.
• Cipher spec: Specifies the bulk data encryption algorithm and a hash
algorithm used for MAC calculation. It also defines cryptographic attributes
such as the hash_size.
• Master secret: 48-byte secret shared between the client and server.
• Is resumable: A flag indicating whether the session can be used to initiate
new connections.
 1.SSL Architecture
A connection state is defined by
• Server and client random: Byte sequences that are chosen by the server and client for
each connection.
• Server write MAC secret: The secret key used in MAC operations on data sent by the
server.
• Client write MAC secret: The secret key used in MAC operations on data sent by the client.
• Server write key: The secret encryption key for data encrypted by the server and
decrypted by the client.
• Client write key: The symmetric encryption key for data encrypted by the client and
decrypted by the server.
• Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV)
is maintained for each key.
• Sequence numbers: Each party maintains separate sequence numbers for transmitted and
received messages for each connection.
1.SSL Architecture
 2.SSL Record Protocol
The SSL Record Protocol provides two services for SSL connections:
• Confidentiality: The Handshake Protocol defines a shared secret key that is
used for conventional encryption of SSL payloads.
• Message Integrity: The Handshake Protocol also defines a shared secret key
that is used to form a message authentication code (MAC).
Figure 16.3 indicates the overall operation of the SSL Record Protocol.
The Record Protocol takes an application message to be transmitted, fragments
the data into manageable blocks, optionally compresses the data, applies a
MAC, encrypts, adds a header, and transmits the resulting unit in a TCP
segment.
 Received data are decrypted, verified, decompressed, and reassembled before
being delivered to higher-level users.
 2.SSL Record Protocol
The first step is fragmentation. Each upper-layer message is fragmented
into blocks of 214 bytes or less.
 Next, compression is optionally applied. Compression must be lossless
and may not increase the content length by more than 1024 bytes.
The next step in processing is to compute a message authentication code
over the compressed data. For this purpose, a shared secret key is used.
Next, the compressed message plus the MAC are encrypted using
symmetric encryption. Encryption may not increase the content length by
more than 1024 bytes, so that the total length may not exceed 214 + 2048.
The following encryption algorithms are permitted:AES,IDEA,RC2 AND
DES40,DES FORTEZZA AND 3DES
 2.SSL Record Protocol
• Note that the MAC is computed before encryption takes place and that the MAC is
then encrypted along with the plaintext or compressed plaintext.
• For block encryption, padding may be added after the MAC prior to encryption.
• The final step of SSL Record Protocol processing is to prepare a header consisting of
the following fields:
 Content Type (8 bits): The higher-layer protocol used to process the enclosed
fragment.
 Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the value is 3.
 Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is 0.
Compressed Length (16 bits): The length in bytes of the plaintext fragment.
The content types that have been defined are change_cipher_spec, alert, handshake,
and application_data. The first three are the SSL-specific protocols.
2.SSL Record Protocol
2.SSL Record Protocol
SSL record format:
3.Change Cipher Spec Protocol
• This is a SSL-specific protocols that is simple and uses the SSL Record
Protocol
• This protocol consists of a single message (Figure 16.5a), which
consists of a single byte with the value 1.
• The sole purpose of this message is to cause the pending state to be
copied into the current state, which updates the cipher suite to be
used on this connection.
3.Change Cipher Spec Protocol
4.Alert Protocol
• Its used to convey SSL-related alerts to the peer entity.
• As with other applications that use SSL, alert messages are
compressed and encrypted, as specified by the current state.
• Each message in this protocol consists of two bytes (Figure 16.5b).
The first byte takes the value warning (1) or fatal (2) to convey the
severity of the message.
• If the level is fatal, SSL immediately terminates the connection.
Other connections on the same session may continue, but no new
connections on this session may be established.
• The second byte contains a code that indicates the specific alert.
4.Alert Protocol
First, we list those alerts that are always fatal:
1. unexpected_message: An inappropriate message was received.
2. bad_record_mac: An incorrect MAC was received.
3. decompression_failure: The decompression function received improper input
4. handshake_failure: Sender was unable to negotiate an acceptable set of security parameters
given the options available.
5. illegal_parameter: A field in a handshake message was out of range or inconsistent with other
fields.
6. close_notify: Notifies the recipient that sender will not send any more messages on this
connection. Each party is required to send a close_notify alert before closing the write side of a
connection.
7. no_certificate: May be sent in response to a certificate request if no appropriate certificate is
available.
8. bad_certificate: A received certificate was corrupt
9. unsupported_certificate: The type of the received certificate is not supported.
10. certificate_revoked: A certificate has been revoked by its signer.
 5.Handshake Protocol
• The most complex part of SSL is the Handshake Protocol.
• This protocol allows the server and client to authenticate each other and to
negotiate an encryption and MAC algorithm and cryptographic keys to be used
to protect data sent in an SSL record.
• The Handshake Protocol is used before any application data is transmitted.
• It consists of a series of messages exchanged by client and server.
• All of these have the format shown in Figure 16.5c. Each message has three
fields:
 Type (1 byte): Indicates one of 10 messages. Table 16.2 lists the defined
message types.
 Length (3 bytes): The length of the message in bytes.
 Content ( bytes): The parameters associated with this message; these are listed
in Table 16.2.
 5.Handshake Protocol
• Figure 16.6 shows the initial exchange needed to establish a logical connection
between client and server. The exchange can be viewed as having four phases.
PHASE 1. ESTABLISH SECURITY CAPABILITIES : initiate a logical connection and to
establish the security capabilities that will be associated with it.
• The exchange is initiated by the client, which sends a client_hello message with the
following parameters :
• Version: The highest SSL version
• Random: A client-generated random structure that serve as nonces and are used
during key exchange to prevent replay attacks
• Session ID: A variable-length session identifier
• CipherSuite: This is a list that contains the combinations of cryptographic
algorithms(RSA,fixed Diffie-hellman, Fortezza are e.g.) supported by the client, in
decreasing order of preference
• Compression Method: This is a list of the compression methods the client supports
5.Handshake Protocol
5.Handsh
ake
Protocol
5.Handshake Protocol
PHASE 2. SERVER AUTHENTICATION AND KEY EXCHANGE
• The server sends its certificate if it needs to be authenticated
• The message contains one or a chain of X.509 certificates.The certificate message is required for
any agreed-on key exchange method except anonymous Diffie-Hellman.
• Next, a server_key_exchange message may be sent if it is required. It is not required in two
instances: (1) The server has sent a certificate with fixed Diffie-Hellman parameters or (2) a RSA
key exchange is to be used.
• Next, a nonanonymous server (server not using anonymous Diffie-Hellman) can request a
certificate from the client. The certificate_request message includes two parameters:
certificate_type and certificate_authorities.
• The certificate type indicates the public-key algorithm and its use.
• The second parameter in the certificate_request message is a list of acceptable certificate
authorities. The final message in phase 2, and one that is always required, is the server_done
message, which is sent by the server to indicate the end of the server hello and associated
messages. After sending this message, the server will wait for a client response. This message has
no parameters
5.Handshake Protocol
PHASE 3. CLIENT AUTHENTICATION AND KEY EXCHANGE
• On receipt of the server_done message, client verify that the server provided a valid
certificate and check that the server_hello parameters are acceptable.
• If all is satisfactory, the client sends one or more messages back to the server.
• If the server has requested a certificate, the client begins this phase by sending a
certificate message. If no suitable certificate is available, the client sends a
no_certificate alert.
• Next is the client_key_exchange message, which must be sent in this phase.
• The content of the message depends on the type of key exchange(RSA,fixed Diffie-
hellman,etc).
• Finally, in this phase, the client may send a certificate_verify message to provide
explicit verification of a client certificate.
5.Handshake Protocol

PHASE 4. FINISH
• This phase completes the setting up of a secure connection.
• The client sends a change_cipher_spec message and copies the
pending CipherSpec into the current CipherSpec.
• The client then immediately sends the finished message which
verifies that the key exchange and authentication processes were
successful
5.Handshake Protocol:
Cryptographic Computations
1. MASTER SECRET CREATION :The shared master secret is a one-time 48-byte
value (384 bits) generated for this session by means of secure key exchange.
• The creation is in two stages. First, a pre_master_secret is exchanged. Second,
the master_secret is calculated by both parties.
• For pre_master_secret exchange, there are two possibilities.
• RSA: A 48-byte pre_master_secret is generated by the client, encrypted with
the server’s public RSA key, and sent to the server. The server decrypts the
ciphertext using its private key to recover the pre_master_secret.
• Diffie-Hellman: Both client and server generate a Diffie-Hellman public key.
After these are exchanged, each side performs the Diffie-Hellman calculation to
create the shared pre_master_secret.
5.Handshake Protocol:
Cryptographic Computations
2.GENERATION OF CRYPTOGRAPHIC PARAMETERS
• CipherSpecs require a client write MAC secret, a server write MAC
secret, a client write key, a server write key, a client write IV, and a
server write IV, which are generated from the master secret in that
order.
• These parameters are generated from the master secret by hashing
the master secret into a sequence of secure bytes of sufficient length
for all needed parameters.
3.HTTPS
• HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to
implement secure communication between a Web browser and a Web
server.
• The HTTPS capability is built into all modern Web browsers.
• Its use depends on the Web server supporting HTTPS communication.
For example, search engines do not support HTTPS.
• The principal difference seen by a user of a Web browser is that URL
(uniform resource locator) addresses begin with https:// rather than
http://. A normal HTTP connection uses port 80. If HTTPS is specified,
port 443 is used, which invokes SSL.
3.HTTPS
• When HTTPS is used, the following elements of the communication
are encrypted:
URL of the requested document
Contents of the document
Contents of browser forms (filled in by browser user)
Cookies sent from browser to server and from server to browser
 Contents of HTTP header
3.HTTPS
1.Connection Initiation:For HTTPS, the agent acting as the HTTP client also acts as the TLS client.
The client initiates a connection to the server on the appropriate port and then sends the TLS
ClientHello to begin the TLS handshake.
 When the TLS handshake has finished, the client may then initiate the first HTTP request. All
HTTP data is to be sent as TLS application data. Normal HTTP behavior, including retained
connections, should be followed.
 We need to be clear that there are three levels of awareness of a connection in HTTPS.
 At the HTTP level, an HTTP client requests a connection to an HTTP server by sending a
connection request to the next lowest layer.
 Typically, the next lowest layer is TCP, but it also may be TLS/SSL. At the level of TLS, a session is
established between a TLS client and a TLS server.
 This session can support one or more connections at any time. As we have seen, a TLS request
to establish a connection begins with the establishment of a TCP connection between the TCP
entity on the client side and the TCP entity on the server side.
3.HTTPS
2.Connection Closure: An HTTP client or server can indicate the closing of a connection .
 Connection: close - This indicates that the connection will be closed after this record is
delivered.
 The closure of an HTTPS connection requires that TLS close the connection with the peer
TLS entity on the remote side, which will involve closing the underlying TCP connection.
At the TLS level, the proper way to close a connection is for each side to use the TLS alert
protocol to send a close_notify alert.
 TLS implementations must initiate an exchange of closure alerts before closing a
connection. A TLS implementation may, after sending a closure alert, close the connection
without waiting for the peer to send its closure alert, generating an “incomplete close”.
 HTTP clients also must be able to cope with a situation in which the underlying TCP
connection is terminated without a prior close_notify alert and without a Connection:
close indicator.
 4.Secure Shell (SSH)
• Secure Shell (SSH) is a protocol for secure network communications designed to
be relatively simple and inexpensive to implement.
• The initial version, SSH1 was focused on providing a secure remote logon facility to
replace TELNET and other remote logon schemes that provided no security.
• SSH also provides a more general client/server capability and can be used for such
network functions as file transfer and e-mail.
• A new version, SSH2, fixes a number of security flaws in the original scheme.
• SSH client and server applications are widely available for most operating systems.
It has become the method of choice for remote login and X tunneling and is rapidly
becoming one of the most pervasive applications for encryption technology outside
of embedded systems.
• SSH is organized as three protocols that typically run on top of TCP (Figure 16.8):
4.Secure Shell (SSH)
4.Secure Shell (SSH)
1. Transport Layer Protocol: Provides server authentication, data
confidentiality, and data integrity with forward secrecy (i.e., if a key
is compromised during one session, the knowledge does not affect
the security of earlier sessions).The transport layer may optionally
provide compression.
2.User Authentication Protocol: Authenticates the user to the server.
3.Connection Protocol: Multiplexes multiple logical communications
channels over a single, underlying SSH connection.
 4.Secure Shell (SSH):Transport
Layer Protocol
HOST KEYS:
• Server authentication occurs at the transport layer, based on the server possessing a
public/private key pair.
• A server may have multiple host keys using multiple different asymmetric encryption
algorithms. Multiple hosts may share the same host key. In any case, the server host
key is used during key exchange to authenticate the identity of the host.
• For this to be possible:
1. The client must have a priori knowledge of the server’s public host key. So The client
has a local database that associates each host name with the corresponding public host
key. This requires no centrally administered infrastructure and no third-party
coordination. The downside is that the database of name-to-key associations may
become burdensome to maintain.
2. The host name-to-key association is certified by a trusted certification authority (CA).
The client only knows the CA root key and can verify the validity of all host keys certified
by accepted CAs. This alternative eases the maintenance problem
 4.Secure Shell (SSH):Transport
Layer Protocol
PACKET EXCHANGE :
• Figure 16.9 illustrates the sequence of events in the SSH Transport Layer Protocol.
• First, the client establishes a TCP connection to the server. This is done via the TCP protocol and
is not part of the Transport Layer Protocol.
• Once the connection is established, the client and server exchange data, referred to as packets,
in the data field of a TCP segment. Each packet is in the following format (Figure 16.10).
• Packet length: Length of the packet in bytes, not including the packet length and MAC fields. •
Padding length: Length of the random padding field.
• Payload: Useful contents of the packet. Prior to algorithm negotiation, this field is
uncompressed. If compression is negotiated, then in subsequent packets, this field is compressed.
• Random padding: Once an encryption algorithm has been negotiated, this field is added. It
contains random bytes of padding so that that total length of the packet (excluding the MAC field)
is a multiple of the cipher block size, or 8 bytes for a stream cipher.
• Message authentication code (MAC): If message authentication has been negotiated, this field
contains the MAC value.
4.Secure Shell (SSH):
Transport Layer
Protocol
4.Secure Shell (SSH)
Transport Layer
Protocol
4.Secure Shell (SSH)
Transport Layer
Protocol
4.Secure Shell (SSH):User
Authentication Protocol
The User Authentication Protocol provides the means by which the client is authenticated to the server
Three types of messages are always used in the User Authentication Protocol. Authentication requests
from the client have user name is the authorization identity the client is claiming, service name is the
facility to which the client is requesting access (typically the SSH Connection Protocol), and method
name is the authentication method being used in this request. The first byte has decimal value 50, which
is interpreted as SSH_MSG_USERAUTH_REQUEST. If the server either (1) rejects the authentication
request or (2) accepts the request but requires one or more additional authentication methods, the
server sends a message with the name-list is a list of methods that may productively continue the dialog.
If the server accepts authentication, it sends a single byte message: SSH_MSG_ USERAUTH_SUCCESS

• AUTHENTICATION METHODS: The server may require one or more of the following authentication
methods :publickey,password,hostbased: Authentication is performed on the client’s host rather than
the client itself

• MESSAGE EXCHANGES:The message exchange involves the following steps

4.Secure Shell (SSH):User
Authentication Protocol
4.Secure Shell (SSH):
:Connection
Protocol
4.Secure Shell (SSH):Connection
Protocol
• PORT FORWARDING One of the most useful features of SSH is port forwarding. In
essence, port forwarding provides the ability to convert any insecure TCP
connection into a secure SSH connection. This is also referred to as SSH tunneling.
• Figure 16.12 illustrates the basic concept behind port forwarding. We have a client
application that is identified by port number and a server application identified by
port number .
• At some point, the client application invokes the local TCP entity and requests a
connection to the remote server on port .The local TCP entity negotiates a TCP
connection with the remote TCP entity, such that the connection links local port to
remote port .
• To secure this connection, SSH is configured so that the SSH Transport Layer
Protocol establishes a TCP connection between the SSH client and server entities
with TCP port numbers and , respectively.
4.Secure Shell (SSH):
Connection
Protocol
4.Secure Shell (SSH):Connection
Protocol
• SSH supports two types of port forwarding: local forwarding and remote forwarding.
• Local forwarding allows the client to set up a “hijacker” process. This will intercept
selected application-level traffic and redirect it from an unsecured TCP connection to a
secure SSH tunnel. SSH is configured to listen on selected ports. SSH grabs all traffic using
a selected port and sends it through an SSH tunnel. On the other end, the SSH server
sends the incoming traffic to the destination port dictated by the client application.
• With remote forwarding, the user’s SSH client acts on the server’s behalf. The client
receives traffic with a given destination port number, places the traffic on the correct
port and sends it to the destination the user chooses. A typical example of remote
forwarding is the following. You wish to access a server at work from your home
computer. Because the work server is behind a firewall, it will not accept an SSH request
from your home computer. However, from work you can set up an SSH tunnel using
remote forwarding