Chapter 14

Transport Layer Security

A familiar implementation of public-key encryption is Secure Socket Layer (SSL). SSL is used by web browsers and servers for transmission of sensitive information. SSL is a part of an overall protocol known as Transport Layer Security (TLS). SSL and its successor TLS makes use of certificate authorities. When browser requests a secure web page, ‘s’ added onto ‘http’ in URL of the browser which sends out the public key and the certificate by checking whether the certificate comes from a trusted party which is currently valid and has a relationship with the site from where it comes.

14.1 SECURE SOCKET LAYER

SSL version 1.0 was developed by Netscape for securely exchanging document in the Internet. SSL 2.0 was developed later with version 1.0 of Netscape Navigator. SSL 3.0 was released and Netscape has allowed the IETF to take over the development of future versions. Other versions of SSL protocol are changed to TLS, with version numbers beginning at 1.0. Version numbers that are discussed in ­ClientHello and ServerHello messages of SSL are 3.0 and below. For future revisions of version numbers that has to be negotiated with TLS will continue as version 3.1 or higher indicates revision of SSL 3.0.

Large part of the Internet community has chosen SSL as the secure communications protocol. Many applications of SSL are in existence due to its capability of securing any transmission over TCP. In E-commerce or password transactions, Secure HTTP (HTTPS) is used which is a famous application of SSL.

SSL Protocol has to provide privacy, identity authentication and reliability between two communicating applications. Privacy can be provided through encryption. Identity authentication can done with help of identification through certificates and reliability can be establish by dependable maintenance of a secure connection through message integrity checking.

14.1.1 SSL Architecture

The SSL protocol stack has 4 components over the transport layer. They are SSL record protocol, SSL ChangeCipherSpec protocol, SSL alert protocol and SSL handshake protocol. Figure 14.1 shows the SSL architecture. The four protocol layers of SSL comprise communication between the client ­machine and the server.

C14F001.png

Figure 14.1 SSL protocol stack

  1. Record protocol: The record protocol layer formats the alert, ChangeCipherSpec, handshake and application protocol messages. This formatting provides a header for each message and a hash is generated from a Message Authentication Code (MAC) at the end. The fields that ­comprise the five byte header of the record protocol layer are protocol definition (1 byte), ­protocol version (2 byte) and the length (2 byte). The header followed by the protocol messages has to be lesser than 16,384 bytes.
  2. ChangeCipherSpec protocol: This protocol signals a message denotes the starting of secure communications between client and server. The actual ChangeCipherSpec message is only one byte long which uses the Record Layer format and signals the value of ‘1’ to indicate change in communications protocol.
  3. Alert protocol: The connection between two parties can have errors, problems or warnings which are sent by this protocol. This layer is formed with two fields namely the Severity Level and Alert Description. The Severity Level sends messages with a value ‘1’ or ‘2’, depending on the level of concern. Value of ‘1’ in message is a caution or warning suggesting that parties should discontinue their session and reconnect using a new handshake. Message with a value of ‘2’ is a fatal alert which requires that parties should discontinue their session. Specific error is indicated in Alert Description field which caused the Alert Message to be sent from a party. This field is one byte, mapped to one of twelve specific numbers and can take on one of the meaning such as CloseNotify, UnexpectedMessage, BadRecordMAC, DecompressionFailure, HandshakeFailure, NoCertificate, BadCertificate, UnsupportedCertificate, CertificateRevoked, CertificateExpired, CertificateUnknown, IllegalParameter.
  4. Handshake protocol: Secure connection is established by a handshake that passes messages between client and server usually web browser and web application. The messages that compose this handshake are: ClientHello, ServerHello, ServerKeyExchange, ServerHelloDone, ClientKeyExchange, ChangeCipherSpec, Finished.

14.1.2 Working of SSL

SSL provides the security to the messages that are communicated between the client and the server over the Internet. The SSL protocol is integrated into most of the web browsers to access web applications. Therefore, no further configuration is required from the client’s side of the SSL connection. Configuration is relatively simple at the server side. Web server administrator must acquire a digital certificate, which can be got from Certification Authority (CA) such as VeriSign. CA requires the certificates to be renewed after certain period of time, as a procedure for identity verification of the owner of web server.

The working of SSL layer protocol in the web application is explained with the following messages.

  1. ClientHello: The first message is the ClientHello. Client machine can request secure communication session to the server with this message that includes the required options. The options are Version of SSL to be used, CipherSuites supported by the client and CompressionMethods used by the client. Other information that are included in this message are a 32-byte RandomNumber that assists the client in establishing encrypted communications and a SessionID field that is blank. For example, when a client wants to check the E-mail with ‘secure connection’ option this message is generated.
  2. ServerHello: The second message of the SSL handshake is the ServerHello. Server makes choices based on the ClientHello message using this message. Server returns five fields like the ClientHello message. It fills the SessionID making firm decision on version of SSL to be used along with the CompressionMethod and CipherSuite. Date and time stamp are used for four bytes of RandomNumber field, to prevent repetition in random values.
  3. ServerKeyExchange: Decisions for the transmission of data are made by the server. Information about data encryption must be passed between the parties. This information is sent without encryption because no algorithm has been previously agreed upon. The server’s public key is used to encrypt a separate session key to be maintained for the secure communication. Both the client and server will use the same key to encrypt data to be transmitted. To ensure that the communicating parties, who they claim to be, digital certificates are provided as electronic identification. Public key is combined with digital certificates to connect the name of certificate owner with it. Besides, these certificates can have public keys to CAs like RSA Security or VeriSign. It has an expiry date for verification of the link between certificate owner and CA so that person receiving the digital certificate can check it. Only the public key is included in certificate. Private key is not included because it would be compromised and the entire purpose of having the digital certificate would be voided.
  4. ServerHelloDone: Once the Server has completed the ServerKeyExchange message, the client receives a ServerHelloDone message to indicate that the server is through with its messages.
  5. ClientKeyExchange: SSL don’t need key pair of client to establish a SSL session. Hence the ClientKeyExchange message has information about the key which is used by client and server for communication. Hence ‘man in the middle’ attack is mitigated because a masquerader needs the server’s private key for message decryption. The negotiation processes between client and the server is completed by this message.
  6. ChangeCipherSpec: Data transmission from an insecure state to a secure state is signalled by two ChangeCipherSpec messages. The connection side is changed into the agreed-upon secure state based on the ChangeCipherSpec message sent by computer.
  7. Finished: Final messages of SSL handshake ensures three things are verified before the initial handshake is complete. It is done by two messages which signalled it. Key Information, Previous SSL handshake messages content and special value indicating whether the sender is a client or server are the three things in final messages.

User visualizes a lock icon in the corner of browser which indicates a secure protocol has been agreed upon that is in use by the web browser and the E-mail server.

14.1.2.1 Message Authentication

Upon checking message authentication, the communication continues by appending message authentication algorithm to the end of each message. It is performed by using an algorithm which makes use of cryptographic technology for creating digital summary of information. This summary is known as a hash will change upon the information alteration. MD5 and SHA are common hash functions used in SSL communications.

14.1.2.2 Resuming a Disconnected Session

If an Alert message disconnects a sessions before the parties finishing their communication, that ­session can be resumed if the client sends a HelloRequest to the server with the properly encrypted SessionID information. Secure communication can resume only after the validation of SessionID for exchanging ChangeCipherSpec and Finished messages with client machine by the server.

14.1.3 SSL Applications

Practical applications of SSL communications are E-mail and financial transaction communications. For example, a user wishes to check the E-mail without a digital certificate on the Internet. Secure connection exists in the E-mail webpage, which expects the user to feed username and password. The identification of the E-mail server from user’s current workstation is critical. User can check the E-mail from any computer which means that an identifying certificate on their machine is not critical. Hence, SSL do not want a client certificate.

14.1.4 Issues in SSL

SSL gave customers a sense of safety for online stores while using their credit cards online, and guaranteed users of online applications that they were communicating with their intended recipient. SSL protects information that is passed through the Internet channels. It need not protect data held by the server. Hence, legislations are in effect for protecting the data and web servers in addition to secured connections. Man in the middle attack is possible by capturing encrypted information. But incorrect message authentication will alert the main parties of the secure session to disconnect from the current insecure session and re-instantiate a new secure session.

14.2 WIRED TLS

TLS is the successor of SSL protocol in the Internet. TLS provides secure communication over the ­Internet for E-mailing, Internet faxing and other online data transfers. Differences existing between SSL 3.0 and TLS 1.0 are very few. TLS falls on the Application Layer of OSI model. TLS provides security both in wired and wireless mode.

Server and client can authenticate with each other using TLS Handshake Protocol which allows for negotiation of cryptographic algorithm and keys before data is exchanged. Only authentication of server is done to ensure its identity. The authentication of servers requires public key deployment to clients. During communication between a server and client, TLS protocol assures that no third party can eavesdrop or tamper with any message.

When a website is accessed by ‘https’ protocol through a browser, it most likely uses TLS to securely send the data to and from the web server. TLS is based on the SSL specification developed by Netscape for their browser Navigator. Interchangeably using the terms SSL and TLS are common, but cryptography literature denotes collectively as TLS. In the application design, TLS is used for encapsulating application specific protocols such as SMTP, HTTP, FTP, etc. TLS is used along with connection-oriented reliable protocols such as TCP.

The TLS protocol makes client-server application to securely communicate across an untrusted network. It is designed in a way to protect from stealing information by reading the communication and changing the transmitted information. Asymmetric cryptography is used for securely exchanging keys between client and the server. Symmetric cryptography is used only for the actual encryption of secret data that are being transmitted. MAC is used for message integrity.

14.2.1 TLS Architecture

Figure 14.2 shows the TLS architecture. Cryptographic security, platform independence, scalability and relative efficiency are the major objectives of TLS. These are accomplished through implementation of the TLS protocol on the following two levels:

  1. TLS Record protocol: It negotiates private and reliable connection between client and the server. It uses keys to ensure a private connection, which is secured by using hash functions.
  2. TLS Handshake protocol: This allows authenticated communication to proceed between the server and client. It allows the client and server to communicate in same terms. It makes them to agree upon an algorithm and keys before the selected application protocol begins to send data. It uses the same handshake protocol procedure as SSL, which provides authentication of server and optionally the client.
C14F002.png

Figure 14.2 TLS architecture

14.2.2 Working of TLS

Client initiates a session by ‘Hello’. It proposes protocol version and cipher suite. Server selects protocol as well as suite. Client can request for using cached session and server chooses whether to honour the request or not. Server sends certificate having public key parameters information. Client sends encrypted ‘pre-master’ secret to server using the ClientKeyExchange message. Master secret is calculated by using random values sent in both Hello messages.

14.2.3 TLS Applications

The most familiar use of TLS is to secure the online transactions. TLS can also be used for security purpose in servers such as mail, database or directory. Virtual private network uses TLS to encrypt connection between user’s device and the network being accessed.

14.2.4 Issues in TLS

All versions of TLS protocol are vulnerable to man in the middle and denial of service attacks. Other issues of TLS include low bandwidth, datagram connection, limited processing power, memory capacity and cryptography exporting restrictions.

14.3 WIRELESS TRANSPORT LAYER SECURITY

Wireless Transport Layer Security (WTLS) is part of Wireless Application Protocol (WAP) stack. It is a form of TLS with optimizations for message size. It provides efficient encoding by suppressing redundancies with compression techniques. It wants to be packet friendly. Bidirectional stream ignores any notion of packet in working of TLS. It breaks down data into records based on its internal needs. The WTLS makes the TLS like layers aware of the size of individual underlying packets. The WTLS has been superseded with normal TLS.

Open industry established global standard is WAP which empowers mobile users for feasible access and interact with information and services over the Internet. WAP Version 1.1 includes the WTLS specification that defines the Internet security extension to the wireless Internet. The WAP gateway makes use of SSL for securely communicating with a Web server, which ensures privacy, integrity and server authenticity. The WAP gateway takes encrypted messages of SSL from the web for translation, so that transmission over wireless networks is done using the WTLS security protocol. Mobile devices can send their messages to the Web server by converting the WTLS into SSL. WAP gateway has bridge between the WTLS and SSL security protocols. The necessity for translation between SSL and WTLS arises due to low bandwidth transmissions with high latency of the wireless communications.

14.3.1 WTLS Architecture

The WAP defines a set of protocols for each layer. The main purpose of having a layer protocol stack is that the communication with a certain layer is made through well-defined interfaces. Thus, changing something in one layer does not imply changing all other layers. For example, if a new protocol has to be supported as a bearer, only the transport layer has to be changed and it will not affect the other layers. Figure 14.3 depicts the WTLS in WAP architecture.

C14F003.png

Figure 14.3 WTLS in WAP architecture

The WTLS is used in the security layer of WAP. Cryptographic operations such as digital signing, stream cipher encryption, block cipher encryption and public key encryption are supported by the WTLS. The attributes of these operations can be negotiated for each secure transmission. Security algorithms are processed faster by minimizing protocol overhead in the WTLS. It enables more data compression than the traditional SSL approach. These optimizations allow portable devices to ­communicate securely over the Internet. Key refresh mechanism is provided for updating keys in a secure connection without handshaking.

Figure 14.4 shows the WTLS architecture. The WTLS architecture has record protocol that ­supports four protocol clients: the handshake protocol, the alert protocol, the application protocol, and the ChangerCipherSpec protocol. The application protocol is not described, since it is the interface for the upper layers. External applications have direct access to the WTLS layer using the Wireless Markup Language (WML) Script.

C14F004.png

Figure 14.4 The WTLS architecture

  1. WTLS Record Protocol: It accepts raw data from the upper layers to be transmitted which optionally compresses the data and applies a MAC with encryption for transmitting the result. Received data is decrypted, verified and decompressed, then handed to the higher layers. Data integrity and authentication are taken care by this protocol.
  2. The Handshake Protocol: Security related parameters are agreed during the handshake. It includes attributes such as protocol versions, cryptographic algorithms, and shared secret information generation. The WTLS handshake works like SSL which defines an abbreviated handshake where only Hello and Finished messages are sent. In this case, pre-master secret is the shared secret used by both parties.
  3. The Alert Protocol: Alert messages convey the severity of the message with the description namely fatal, critical, and warning. If a fatal alert message is sent, both parties terminate the secure connection. Critical alert message leads to termination of current secure connection. Any of the party may initiate the exchange of closing messages by sending a warning alert. Upon reception of closing message, further data are ignored. The alert messages are also used to handle errors.
  4. The ChangeCipherSpec Protocol: The ChangeCipherSpec is sent either by the client or the server. By means of this message, both parties decide that they start using the negotiated session parameters. When the ChangeCipherSpec message arrives, the sender of the message sets the current write state to the pending state and the receiver also sets the current read state to the pending state. Security parameters have been agreed upon following which ChangeCipherSpec message is sent during the Handshake phase.

14.3.2 Working of the WTLS

Digital certificates are used for creating a secure and confidential communication pipe between two ­entities, typically a mobile phone and a WAP Server by the WTLS. Two parties involving in the ­secured communication are immediately aware of the tampering when data is forged with the aid of WTLS. Figure 14.5 shows the working of the WTLS.

C14F005.png

Figure 14.5 Working of WTLS

14.3.3 WTLS Applications

Users access many transaction-based activities like banking, sale notification, auction notification, wireless ticketing and many other services on their mobile device screen with the aid of WTLS applications. Mobile devices such as mobile phones, pagers, personal digital assistants are overwhelming the interest of users in wireless technologies which is not only for luxuries and conveniences, but also for the sheer magnitude in which they can change the way in which businesses are run.

14.3.4 Issues in the WTLS

The WTLS has security problems that include the chosen plaintext data recovery attack, the datagram truncation attack, the message forgery attack.

The WTLS alert messages are not encrypted. Alert messages are assigned with sequence numbers which can be replaced with an unauthenticated message with same sequence number that are not detected. Hence truncation attack occurs which can allow arbitrary packets to be removed from the data stream. An eavesdropper can determine the change of keys by reading the contents of this record _type field, which is sent unencrypted.

Security from the web or application server to the mobile client may not be guaranteed. The WTLS defines encryption between the mobile client and the WAP gateway only. The endpoint of encrypted WTLS data is the WAP gateway proxy server.

14.4 COMPARISON OF SSL AND TLS

The major differences between SSL and TLS, ranging from protocol version number to the key information generation, are enumerated as follows:

  1. TLS provides an alert message called ‘NoCertificate’ whereas SSL assumes there is no need for a separate message if no certificate exists for the user.
  2. TLS implements standardized MAC operating with any hash function whereas it is explicitly stated by the SSL protocol.
  3. TLS uses the HMAC standard and its Pseudo Random Function (PRF) output to generate the key information whereas SSL uses RSA or Diffie–Hellman output to create it.
  4. CertificateVerify message requires a complex procedure of messages in SSL whereas the verification information is enclosed in the handshake messages for TLS.
Key Terms

Alert protocol

ChangeCipherSpec protocol

ClientHello

ClientKeyExchange

Finished

Handshake protocol

Record protocol

Secure socket layer

ServerHello

ServerHelloDone

ServerKeyExchange

Wired transport layer security

Wireless transport layer security

Summary
  • Using secure communication protocols, the C-I-A (Confidentiality, Integrity, and Availability) Model for information security can be addressed in numerous ways. The main purpose of SSL and TLS protocols is confidentiality of the information that is transmitted over the Internet. ­Message authentication for each message starting from the first handshake ensures the integrity of data transmission. Digital certificate passing through ensures non-repudiation apart from the ­integrity check of message authentication. Securing sensitive communications are achieved by the ­efficient and proven methods of SSL and TLS. Huge information must be secured properly along with secure communications protocols for providing add-on tools for easy implementation of web ­systems by developers.
Review Questions
  1. Explain SSL architecture.
  2. Describe the working of SSL.
  3. Point out the applications of SSL.
  4. What are the issues in SSL?
  5. With the help of a neat diagram, explain wired TLS architecture.
  6. Briefly narrate the working of wired TLS.
  7. Write down the applications of wired TLS and its issues.
  8. Explain wireless TLS architecture.
  9. Describe the working of wireless TLS architecture.
  10. Write a short note on the applications of wireless TLS and its issues.
  11. Compare SSL and TLS.