1

Module-3 (Network Layer Security and Web Security)

Internet Protocol Security (IPSec) – Overview, IP security architecture,

Authentication Header (AH), Encapsulating Security Payload (ESP),
Combining Security Associations, Key management. Internet Key
Exchange (IKE) - Phases.

Web Security – Web security considerations. Secure Socket Layer and

Transport Layer Security (SSL/TLS) – SSL Architecture, SSL protocols,
Cryptographic computations, Transport layer security.
IP Security 2

• Purpose of IP Security
• Application specific security measures insufficient
• Organizations have needs of security which cut layers
• IP-level security enhances both application security
already in place, and provides to security to applications
lacking security
• What an IP Security system should provide
• Three functional areas
• Authentication
• Confidentiality
• Key management
• Look at security architecture, then each of the functional areas
IP Security Overview 3

• IP Security: Known as “IPSec”

• IPv6 (successor to IPv4) has authentication and
encryption
• IPSec was designed to be work with both IPv4 and IPv6
• In v6, IPSec’s implementation is mandatory
• For IPv4, it’s still optional
• Benefit is v6 security can be rolled out immediately,
before v6 is mainstream
IPSec Applications 4

•IPSec provides secure communications across a

LAN,across private and public WANs and across the
Internet.
5

5
Benefits of IPSec 6

6
 7

Routing Application

• IPSec used in routing:

• router advertisements are authentic
• neighbor advertisements are authentic
• verification of redirect messages
• routing update is not forged
 8

IP Security Architecture

 IPSec specification consists of numerous documents

 Mandatory in IPv6, optional in IPv4
 Have two security header extensions:
 Authentication Header (AH)
 Encapsulating Security Payload (ESP)

8
9
 10

The documents are divided into seven groups.

•● Architecture: Covers the general concepts, security requirements, definitions, and mechanisms defining
IPSec technology.

•Encapsulating Security Payload (ESP): Covers the packet format and general issues related to the use of
the ESP for packet encryption and, optionally, authentication.

• ● Authentication Header (AH): Covers the packet format and general issues related to the use of AH for
packet authentication.

•● Encryption Algorithm: A set of documents that describe how various encryption algorithms are used for
ESP.

•● Authentication Algorithm: A set of documents that describe how various authentication algorithms are
used for AH and for the authentication option of ESP.

• ● Key Management: Documents that describe key management schemes.

•● Domain of Interpretation (DOI): Contains values needed for the other documents to relate to each other.
These include identifiers for approved encryption and authentication algorithms, as well as operational
parameters such as key lifetime.
 11

IPSec Services
IPSec provides security services at the IP layer by enabling a system to select required
security protocols, determine the algorithm(s) to use for the service(s), and put in place
any cryptographic keys required to provide the requested services.
Two protocols are used to provide security: an authentication protocol designated by
the header of the protocol, Authentication Header (AH); and a combined
encryption/authentication protocol designated by the format of the packet for that
protocol, Encapsulating Security Payload (ESP).

11
 12

IPSec Services
 Access control
 Connectionless integrity
 Data origin authentication
 Rejection of replayed packets
 Confidentiality (encryption)
 Limited traffic flow confidentiality

12
 13

IP Security Policy
 A security policy is applied to each IP packet that
transits from a source to a destination
 IP sec policy is determined primarily by the
interaction of two databases,
 The security association database (SAD)
 The security policy database (SPD)

13
 14

Security Associations
• A key concept that appears in both the authentication and confidentiality
mechanisms for IP is the security association (SA).

• An association is a one-way relationship between a sender and a receiver

that affords security services to the traffic carried on it.

• If a peer relationship is needed, for two-way secure exchange, then two

security associations are required. Security services are afforded to an SA for
the use of AH or ESP, but not both.

• SA uniquely identified by three parameters: Security Parameters Index (SPI),

IP Destination Address, Security Protocol Identifier

14
 15

• ● Security Parameters Index (SPI): A bit string assigned to this SA and having local
significance only. The SPI is carried in AH and ESP headers to enable the receiving
system to select the SA under which a received packet will be processed.
• ● IP Destination Address: Currently, only unicast addresses are allowed; this is the
address of the destination endpoint of the SA, which may be an end user system or a
network system such as a firewall or router.
• ● Security Protocol Identifier: This indicates whether the association is an AH or ESP
security association.
• Hence, in any IP packet, the security association is uniquely identified by the
Destination Address in the IPv4 or IPv6 header and the SPI in the enclosed extension
header (AH or ESP).
 Security AssociationDatabase 16
 In each IPSec implementation, there is a nominal Security Association Database that defines
the parameters associated with each SA. A security association is normally defined by the
following parameters

 Sequence Number Counter

 Sequence Counter Overflow
 Anti-replay window
 AH information
 ESP information
 Lifetime of this SA
 IPSec protocol mode
 Path MTU (Maximum Transmission Unit)

16
17
18
 19

Security PolicyDatabase
 IPSec provides good flexibility in discriminating
between the traffic
 that needs IPSec protection and
 that is allowed to bypass IPSec
 Security Policy Database (SPD) entry called
selectors are used to filter outgoing traffic for a
particular SA

19
 20

Security Policy DatabaseSelectors

The following selectors determine an SPD entry:
 Destination IP Address: This may be a single IP address, an enumerated list or range of addresses, or
a wildcard (mask) address. The latter two are required to support more than one destination system
sharing the same SA (e.g., behind a firewall).
 Source IP Address: This may be a single IP address, an enumerated list or range of addresses, or a
wildcard (mask) address. The latter two are required to support more than one source system
sharing the same SA (e.g., behind a firewall).
 UserID: A user identifier from the operating system. This is not a field in the IP or upper-layer
headers but is available if IPSec is running on the same operating system as the user
 Data Sensitivity Level: Used for systems providing information flow security (e.g., Secret or
Unclassified).
 Transport Layer Protocol: Obtained from the IPv4 Protocol or IPv6 Next Header field. This may be an
individual protocol number, a list of protocol numbers, or a range of protocol numbers.
 Source and Destination Ports: These may be individual TCP or UDP port values, an enumerated list of
ports, or a wildcard port.

20
 21
IPSec ProtocolMode
•Another important concept reused:
• Transport mode: Protection of packet payload
• Tunnel mode: Protection of entire packet
• Transport mode used in end to end communication between
hosts.
• ESP: encrypts (+ authenticate) payload, not header
• AH: Authenticates payload, selected header bits
• Tunnel mode: new routing info added
• ESP: encrypts (+ authenticate) packet(not outer header)
• AH: authenticates entire packet, selected outer bits
22
23
24
Authentication Header (AH) 25
 Provides support for data integrity & authentication of IP
packets
 The data integrity feature ensures that undetected
modification to a packet’s content is not possible in transit.
 The authentication feature enables an end system or
network device to authenticate the user or application and
filter traffic accordingly.
 It also prevents address spoofing attack and replay attack.
 Based on use of a MAC
 HMAC-MD5-96 or HMAC-SHA-1-96
 Parties must share a secret key
 26

Authentication Header
27
Anti-Replay Service 28

 A replay attack is one in which an attacker obtains a copy of an

authenticated packet and later transmits it to the intended
destination.
 The receipt of duplicate ,authenticated IP packets disrupt
service.
 The sequence number is designed to prevent this.
 Sender uses a sequence number starting from 0
 For each packet, seq no is incremented and places on the
Sequence Number field.
 Once the max value is reached, a new SA is
negotiated with new key
29
Integrity Check Value 30

 The Authentication Data field holds a value called Integrity Check Value
 ICV is a MAC
Transport & Tunnel Modes 31
 32
Figure shows two ways in which the IPSec authentication service can be used.

In one case, authentication is provided directly between a server and client workstations;
the workstation can be either on the same network as the server or on an external network.
As long as the workstation and the server share a protected secret key, the authentication
process is secure.
This case uses a transport mode SA.

In the other case, a remote workstation authenticates itself to the corporate firewall, either
for access to the entire internal network or because the requested server does not support
the authentication feature.
This case uses a tunnel mode SA
 33
For transport mode AH using IPv4, the AH is inserted after the original IP header
and before the IP payload (e.g., a TCP segment);

Authentication covers the entire packet, excluding mutable fields in the IPv4 header
that are set to zero for MAC calculation.
 For tunnel mode AH, the entire original IP packet is authenticated, and34the AH is inserted
between the original IP header and a new outer IP header .
The inner IP header carries the ultimate source and destination addresses, while an
outer IP header may contain different IP addresses (e.g., addresses of firewalls or other
security gateways).

With tunnel mode, the entire inner IP packet, including the entire inner IP header is protected
by AH. The outer IP header (and in the case of IPv6, the outer IP extension headers) is
protected except for mutable and unpredictable fields.
 35

Encapsulating Security Payload (ESP)

 Provides message content confidentiality & limited

traffic flow confidentiality
 Can optionally provide the same authentication services
as AH
 Supports range of ciphers, modes, padding
 incl. DES, Triple-DES, RC5, IDEA, CAST etc
 padding needed to fill block size, fields, for traffic flow
 36

Encapsulating Security Payload

 37
● Security Parameters Index (32 bits): Identifies a security association.
● Sequence Number (32 bits): A monotonically increasing counter value; this
provides an antireplay function, as discussed for AH.
● Payload Data (variable): This is a transport-level segment (transport mode) or IP
packet (tunnel mode) that is protected by encryption.
● Padding (0255 bytes): The purpose of this field is discussed later.
● Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this
field.
● Next Header (8 bits): Identifies the type of data contained in the payload data
field by identifying the first header in that payload (for example, an extension
header in IPv6, or an upper-layer protocol such as TCP).
● Authentication Data (variable): A variable-length field (must be an integral
number of 32-bit words) that contains the Integrity Check Value computed over the
ESP packet minus the Authentication Data field.
 38

Encryption and Authentication Algorithms

The Payload Data, Padding, Pad Length, and Next Header fields are
encrypted by the ESP service.

If the algorithm used to encrypt the payload requires cryptographic

synchronization data, such as an initialization vector (IV), then these
data may be carried explicitly at the beginning of the Payload Data
field.

If included, an IV is usually not encrypted, although it is often

referred to as being part of the ciphertext
 39
Padding
The Padding field serves several purposes:
● If an encryption algorithm requires the plaintext to be a multiple of some number
of bytes (e.g., the multiple of a single block for a block cipher), the Padding field is
used to expand the plaintext (consisting of the Payload Data, Padding, Pad Length,
and Next Header fields) to the required length.

● The ESP format requires that the Pad Length and Next Header fields be right
aligned within a 32- bit word. Equivalently, the ciphertext must be an integer multiple
of 32 bits. The Padding field is used to assure this alignment.

● Additional padding may be added to provide partial traffic flow confidentiality by

concealing the actual length of the payload
 Transport vs Tunnel ModeESP 40
 Transport mode is used to encrypt & optionally
authenticate IP data
 data protected but header left in clear
 can do traffic analysis but is efficient
 good for ESP host to host traffic
 Tunnel mode encrypts entire IP packet
 add new header for next hop
 good for VPNs, gateway to gateway security
 Transport Mode ESP 41
• Transport mode ESP is used to encrypt and optionally authenticate the data
carried by IP (e.g., a TCP segment).

• For this mode using IPv4, the ESP header is inserted into the IP packet
immediately prior to the transport-layer header (e.g., TCP, UDP, ICMP) and an ESP
trailer (Padding, Pad Length, and Next Header fields) is placed after the IP packet;
if authentication is selected, the ESP Authentication Data field is added after the
ESP trailer.

• The entire transport-level segment plus the ESP trailer are encrypted.

• Authentication covers all of the ciphertext plus the ESP header.

Transport mode operation may be summarized as follows:
42
1. At the source, the block of data consisting of the ESP trailer plus the entire transport-layer
segment is encrypted and the plaintext of this block is replaced with its ciphertext to form
the IP packet for transmission. Authentication is added if this option is selected.

2. The packet is then routed to the destination. Each intermediate router needs to examine
and process the IP header plus any plaintext IP extension headers but does not need to
examine the ciphertext.

3. The destination node examines and processes the IP header plus any plaintext IP
extension headers. Then, on the basis of the SPI in the ESP header, the destination node
decrypts the remainder of the packet to recover the plaintext transport-layer segment.
Tunnel Mode ESP
43
1. The source prepares an inner IP packet with a destination address of the target
internal host. This packet is prefixed by an ESP header; then the packet and ESP
trailer are encrypted and Authentication Data may be added. The resulting block is
encapsulated with a new IP header (base header plus optional extensions such as
routing and hop-by-hop options for IPv6) whose destination address is the firewall;
this forms the outer IP packet.
2. The outer packet is routed to the destination firewall. Each intermediate router
needs to examine and process the outer IP header plus any outer IP extension
headers but does not need to examine the ciphertext.
3. The destination firewall examines and processes the outer IP header plus any outer
IP extension headers. Then, on the basis of the SPI in the ESP header, the
destination node decrypts the remainder of the packet to recover the plaintext
inner IP packet. This packet is then transmitted in the internal network.
4. The inner packet is routed through zero or more routers in the internal network to
the destination host.
44

29
 Combining SecurityAssociations 45

 An individual SA can implement either the AH or

ESP protocol but not both
 Sometimes both are required, plus transport and
tunnel modes
 For that , multiple Sas must be employed for the
same traffic flow called Security Association
Bundle

45
Combining SecurityAssociations 46

 Security associations may be combined into bundles in

two ways:
 Transport adjacency
 Refers to applying AH and ESP to the same IP packet
without tunneling. This approach to combining AH
and ESP allows for only one level of combination
 Iterated tunneling
 Refers to the application of multiple layers of
security protocols through IP tunneling. This
approach allows for multiple levels of nesting.

46
 47
Combining Security Associations: Authentication
PlusConfidentiality
Encryption and authentication can be combined in
order to transmit an IP packet that has both
confidentiality and authentication between hosts.

Approaches to combine Encryption and authentication

on IP Packets:
 ESP with Authentication option
 Transport Adjacency
 Transport-Tunnel Bundle
47
 ESP with Authenticationoption 48

In this approach, the user first applies ESP to the data to be protected and then
appends the authentication data field. There are actually two subcases:

● Transport mode ESP: Authentication and encryption apply to the IP payload

delivered to the host, but the IP header is not protected.

● Tunnel mode ESP: Authentication applies to the entire IP packet delivered to

the outer IP destination address (e.g., a firewall), and authentication is
performed at that destination. The entire inner IP packet is protected by the
privacy mechanism, for delivery to the inner IP destination.

For both cases, authentication applies to the ciphertext rather than the
plaintext.

48
 Transport Adjacency 49
 Another way to apply authentication after encryption is to use two bundled
transport SAs, with the inner being an ESP SA and the outer being an AH SA.
 In this case ESP is used without its authentication option.
 Because the inner SA is a transport SA, encryption is applied to the IP payload.
 The resulting packet consists of an IP header (and possibly IPv6 header
extensions) followed by an ESP.
 AH is then applied in transport mode, so that authentication covers the ESP plus
the original IP header (and extensions) except for mutable fields.
 The advantage of this approach over simply using a single ESP SA with the ESP
authentication option is that the authentication covers more fields, including the
source and destination IP addresses.
 The disadvantage is the overhead of two SAs versus one SA.
49
Transport-Tunnel Bundle 50

 The use of authentication prior to encryption might be preferable for several

reasons.
 First, because the authentication data are protected by encryption, it is
impossible for anyone to intercept the message and alter the authentication
data without detection.
 Second, it may be desirable to store the authentication information with the
message at the destination for later reference.
 One approach to applying authentication before encryption between two hosts
is to use a bundle consisting of an inner AH transport SA and an outer ESP
tunnel SA.

50
 Basic Combinations of Security Associations
51
In Case 1, all security is provided between end systems that implement IPSec.
For any two end systems to communicate via an SA, they must share the appropriate
secret keys.
Among the possible combinations:
a. AH in transport mode
b. ESP in transport mode
c. ESP followed by AH in transport mode (an ESP SA inside an AH SA)
d. Any one of a, b, or c inside an AH or ESP in tunnel mode

51
 Basic Combinations of Security Associations
52
For Case 2, security is provided only between gateways (routers, firewalls, etc.) and no hosts
implement IPSec. This case illustrates simple virtual private network support. The security
architecture document specifies that only a single tunnel SA is needed for this case. The
tunnel could support AH, ESP, or ESP with the authentication option. Nested tunnels are not
required because the IPSec services apply to the entire inner packet.

52
 Basic Combinations ofSecurity Associations
53
Here Case 3 builds on Case 2 by adding end-to-end security.
The same combinations discussed for cases 1 and 2 are allowed here. The gateway-to-gateway
tunnel provides either authentication or confidentiality or both for all traffic between end
systems. When the gateway-to-gateway tunnel is ESP, it also provides a limited form of traffic
confidentiality. Individual hosts can implement any additional IPSec services required for given
applications or given users by means of end-to-end SAs.

53
 Basic Combinations ofSecurity Associations
54

Case 4 provides support for a remote host that uses the Internet to reach an
organization's firewall and then to gain access to some server or workstation behind
the firewall. Only tunnel mode is required between the remote host and the firewall.
As in Case 1, one or two SAs may be used between the remote host and the local
host.

40
Key Management 55
 The key management portion of IPsec involves the determination and
distribution of secret keys
 The IPsec Architecture document mandates support for two types of key
management:
 Manual
 Automated
 The automated key management protocol for IPsec is referred to as
ISAKMP/Oakley
 It consists of the following elements:
 Oakley Key Determination Protocol
 Internet Security Association and Key Management
Protocol (ISAKMP)

55
 Oakley Key DeterminationProtocol
56

 A key exchange protocol based on the Diffie-Hellman Algorithm

with added security.
 Advantages of Diffie-Hellman
Secret keys are created only when needed
The exchange requires no pre-existing infrastructure
 Weaknesses to Diffie-Hellman
Does not provide information on identities of the
parties
Subject to a man-in-the-middle attack
Computationally intensive: clogging attack
56
 57

Oakley Features

A. It employs cookies to thwart clogging attacks

B. It enables the two parties to negotiate a group; this, specifies
the global parameters of the Diffie-Hellman
C. It uses nonces to ensure against replay attacks.
D. It enables the exchange of Diffie-Hellman public key values.
E. It authenticates the Diffie-Hellman exchange to thwart man-
in-the-middle attacks.

57
 IKE v2 Exchanges 58

 The IKEv2 protocol involves the exchange of

messages in pairs
IKE v2: InitialExchanges

58
 59

IKE v2 Further Exchanges

59
 IKE HeaderFormat 60

IKE PayloadTypes
All IKE payloads begin with the same generic payload header

60
 61
IKE Payload Types

51
 62

Module-3 (Network Layer Security and Web Security)

Internet Protocol Security (IPSec) – Overview, IP security architecture,

Authentication Header (AH), Encapsulating Security Payload (ESP), Combining
Security Associations, Key management. Internet Key Exchange (IKE) - Phases.

Web Security – Web security considerations. Secure Socket Layer and Transport
Layer Security (SSL/TLS) – SSL Architecture, SSL protocols, Cryptographic
computations, Transport layer security.
 63

WEB SECURITY CONSIDERATIONS

• The World Wide Web is fundamentally a client/server application

running over the Internet and TCP/IP intranets
• Web browsers are very easy to use, Web servers are relatively easy to
configure and manage, and Web content is increasingly easy to
develop, the underlying software is extraordinarily complex.
• A 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.
 64
Web Traffic Security Approaches
 65

• A general-purpose solution is to implement security just above

TCP . The foremost example of this approach is the Secure
Sockets Layer (SSL) and the follow-on Internet standard known
as Transport Layer Security (TLS). At this level, there are two
implementation choices. 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.
 66

Secure Socket Layer (SSL)

• One of the most widely used security services

• With the protocol in place, an eavesdropper can only see the
connection end points but cannot read or modify any of the
actual data. Thus, it can protect user's personal data and ensure a
safe transaction.
• A general purpose service implemented as a set of protocols that
rely on TCP
• Could be provided as part of the underlying protocol suite and
therefore be transparent to applications
• Can be embedded in specific packages
 67

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
 68

SSL Protocol Stack

 69

SSL Protocol Stack

• The SSL Record Protocol provides basic security services to various higher
layer protocols.
• 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
• The Alert Protocol.
• These SSL-specific protocols are used in the management of SSL exchanges
 70

Two important SSL concepts

Two important SSL concepts are the SSL session and the SSL
connection, which are defined in the specification as follows:
 Connection: A connection is a transport (in the OSI layering model
definition) 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.
 71

Two important SSL concepts

Between any pair of parties (applications such as

HTTP on client and server), there may be multiple
secure connections.
There are actually a number of states associated
with each session.
 72

Session State Parameters

1. Session identifier: An arbitrary byte sequence chosen by the
server to identify an active or resumable session state
2. Peer certificate: An X509.v3 certificate of the peer; this
element of the state may be null
3. Compression method : The algorithm used to compress data
prior to encryption
4. Cipher spec: Specifies the bulk data encryption algorithm and
a hash algorithm used for MAC calculation; also defines
cryptographic attributes such as the hash_size
5. Master secret: 48-byte secret shared between the client and
the server
6. Is resumable : A flag indicating whether the session can be
used to initiate new connections
 Connection State Parameters 73
1. Server and client random: Byte sequences that are chosen by the server and client for
each connection
2. Server write MAC secret: The secret key used in MAC operations on data sent by the
server
3. Client write MAC secret: The secret key used in MAC operations on data sent by the
client
4. Server write key: The secret encryption key for data encrypted by the server and
decrypted by the client
5. Client write key: The symmetric encryption key for data encrypted by the client and
decrypted by the server
6. Initialization vectors: When a block cipher in CBC mode is used, an initialization vector
(IV) is maintained for each key This field is first initialized by the SSL Handshake
Protocol.The final ciphertext block from each record is preserved for use as the IV with
the following record
7. Sequence numbers: Each party maintains separate sequence numbers for transmitted
and received messages for each connection.When a party sends or receives a change
cipher spec message, the appropriate sequence number is set to zero Sequence
numbers may not exceed 264 - 1
 74

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)
 75

SSL RECORD PROTOCOL

 76

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.
 77

SSL RECORD PROTOCOL

• The first step is fragmentation. Each upper-layer message is fragmented into
blocks of
• 214 bytes (16384 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.
 78

SSL RECORD PROTOCOL

Header Structure
 79

SSL RECORD PROTOCOL

• The final step of SSL Record Protocol processing is to
prepare a header consisting of the following fields:
1. Content Type (8 bits): The higher-layer protocol used to process the
enclosed fragment.
2. Major Version (8 bits): Indicates major version of SSL in use. For SSLv3,
the value is 3.
3. Minor Version (8 bits): Indicates minor version in use. For SSLv3, the
value is 0.
4. Compressed Length (16 bits): The length in bytes of the plaintext
fragment (or compressed fragment if compression is used).
 80

Change Cipher Spec Protocol

• The Change Cipher Spec Protocol is one of the
three SSL-specific protocols that use the SSL
Record Protocol, and it is the simplest.
• This protocol consists of a single message which
consists of a single byte with the value 1.
• The 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
 81
ALERT PROTOCOL
• The Alert Protocol is used to convey SSL-related alerts to the
peer entity.
• Each message in this protocol consists of two bytes
• 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.
 82

ALERT PROTOCOL
 83

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.
• The Handshake Protocol consists of a series of messages exchanged by
client and server.
 84

Handshake Protocol
 Type(1 byte): indicates one of 10 messages (hello_request, client_hello etc)
 Length(3 bytes): The length of message in bytes
 Content(>-1 byte): Parameters related with the message
Handshake Protocol 85
SSL Handshake Protocol Message Types
86
 87
• Phase 1. Establish Security Capabilities.
• This phase is used to 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 understood by the client.
● Random: A client-generated random structure, consisting of a 32-bit timestamp and
28 bytes generated by a secure random number generator. These values serve as
nonces and are used during key exchange to prevent replay attacks.
● Session ID: A variable-length session identifier. A nonzero value indicates that the
client wishes to update the parameters of an existing connection or create a new
connection on this session. A zero value indicates that the client wishes to establish a
new connection on a new session.
 88

● CipherSuite: This is a list that contains the combinations of cryptographic algorithms

supported by the client, in decreasing order of preference. Each element of the list
(each cipher suite) defines both a key exchange algorithm and a CipherSpec.
● Compression Method: This is a list of the compression methods the client supports.

After sending the client_hello message, the client waits for the server_hello message,
which contains the same parameters as the client_hello message. For the server_hello
message, the following conventions apply. The Version field contains the lower of the
version suggested by the client and the highest supported by the server. The Random
field is generated by the server and is independent of the client's Random field. If the
SessionID field of the client was nonzero, the same value is used by the server;
otherwise the server's SessionID field contains the value for a new session. The
CipherSuite field contains the single cipher suite selected by the server from those
proposed by the client. The Compression field contains the compression method
selected by the server from those proposed by the client
 89
• The first element of the Cipher Suite parameter is the key exchange method (i.e., the
means by which the cryptographic keys for conventional encryption and MAC are
exchanged). The following key exchange methods are supported:
• RSA, Fixed Diffie-Hellman:, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman,
Fortezza.

• Following the definition of a key exchange method is the CipherSpec, which includes the
following fields:
• ● CipherAlgorithm: Any of the algorithms mentioned earlier: RC4, RC2, DES, 3DES, DES40, IDEA,
Fortezza
• ● MACAlgorithm: MD5 or SHA-1
• ● CipherType: Stream or Block
• ● IsExportable: True or False
• ● HashSize: 0, 16 (for MD5), or 20 (for SHA-1) bytes
• ● Key Material: A sequence of bytes that contain data used in generating the write keys
• ● IV Size: The size of the Initialization Value for Cipher Block Chaining (CBC) encryption
Phase 2. Server Authentication and Key Exchange 90

• The server begins this phase by sending 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. Note that if fixed Diffie-Hellman is used, this certificate message functions as
the server's key exchange message because it contains the server's public Diffie-Hellman
parameters.
• 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) 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 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.
 91

Phase 3. Client Authentication and Key Exchange

• Upon receipt of the server_done message, the client should verify
that the server provided a valid certificate if required 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 instead.
• 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.
• Finally, in this phase, the client may send a certificate_verify
message to provide explicit verification of a client certificate. This
message is only sent following any client certificate that has signing
capability.
 92

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. Note that this message is not considered part of the
Handshake Protocol but is sent using the Change Cipher Spec Protocol. The
client then immediately sends the finished message under the new
algorithms, keys, and secrets. The finished message verifies that the key
exchange and authentication processes were successful.
• In response to these two messages, the server sends its own
change_cipher_spec message, transfers the pending to the current
CipherSpec, and sends its finished message. At this point the handshake is
complete and the client and server may begin to exchange application layer
data.
 93

Cryptographic Computations
• The creation of a shared master secret by means of the key exchange
• The shared master secret is a one-time 48-byte value generated for this
session by means of secure key exchange
• RSA algorithm and Diffie-Hellman algorithm
• The generation of cryptographic parameters from the master secret
• 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
 TRANSPORT LAYER SECURITY 94
What is Transport Layer Security
(TLS)?
• Transport Layer Security, or TLS, is a widely adopted security protocol
designed to facilitate privacy and data security for communications over
the Internet.
• A primary use case of TLS is encrypting the communication between web
applications and servers, such as web browsers loading a website.
• TLS can also be used to encrypt other A bit more about TLS!
communications such as email, messaging TLS was proposed by the Internet
Engineering Task Force (IETF), an
and voice over IP (VoIP).
international standards organization, and
the first version of the protocol was
published in 1999. The most recent
version is TLS 1.3, which was published in
2018.
 95

What is the difference between TLS and SSL?

• TLS evolved from a previous encryption protocol called
Secure Sockets Layer (SSL), which was developed by
Netscape.
• TLS version 1.0 actually began development as SSL version
3.1, but the name of the protocol was changed before
publication in order to indicate that it was no longer
associated with Netscape.
• Because of this history, the terms TLS and SSL are sometimes
used interchangeably.
 TLS VS SSL
96

• 1. version number
• The TLS Record Format is the same as that of the SSL Record
Format.
• The one difference is in version values. For the current version
of TLS, the Major Version is 3 and the Minor Version is 1
• 2.MAC
• There are two differences between the SSLv3 and TLS MAC
schemes:
• TLS uses HMAC
• SSL uses same .
• But for TLS the MAC covers the version field of the record
header too
 97
• 3. more alert codes
TLS supports all of the alert codes defined in SSLv3 with the exception of
no_certificate.
A number of additional codes are defined in TLS; of these, the following are always
fatal:
• decryption_failed: A ciphertext decrypted in an invalid way; either it was not an
even multiple of the block length or its padding values, when checked, were
incorrect.
• record_overflow: A TLS record was received with a payload (ciphertext) whose
length exceeds max length.
• unknown_ca: A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not be located or could
not be matched with a known, trusted CA.
• access_denied: A valid certificate was received, but when access control was
applied, the sender decided not to proceed with the negotiation.
• decrypt_error: A handshake cryptographic operation failed, including being unable
to verify a signature, decrypt a key exchange, or validate a finished message.
• user_canceled: This handshake is being canceled for some reason unrelated to a
protocol failure
 98
4.cipher suites
• There are several small differences between the cipher suites available under SSLv3 and under TLS:
• ● Key Exchange: TLS supports all of the key exchange techniques of SSLv3 with the exception of
Fortezza.
• ● Symmetric Encryption Algorithms: TLS includes all of the symmetric encryption algorithms found
in SSLv3, with the exception of Fortezza
5.certificate_verify message
• the hash is computed only over the handshake messages
• in SSL the hash contained the master_secret and pads
6. pseudorandom function PRF
TLS makes use of a pseudorandom function referred to as PRF to expand secrets into blocks of data for
purposes of key generation or validation. The objective is to make use of a relatively small shared secret
value but to generate longer blocks of data in a way that is secure from the kinds of attacks made on hash
functions and MACs.
• P_hash(secret, seed) = HMAC_hash( secret, A(1) | seed ) |
HMAC_hash( secret, A(2) | seed ) |
HMAC_hash( secret, A(3) | seed ) | …
where
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
• PRF(secret, label, seed) =
P_MD5(secret_left, label | seed) Å P_SHA(secret_right, label | seed)
7.finished message 99
As with the finished message in SSLv3, the finished message in TLS is a hash based on the shared

master_secret, the previous handshake messages, and a label that identifies client or server. The

calculation is somewhat different. For TLS, we have

PRF( master_secret,
“client finished”,
MD5(handshake_messages) | SHA(handshake_messages) )
where finished_label is the string "client finished" for the client and "server finished" for the server

8.cryptographic computations
pre-master secret is calculated in the same way as in SSL master secret:
PRF( pre_master_secret,
“master secret”,
client_random | server_random )
key block:
PRF( master_secret,
“key expansion”,
server_random | client_random )
 100

9.Padding

• In SSL, the padding added prior to encryption of user data is the minimum amount
required so that the total size of the data to be encrypted is a multiple of the cipher's
block length.
• In TLS, the padding can be any amount that results in a total that is a multiple of the
cipher's block length, up to a maximum of 255 bytes.

***********************************************************************