Network Security – Transport Layer

Network security entails securing data against attacks while it is in transit on a network. To achieve this goal, many real-time security protocols have been designed. There are popular standards for real-time network security protocols such as S/MIME, SSL/TLS, SSH, and IPsec. As mentioned earlier, these protocols work at different layers of networking model.

In the last chapter, we discussed some popular protocols that are designed to provide application layer security. In this chapter, we will discuss the process of achieving network security at Transport Layer and associated security protocols.

For TCP/IP protocol based network, physical and data link layers are typically implemented in the user terminal and network card hardware. TCP and IP layers are implemented in the operating system. Anything above TCP/IP is implemented as user process.

Need for Transport Layer Security

Let's discuss a typical Internet-based business transaction.

Bob visits Alice’s website for selling goods. In a form on the website, Bob enters the type of good and quantity desired, his address and payment card details. Bob clicks on Submit and waits for delivery of goods with debit of price amount from his account. All this sounds good, but in absence of network security, Bob could be in for a few surprises.

• If transactions did not use confidentiality (encryption), an attacker could obtain his payment card information. The attacker can then make purchases at Bob's expense.
• If no data integrity measure is used, an attacker could modify Bob's order in terms of type or quantity of goods.
• Lastly, if no server authentication is used, a server could display Alice's famous logo but the site could be a malicious site maintained by an attacker, who is masquerading as Alice. After receiving Bob's order, he could take Bob's money and flee. Or he could carry out an identity theft by collecting Bob's name and credit card details.

Transport layer security schemes can address these problems by enhancing TCP/IP based network communication with confidentiality, data integrity, server authentication, and client authentication.

The security at this layer is mostly used to secure HTTP based web transactions on a network. However, it can be employed by any application running over TCP.

Philosophy of TLS Design

Transport Layer Security (TLS) protocols operate above the TCP layer. Design of these protocols use popular Application Program Interfaces (API) to TCP, called “sockets" for interfacing with TCP layer.

Applications are now interfaced to Transport Security Layer instead of TCP directly. Transport Security Layer provides a simple API with sockets, which is similar and analogous to TCP's API.

In the above diagram, although TLS technically resides between application and transport layer, from the common perspective it is a transport protocol that acts as TCP layer enhanced with security services.

TLS is designed to operate over TCP, the reliable layer 4 protocol (not on UDP protocol), to make design of TLS much simpler, because it doesn't have to worry about ‘timing out’ and ‘retransmitting lost data’. The TCP layer continues doing that as usual which serves the need of TLS.

Why TLS is Popular?

The reason for popularity of using a security at Transport Layer is simplicity. Design and deployment of security at this layer does not require any change in TCP/IP protocols that are implemented in an operating system. Only user processes and applications needs to be designed/modified which is less complex.

Secure Socket Layer (SSL)

In this section, we discuss the family of protocols designed for TLS. The family includes SSL versions 2 and 3 and TLS protocol. SSLv2 has been now replaced by SSLv3, so we will focus on SSL v3 and TLS.

Brief History of SSL

In year 1995, Netscape developed SSLv2 and used in Netscape Navigator 1.1. The SSL version1 was never published and used. Later, Microsoft improved upon SSLv2 and introduced another similar protocol named Private Communications Technology (PCT).

Netscape substantially improved SSLv2 on various security issues and deployed SSLv3 in 1999. The Internet Engineering Task Force (IETF) subsequently, introduced a similar TLS (Transport Layer Security) protocol as an open standard. TLS protocol is non-interoperable with SSLv3.

TLS modified the cryptographic algorithms for key expansion and authentication. Also, TLS suggested use of open crypto Diffie-Hellman (DH) and Digital Signature Standard (DSS) in place of patented RSA crypto used in SSL. But due to expiry of RSA patent in 2000, there existed no strong reasons for users to shift away from the widely deployed SSLv3 to TLS.

Salient Features of SSL

The salient features of SSL protocol are as follows −

• SSL provides network connection security through −
  • Confidentiality − Information is exchanged in an encrypted form.
  • Authentication − Communication entities identify each other through the use of digital certificates. Web-server authentication is mandatory whereas client authentication is kept optional.
  • Reliability − Maintains message integrity checks.
• SSL is available for all TCP applications.
• Supported by almost all web browsers.
• Provides ease in doing business with new online entities.
• Developed primarily for Web e-commerce.

Architecture of SSL

SSL is specific to TCP and it does not work with UDP. SSL provides Application Programming Interface (API) to applications. C and Java SSL libraries/classes are readily available.

SSL protocol is designed to interwork between application and transport layer as shown in the following image −

SSL itself is not a single layer protocol as depicted in the image; in fact it is composed of two sub-layers.

• Lower sub-layer comprises of the one component of SSL protocol called as SSL Record Protocol. This component provides integrity and confidentiality services.
• Upper sub-layer comprises of three SSL-related protocol components and an application protocol. Application component provides the information transfer service between client/server interactions. Technically, it can operate on top of SSL layer as well. Three SSL related protocol components are −
  • SSL Handshake Protocol
  • Change Cipher Spec Protocol
  • Alert Protocol.
• These three protocols manage all of SSL message exchanges and are discussed later in this section.

Functions of SSL Protocol Components

The four sub-components of the SSL protocol handle various tasks for secure communication between the client machine and the server.

• Record Protocol
  • The record layer formats the upper layer protocol messages.
  • It fragments the data into manageable blocks (max length 16 KB). It optionally compresses the data.
  • Encrypts the data.
  • Provides a header for each message and a hash (Message Authentication Code (MAC)) at the end.
  • Hands over the formatted blocks to TCP layer for transmission.

• SSL Handshake Protocol
  • It is the most complex part of SSL. It is invoked before any application data is transmitted. It creates SSL sessions between the client and the server.
  • Establishment of session involves Server authentication, Key and algorithm negotiation, Establishing keys and Client authentication (optional).
  • A session is identified by unique set of cryptographic security parameters.
  • Multiple secure TCP connections between a client and a server can share the same session.
  • Handshake protocol actions through four phases. These are discussed in the next section.
• ChangeCipherSpec Protocol
  • Simplest part of SSL protocol. It comprises of a single message exchanged between two communicating entities, the client and the server.
  • As each entity sends the ChangeCipherSpec message, it changes its side of the connection into the secure state as agreed upon.
  • The cipher parameters pending state is copied into the current state.
  • Exchange of this Message indicates all future data exchanges are encrypted and integrity is protected.
• SSL Alert Protocol
  • This protocol is used to report errors – such as unexpected message, bad record MAC, security parameters negotiation failed, etc.
  • It is also used for other purposes – such as notify closure of the TCP connection, notify receipt of bad or unknown certificate, etc.

Establishment of SSL Session

As discussed above, there are four phases of SSL session establishment. These are mainly handled by SSL Handshake protocol.

Phase 1 − Establishing security capabilities.

• This phase comprises of exchange of two messages – Client_hello and Server_hello.

• Client_hello contains of list of cryptographic algorithms supported by the client, in decreasing order of preference.
• Server_hello contains the selected Cipher Specification (CipherSpec) and a new session_id.
• The CipherSpec contains fields like −
  • Cipher Algorithm (DES, 3DES, RC2, and RC4)
  • MAC Algorithm (based on MD5, SHA-1)
  • Public-key algorithm (RSA)
  • Both messages have “nonce” to prevent replay attack.

Phase 2 − Server authentication and key exchange.

• Server sends certificate. Client software comes configured with public keys of various “trusted” organizations (CAs) to check certificate.
• Server sends chosen cipher suite.
• Server may request client certificate. Usually it is not done.
• Server indicates end of Server_hello.

Phase 3 − Client authentication and key exchange.

• Client sends certificate, only if requested by the server.
• It also sends the Pre-master Secret (PMS) encrypted with the server’s public key.
• Client also sends Certificate_verify message if certificate is sent by him to prove he has the private key associated with this certificate. Basically, the client signs a hash of the previous messages.

Phase 4 − Finish.

• Client and server send Change_cipher_spec messages to each other to cause the pending cipher state to be copied into the current state.
• From now on, all data is encrypted and integrity protected.
• Message “Finished” from each end verifies that the key exchange and authentication processes were successful.

All four phases, discussed above, happen within the establishment of TCP session. SSL session establishment starts after TCP SYN/ SYNACK and finishes before TCP Fin.

Resuming a Disconnected Session

• It is possible to resume a disconnected session (through Alertmessage), if the client sends a hello_request to the server with the encrypted session_id information.
• The server then determines if the session_id is valid. If validated, it exchanges ChangeCipherSpec and finished messages with the client and secure communications resume.
• This avoids recalculating of session cipher parameters and saves computing at the server and the client end.

SSL Session Keys

We have seen that during Phase 3 of SSL session establishment, a pre-master secret is sent by the client to the server encrypted using server’s public key. The master secret and various session keys are generated as follows −

• The master secret is generated (via pseudo random number generator) using −
  • The pre-master secret.
  • Two nonces (RA and RB) exchanged in the client_hello and server_hello messages.
• Six secret values are then derived from this master secret as −
  • Secret key used with MAC (for data sent by server)
  • Secret key used with MAC (for data sent by client)
  • Secret key and IV used for encryption (by server)
  • Secret key and IV used for encryption (by client)

TLS Protocol

In order to provide an open Internet standard of SSL, IETF released The Transport Layer Security (TLS) protocol in January 1999. TLS is defined as a proposed Internet Standard in RFC 5246.

Salient Features

• TLS protocol has same objectives as SSL.
• It enables client/server applications to communicate in a secure manner by authenticating, preventing eavesdropping and resisting message modification.
• TLS protocol sits above the reliable connection-oriented transport TCP layer in the networking layers stack.
• The architecture of TLS protocol is similar to SSLv3 protocol. It has two sub protocols: the TLS Record protocol and the TLS Handshake protocol.
• Though SSLv3 and TLS protocol have similar architecture, several changes were made in architecture and functioning particularly for the handshake protocol.

Comparison of TLS and SSL Protocols

There are main eight differences between TLS and SSLv3 protocols. These are as follows −

• Protocol Version − The header of TLS protocol segment carries the version number 3.1 to differentiate between number 3 carried by SSL protocol segment header.
• Message Authentication − TLS employs a keyed-hash message authentication code (H-MAC). Benefit is that H-MAC operates with any hash function, not just MD5 or SHA, as explicitly stated by the SSL protocol.
• Session Key Generation − There are two differences between TLS and SSL protocol for generation of key material.
  • Method of computing pre-master and master secrets is similar. But in TLS protocol, computation of master secret uses the HMAC standard and pseudorandom function (PRF) output instead of ad-hoc MAC.
  • The algorithm for computing session keys and initiation values (IV) is different in TLS than SSL protocol.
• Alert Protocol Message −
  • TLS protocol supports all the messages used by the Alert protocol of SSL, except No certificate alert message being made redundant. The client sends empty certificate in case client authentication is not required.
  • Many additional Alert messages are included in TLS protocol for other error conditions such as record_overflow, decode_error etc.
• Supported Cipher Suites − SSL supports RSA, Diffie-Hellman and Fortezza cipher suites. TLS protocol supports all suits except Fortezza.
• Client Certificate Types − TLS defines certificate types to be requested in a certificate_request message. SSLv3 support all of these. Additionally, SSL support certain other types of certificate such as Fortezza.
• CertificateVerify and Finished Messages −
  • In SSL, complex message procedure is used for the certificate_verify message. With TLS, the verified information is contained in the handshake messages itself thus avoiding this complex procedure.
  • Finished message is computed in different manners in TLS and SSLv3.
• Padding of Data − In SSL protocol, the padding added to user data before encryption is the minimum amount required to make the total data-size equal to a multiple of the cipher’s block length. In TLS, the padding can be any amount that results in data-size that is a multiple of the cipher’s block length, up to a maximum of 255 bytes.

The above differences between TLS and SSLv3 protocols are summarized in the following table.

Secure Browsing - HTTPS

In this section, we will discuss the use of SSL/TLS protocol for performing secure web browsing.

HTTPS Defined

Hyper Text Transfer Protocol (HTTP) protocol is used for web browsing. The function of HTTPS is similar to HTTP. The only difference is that HTTPS provides “secure” web browsing. HTTPS stands for HTTP over SSL. This protocol is used to provide the encrypted and authenticated connection between the client web browser and the website server.

The secure browsing through HTTPS ensures that the following content are encrypted −

• URL of the requested web page.
• Web page contents provided by the server to the user client.
• Contents of forms filled in by user.
• Cookies established in both directions.

Working of HTTPS

HTTPS application protocol typically uses one of two popular transport layer security protocols - SSL or TLS. The process of secure browsing is described in the following points.

• You request a HTTPS connection to a webpage by entering https:// followed by URL in the browser address bar.
• Web browser initiates a connection to the web server. Use of https invokes the use of SSL protocol.
• An application, browser in this case, uses the system port 443 instead of port 80 (used in case of http).
• The SSL protocol goes through a handshake protocol for establishing a secure session as discussed in earlier sections.
• The website initially sends its SSL Digital certificate to your browser. On verification of certificate, the SSL handshake progresses to exchange the shared secrets for the session.
• When a trusted SSL Digital Certificate is used by the server, users get to see a padlock icon in the browser address bar. When an Extended Validation Certificate is installed on a website, the address bar turns green.

• Once established, this session consists of many secure connections between the web server and the browser.

Use of HTTPS

• Use of HTTPS provides confidentiality, server authentication and message integrity to the user. It enables safe conduct of e-commerce on the Internet.
• Prevents data from eavesdropping and denies identity theft which are common attacks on HTTP.

Present day web browsers and web servers are equipped with HTTPS support. The use of HTTPS over HTTP, however, requires more computing power at the client and the server end to carry out encryption and SSL handshake.

Secure Shell Protocol (SSH)

The salient features of SSH are as follows −

• SSH is a network protocol that runs on top of the TCP/IP layer. It is designed to replace the TELNET which provided unsecure means of remote logon facility.
• SSH provides a secure client/server communication and can be used for tasks such as file transfer and e-mail.
• SSH2 is a prevalent protocol which provides improved network communication security over earlier version SSH1.

SSH Defined

SSH is organized as three sub-protocols.

• Transport Layer Protocol − This part of SSH protocol provides data confidentiality, server (host) authentication, and data integrity. It may optionally provide data compression as well.
  • Server Authentication − Host keys are asymmetric like public/private keys. A server uses a public key to prove its identity to a client. The client verifies that contacted server is a “known” host from the database it maintains. Once the server is authenticated, session keys are generated.
  • Session Key Establishment − After authentication, the server and the client agree upon cipher to be used. Session keys are generated by both the client and the server. Session keys are generated before user authentication so that usernames and passwords can be sent encrypted. These keys are generally replaced at regular intervals (say, every hour) during the session and are destroyed immediately after use.
  • Data Integrity − SSH uses Message Authentication Code (MAC) algorithms to for data integrity check. It is an improvement over 32 bit CRC used by SSH1.
• User Authentication Protocol − This part of SSH authenticates the user to the server. The server verifies that access is given to intended users only. Many authentication methods are currently used such as, typed passwords, Kerberos, public-key authentication, etc.
• Connection Protocol − This provides multiple logical channels over a single underlying SSH connection.

SSH Services

SSH provides three main services that enable provision of many secure solutions. These services are briefly described as follows −

• Secure Command-Shell (Remote Logon) − It allows the user to edit files, view the contents of directories, and access applications on connected device. Systems administrators can remotely start/view/stop services and processes, create user accounts, and change file/directories permissions and so on. All tasks that are feasible at a machine’s command prompt can now be performed securely from the remote machine using secure remote logon.
• Secure File Transfer − SSH File Transfer Protocol (SFTP) is designed as an extension for SSH-2 for secure file transfer. In essence, it is a separate protocol layered over the Secure Shell protocol to handle file transfers. SFTP encrypts both the username/password and the file data being transferred. It uses the same port as the Secure Shell server, i.e. system port no 22.
• Port Forwarding (Tunneling) − It allows data from unsecured TCP/IP based applications to be secured. After port forwarding has been set up, Secure Shell reroutes traffic from a program (usually a client) and sends it across the encrypted tunnel to the program on the other side (usually a server). Multiple applications can transmit data over a single multiplexed secure channel, eliminating the need to open many ports on a firewall or router.

Benefits & Limitations

The benefits and limitations of employing communication security at transport layer are as follows −

• Benefits
  • Transport Layer Security is transparent to applications.
  • Server is authenticated.
  • Application layer headers are hidden.
  • It is more fine-grained than security mechanisms at layer 3 (IPsec) as it works at the transport connection level.
• Limitations
  • Applicable to TCP-based applications only (not UDP).
  • TCP/IP headers are in clear.
  • Suitable for direct communication between the client and the server. Does not cater for secure applications using chain of servers (e.g. email)
  • SSL does not provide non-repudiation as client authentication is optional.
  • If needed, client authentication needs to be implemented above SSL.

Summary

A large number of web applications have emerged on the Internet in the past decade. Many e-Governance and e-Commerce portal have come online. These applications require that session between the server and the client is secure providing confidentiality, authentication and integrity of sessions.

One way of mitigating a potential attack during a user’s session is to use a secure communication protocol. Two of such communication protocols, Secure Sockets Layer (SSL) and Transport Layer Security (TLS), are discussed in this chapter. Both of these protocol function at Transport layer.

Another transport layer protocol, Secure Shell (SSH), designed to replace the TELNET, provides secure means of remote logon facility. It is capable of providing various services such as Secure Command Shell and SFTP.

Employment of Transport layer security has many benefits. However, the security protocol designed at these layer can be used with TCP only. They do not provide security for communication implemented using UDP.