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
# Once the Web server is subverted, 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.

2/28
Types of Security Threats on the Web

3/28
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.

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.

Issues of server and browser security fall into the category of computer system
security;
the issue of system security is also applicable to Web system security. Issues of
traffic security fall into the category of
network security.
 TCP/IP Protocol Stack

There are various Web security approaches that have been considered are similar in the services they provide
and, to some extent, in the mechanisms that they use, but they differ with respect to their scope of
applicability and their relative location within the TCP/IP protocol stack.

Locations of Security Approaches in TCP/IP Protocol Stack

relatively general-purpose solution is to implement security above TCP, Application-specific security
e.x is SSL and TLS. At this level, there are two implementation choices. services are embedded within
The advantage of using IPsec is that it is transparent For full generality, SSL (or TLS) could be provided as part of the the particular application.The
to end users and applications and provides a underlying protocol suite and therefore be transparent to applications. advantage of this approach is
general-purpose solution. Alternatively, TLS can be embedded in specific packages, (most Web that the service can be tailored
servers have implemented the protocol.) to the specific needs of a given
IPsec includes a filtering capability so that only application.
selected traffic need incur the overhead of IPsec
processing.

5/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.

6/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.
7/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.
8/28
 Calculation of Maser Key from
Pre-master Secret

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

9/28
 Calculation of the Key Materials from
Master Secret

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

10/28
Extraction of cryptographic secrets
from Key Materials

11/28
Summary of Cryptographic Parameter
Generation

12/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.

13/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).

14/28
 SSL Handshake
Protocol Messages

the initial exchange needed to establish a logical

connection between client and server. The
exchange can be viewed as having the four
phases discussed previously.
15/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.
16/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.
❏ 17/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.
❏

18/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.
❏
19/28
 Handshake Protocol Message Types

Table
Table
Each message has three fields: 17.2 SSL
17.2 TLSHandshake
HandshakeProtocol
ProtocolMessage
MessageTypes
Types
• Type (1 byte): Indicates one of ten messages.
• Length (3 bytes): The length of the message in bytes.
• Content (# 0 bytes): The parameters associated with this message;
20/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).

21/28
ChangeCipherSpec Protocol

22/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.

23/28
Heartbeat & HTTPS Protocols

24/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

25/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
26/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
Normal HTTP behavior, including retained connections, should be followed.

❏ 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

27/28
 Connection Closure
❏ HTTP client or server can indicate the closing of a connection
by including the line Connection: close in an HTTP record
This indicates that the connection will be closed after this record is delivered.

❏ 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
❏ 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”
Note that an implementation that does this may choose to reuse the session. This should only be done when the application
knows (typically through detecting HTTP message boundaries) that it has received all the message data that it cares about.

❏ 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
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. Such a situation could be due to
a programming error on the server or a communication error that causes the TCP connection to drop.

28/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
29/28