Chapter 2

Transport Level Security-SSL,TLS

After studying this chapter

students should be able to present:
Course Learning
Outcome: ✔ Web security considerations:
o Present techniques and threats,countermeasures
protocols for ✔ Secure Sockets Layer(SSL)/
Transport Layer Security(TLS)
transport-level
security. ✔ Hypertext Transfer Protocol
Security (HTTPS)

1/28
 Web Security Considerations
❏ World Wide Web (WWW) is fundamentally a client/server
application running over the Internet and TCP/IP intranets
❏ The following characteristics of Web usage suggest the
need for tailored security tools:
❏ Web servers are relatively easy to configure and manage
❏ Web content is increasingly easy to develop
❏ Underlying software is extraordinarily complex
❏ May hide many potential security flaws
❏ Web server can be exploited as a launching pad into the
corporation’s or agency’s entire computer complex
❏ Casual and untrained (in security matters) users are
common clients for Web-based services
❏ Such users are not necessarily aware of the security risks that
exist and do not have the tools or knowledge to take effective
countermeasures

2/28
Types of Security Threats on the Web

3/28
 TCP/IP Protocol Stack

Locations of Security Approaches in TCP/IP Protocol Stack

4/28
 Secure Sockets Layer(SSL)/ Transport
Layer Security(TLS)
❏ SSL/TLS protocols are dominant for providing security at the
transport layer.
❏ TLS is actually an IETF version of SSL.
❏ Protocol goals include server and client authentication, data
confidentiality, and data integrity.
❏ Application-layer client/server programs, such as HTTP can
encapsulate their data in SSL packets (HTTPS).

If the server and client are capable of running SSL (or TLS) programs,
then the client can use https://... instead of http://...

e.g., credit card numbers can be safely transferred via the Internet
for online shoppers.

❏ Location of SSL/TLS in the Internet model.

5/28
 SSL Algorithms
❏ Key Exchange Algorithms (like DH_RSA, DH_RSA, Fortezza…):
client and server need six cryptographic secrets created by pre-
master secret.
❏ Encryption/Decryption Algorithms (like RC4, RC2, DES…): client
and server need to agree to a set of encryption and decryption
algorithms.
❏ Hash Algorithms (MD5 and SHA): several hash algorithms have
been defined to provide message integrity (message
authentication).
❏ Cipher Suite: combination of key exchange, encryption and hash
algorithms defines a cipher suite for each SSL session.

❏ Compression Algorithms: Compression is optional in SSL. No

specific compression algorithm is defined.
6/28
 SSL Cryptographic Parameter Generation
❏ The parameters are generated using the following procedure:
❏ 1. Client and server exchange two random numbers; one is created by the
client and the other by the server.
❏ 2. Client and server exchange one pre-master secret using one of the
predefined key-exchange algorithms.
❏ 3. 48-byte master secret is created from the pre-master secret by
applying two hash functions (SHA-1 and MD5), next slide.
❏ 4. Master secret is used to create variable-length key material by applying
the same set of hash functions and prepending with different constants,
next slide.

repeated until key material of adequate size is created.

the length of the key material block depends on the cipher suite selected
and the size of keys needed for this suite.
❏ 5. Six different secrets are extracted from the key material, next slide.
7/28
Calculation of Maser Key from Pre-
master Secret

“A” PM CR SR “BB” PM CR SR “CCC” PM CR SR

SHA-1 SHA-1 SHA-1

PM hash PM hash PM hash

MD5 MD5 MD5

hash hash hash PM: Pre-master Secret

SR: Server Random Number
Master secret CR: Client Random Number
(48 bytes)

Note: "A", "BB", and "CCC" are simple text added.

8/28
 Calculation of the Key Materials from
Master Secret

Note: "A", "BB", and "CCC" are simple text added.

9/28
Extraction of cryptographic secrets
from Key Materials

10/28
Summary of Cryptographic Parameter
Generation

11/28
 Sessions and Connections
❏ Session is association between client and server.

the two parties have common info such as session identifier,
certificate authenticating each of them (if necessary), compression
method (if needed), cipher suite, master secret.
❏ Connection is established to exchange data between client and server.

two entities exchange random numbers and create, using the master
secret, keys and parameters needed for authentication and privacy.
❏ Session can consist of many connections.
❏ Connection between two parties can be terminated and reestablished
within the same session.
❏ Session can be terminated or suspended and resumed.

12/28
 SSL Protocols
❏ Handshake Protocol provides security parameters for Record.

establishes cipher set, provides keys and parameters.

authenticates server to client and vice versa if needed.
❏ ChangeCipherSpec Protocol used for signaling the readiness of
cryptographic secrets.
❏ Alert Protocol for reporting errors and abnormal conditions.

uses only one message that describes the problem and its level
(warning or fatal).
❏ Record Protocol carries messages from other protocols and data
from application layer and forwards messages as payloads to
transport layer (TCP).

13/28
 SSL Handshake
Protocol Messages

14/28
 Handshake Protocol Action Phases
❏ Phase I: Establishing Security Capabilities


client and the server announce and choose security capabilities.

session ID is established and the cipher suite is chosen.

parties agree upon a particular compression method.

two random numbers are selected, by client and server.


After Phase I, the client and server know the version of SSL,
the cryptographic algorithms, the compression method, and the
two random numbers for key generation.
15/28
 Handshake Protocol Action Phases
❏ Phase II: Server Authentication and Key Exchange


Server sends its certificate: the certificate contains the server’s public
key. The client will use this key to authenticate the server and to
encrypt the premaster secret.

Server Key Exchange: this is an optional step in which the server creates
and sends a temporary key to the client. This key can be used by the
client to encrypt the Client Key Exchange message later in the process

Client Certificate Request: this is an optional step in which the server
request certificates from client.

Server Hello Done: this message indicates that the server is finished and
awaiting a response from the client.


After Phase II, the server is authenticated to the client, and
the client knows the public key of the server if required.
❏ 16/28
 Handshake Protocol Action Phases
❏ Phase III: Client Authentication and Key Exchange

• Client Certificate: sent if the server sent a Client Certificate Request.

It contains the client’s public key.
• Client Key Exchange: The client sends a Client Key Exchange message
after computing the premaster secret using both random values. The
premaster secret is encrypted by the public key from the server’s
certificate before being transmitted to the server. Both parties will
compute the master secret locally and derive the session key from it.
• Certificate Verify: this message is sent only if the client previously sent
a Client Certificate message.

After Phase III, the client is authenticated for server, and both the
client and the server know the pre-master secret.
❏

17/28
 Handshake Protocol Action Phases
❏ Phase IV: Finalizing and Finishing

• Client Change Cipher Spec: this message notifies the server that all
messages that follow the Client Finished message will be encrypted using
the keys and algorithms just negotiated (slides 21-22).
• Server Change Cipher Spec: this message notifies the client that the
server will begin encrypting messages with the keys just negotiated
(slides 21-22).
• Finished: this message is a hash of the entire conversation to provide
further authentication of the client or of the server.

• In Phase IV, the client and server send messages to change cipher
specifications and to finish the Handshake Protocol.
❏
18/28
Handshake Protocol Message Types

Table 17.2
Table 17.2 SSL
TLSHandshake
HandshakeProtocol
ProtocolMessage Types
Message Types

19/28
 ChangeCipherSpec Protocol

❏ SSL mandates that parties cannot use parameters or secrets

until they have sent or received ChangeCipherSpec message.

❏ ChangeCipherSpec message defined in the ChangeCipherSpec

Protocol and exchanged during Handshake Protocol.


Sender and receiver need two states: pending & active.


Pending state, keeps track of the parameters and secrets.


Active state, holds parameters and secrets used by the Record

Protocol to sign/verify or encrypt/decrypt messages.


Each state holds two sets of values: read (inbound) and write

(outbound).
20/28
ChangeCipherSpec Protocol

21/28
 Processing done by the record protocol
❏ The record protocol carries messages from the upper layer (Handshake Protocol,
ChangeCipherSpec Protocol, Alert Protocol, or application layer).
❏ SSL provides several services on data received from the application layer:
• Fragmentation: the data is fragmented into blocks of 214 bytes or less
• Compression: each fragment is optionally compressed using a lossless compression method
negotiated bet client and server
• Message Integrity: uses a keyed-hash function to create a Message Authentication Code
(MAC) which is added to the compressed message using the negotiated hash algorithm.
• Confidentiality: compressed fragment and MAC are encrypted using symmetric-key
cryptography ( negotiated encryption algorithm).
• Framing: a header is added to the encrypted payload.

22/28
Heartbeat & HTTPS Protocols

23/28
 Heartbeat Protocol
❏ Generates a periodic signal by hardware or software to indicate normal
operation or to synchronize other parts of a system
❏ Typically used to monitor the availability of a protocol entity
❏ Defined in 2012 in RFC 6250 (Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) Heartbeat Extentsion)
❏ Runs on top of the TLS Record Protocol
❏ Consists of two messages
❏ heartbeat_request
❏ heartbeat_response
❏ The use of the Heartbeat protocol is established during Phase 1 of the
Handshake protocol
❏ The heartbeat serves two purposes
❏ assures the sender that the recipient is still alive
❏ generates activity across the connection during idle periods, which avoids
closure by a firewall that does not tolerate idle connections

24/28
 HTTPS (HTTP over SSL)
❏ HTTPS refers to the combination of HTTP and SSL to implement
secure communication bet Web browser and Web server
❏ HTTPS capability is built into all modern Web browsers
❏ A user of a Web browser will see URL addresses that begin with
https:// rather than http://
❏ If HTTPS is specified, port 443 is used, which invokes SSL
❏ Documented in RFC 2818, HTTP Over TLS
❏ No fundamental change in using HTTP over either SSL or TLS
and both implementations referred to HTTPS
❏ When HTTPS is used, the following elements of the
communication are encrypted:
❏ URL of requested document
❏ Contents of document
❏ Contents of browser forms
❏ Cookies sent from browser to server and from server to
browser
❏ Contents of HTTP header
25/28
 Connection Initiation
❏ For HTTPS, agent acting as HTTP client and as TLS client

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
❏ There are three levels of awareness of a connection in HTTPS:

At HTTP level, HTTP client requests a connection to HTTP
server by sending a connection request to lower layer

Typically lower layer is TCP, but may be TLS/SSL

At TLS level, a session is established bet TLS client and TLS
server

This session can support one or more connections at any time

TLS request to establish connection begins with the
establishment of TCP connection bet TCP entity on client side
and TCP entity on server side

26/28
 Connection Closure
❏ HTTP client or server can indicate the closing of a connection
by including the line Connection: close in an HTTP record

❏ 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

❏ TLS implementations must initiate an exchange of closure

alerts before closing a connection
❏ 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”

❏ An unannounced TCP closure could be evidence of some sort of

attack so the HTTPS client should issue some sort of security
warning when this occurs

27/28
 Summary
● Web security considerations
○ Web security threats
○ Web traffic security approaches

● Secure sockets layer

○ Location of SSL/TLS in the Internet model
○ SSL Serivices
○ SSL Agorithms
○ Computation of cryptographic secrets
○ Record Protocol
○ Handshake Protocol
○ ChangeCipherSpec Protocol
○ Alert Protocol
○ Heartbeat protocol
● HTTPS
○ HTTP over SSL
○ Connection initiation
○ Connection closure
28/28