security in transport layer ssl

17.1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Chapter 17
Security at the
Transport Layer:
SSL and TLS

17.2
Objectives
❏ To discuss the need for security services at the
transport layer of the Internet model
❏ To discuss the general architecture of SSL
❏ To discuss the general architecture of TLS
❏ To compare and contrast SSL and TLS
Chapter 17

17.3
Figure 17.1 Location of SSL and TLS in the Internet model
17 Continued

17.4
17-1 SSL ARCHITECTURE17-1 SSL ARCHITECTURE
SSL is designed to provide security and compressionSSL is designed to provide security and compression
services to data generated from the application layer.services to data generated from the application layer.
17.1.1 Services
17.1.2 Key Exchange Algorithms
17.1.3 Encryption/Decryption Alogrithms
17.1.4 Hash Algorithms
17.1.5 Cipher Suite
17.1.6 Compression Algorithms
17.1.7 Crypography Parameter Generation
17.1.8 Session and Connections
Topics discussed in this section:Topics discussed in this section:

17.5
17.1.1 Services
Fragmentation
Compression
Message Integrity
Confidentiality
Framing

17.6
17.1.2 Key Exchange Algorithms
Figure 17.2 Key-exchange methods

17.7
Null
17.1.2 Continued
There is no key exchange in this method. No pre-There is no key exchange in this method. No pre-
master secret is established between the client and themaster secret is established between the client and the
server.server.
Both client and server need to know the
value of the pre-master secret.
Note

17.8
RSA
17.1.2 Continued
Figure 17.3 RSA key exchange; server public key

17.9
Anonymous Diffie-Hellman
17.1.2 Continued
Figure 17.4 Anonymous Diffie-Hellman key exchange

17.10
Ephemeral Diffie-Hellman key exchange
17.1.2 Continued
Figure 17.5 Ephemeral Diffie-Hellman key exchange

17.11
Fixed Diffie-Hellman
17.1.2 Continued
Another solution is the fixed Diffie-Hellman method.Another solution is the fixed Diffie-Hellman method.
All entities in a group can prepare fixed Diffie-All entities in a group can prepare fixed Diffie-
Hellman parameters (g and p).Hellman parameters (g and p).
Fortezza
Fortezza is a registered trademark of the U.S. NationalFortezza is a registered trademark of the U.S. National
Security Agency (NSA). It is a family of securitySecurity Agency (NSA). It is a family of security
protocols developed for the Defense Department.protocols developed for the Defense Department.

17.12
Figure 17.6 Encryption/decryption algorithms
17.1.3 Encryption/Decryption Algorithms

17.13
17.1.3 Continued
The NULL category simply defines the lack of anThe NULL category simply defines the lack of an
encryption/decryption algorithm.encryption/decryption algorithm.
NULL
Two RC algorithms are defined in stream mode.Two RC algorithms are defined in stream mode.
One RC algorithm is defined in block mode.One RC algorithm is defined in block mode.
All DES algorithms are defined in block mode.All DES algorithms are defined in block mode.
Stream RC
Block RC
DES

17.14
17.1.3 Continued
The IDEA algorithm defined in block mode isThe IDEA algorithm defined in block mode is
IDEA_CBC, with a 128-bit key.IDEA_CBC, with a 128-bit key.
The one Fortezza algorithm defined in block mode isThe one Fortezza algorithm defined in block mode is
FORTEZZA_CBC.FORTEZZA_CBC.
IDEA
Fortezza

17.15
Figure 17.7 Hash algorithms for message integrity
17.1.4 Hash Algorithm

17.16
17.1.4 Continued
The two parties may decline to use an algorithm. InThe two parties may decline to use an algorithm. In
this case, there is no hash function and the message isthis case, there is no hash function and the message is
not authenticated.not authenticated.
NULL
The two parties may choose MD5 as the hashThe two parties may choose MD5 as the hash
algorithm. In this case, a 128-key MD5 hashalgorithm. In this case, a 128-key MD5 hash
algorithm is used.algorithm is used.
The two parties may choose SHA as the hashThe two parties may choose SHA as the hash
algorithm. In this case, a 160-bit SHA-1 hashalgorithm. In this case, a 160-bit SHA-1 hash
algorithm is used.algorithm is used.
MD5
SHA-1

17.17
17.1.5 Cipher Suite
The combination of key exchange, hash, andThe combination of key exchange, hash, and
encryption algorithms defines a cipher suite for eachencryption algorithms defines a cipher suite for each
SSL session.SSL session.

17.18
17.1.5 Continued
Table 17.1 SSL cipher suite list

17.19
17.1.6 Compression Algorithms
Compression is optional in SSLv3. No specificCompression is optional in SSLv3. No specific
compression algorithm is defined for SSLv3.compression algorithm is defined for SSLv3.
Therefore, the default compression method is NULL.Therefore, the default compression method is NULL.

17.20
17.1.7 Cryptographic Parameter Generation
Figure 17.8 Calculation of master secret from pre-master secret

17.21
Figure 17.9 Calculation of key material from master secret
17.1.7 Continued

17.22
Figure 17.10 Extractions of cryptographic secrets from key material
17.1.7 Continued

17.23
17.1.8 Sessions and Connections
In a session, one party has the role of a client
and the other the role of a server;
in a connection, both parties have equal
roles, they are peers.
Note

17.24
17.1.8 Continued
Figure 17.11 A session and connections

17.25
17.1.8 Continued
Session State
Table 17.2 Session state parameters

17.26
17.1.8 Continued
Connection State
Table 17.3 Connection state parameters

17.27
17.1.8 Continued
The client and the server have six different
cryptography secrets: three read secrets
and three write secrets.
The read secrets for the client are the same
as the write secrets for the server and vice
versa.
Note

17.28
17-2 Four Protocols17-2 Four Protocols
We have discussed the idea of SSL without showingWe have discussed the idea of SSL without showing
how SSL accomplishes its tasks. SSL defines fourhow SSL accomplishes its tasks. SSL defines four
protocols in two layers, as shown in Figure 17.12.protocols in two layers, as shown in Figure 17.12.
17.2.1 Handshake Protocol
17.2.2 ChangeCipher Spec Protocol
17.2.3 Alert Protocol
17.2.4 Record Protocol

17.29
Figure 17.12 Four SSL protocols
17.2. Continued

17.30
Figure 17.13 Handshake Protocol

17.31
Figure 17.14 Phase I of Handshake Protocol
17.2.1 Continued

17.32
17.2.1 Continued
After Phase I, the client and server know the
following:
❏ The version of SSL
❏ The algorithms for key exchange, message
authentication, and encryption
❏ The compression method
❏ The two random numbers for key
generation
Note

17.33
Figure 17.15 Phase II of Handshake Protocol
17.2.1 Continued

17.34
17.2.1 Continued
After Phase II,
❏ The server is authenticated to the client.
❏ The client knows the public key of the
server if required.
Note

17.35
Figure 17.16 Four cases in Phase II
17.2.1 Continued

17.36
Figure 17.17 Phase III of Handshake Protocol
17.2.1 Continued

17.37
17.2.1 Continued
After Phase III,
❏ The client is authenticated for the server.
❏ Both the client and the server know the
pre-master secret.
Note

17.38
Figure 17.18 Four cases in Phase III
17.2.1 Continued

17.39
Figure 17.19 Phase IV of Handshake Protocol
17.2.1 Continued

17.40
17.2.1 Continued
After Phase IV, the client and server are
ready to exchange data.
Note

17.41
17.2.2 ChangeCipherSpec Protocol
Figure 17.20 Movement of parameters from pending
state to active state

17.42
Table 17.4 Alerts defined for SSL

17.43
17.2.4 Record Protocol
Figure 17.21 Processing done by the Record Protocol

17.44
Figure 17.22 Calculation of MAC
17.2.4 Continued

17.45
17-3 SSL MESSAGE FORMATS17-3 SSL MESSAGE FORMATS
As we have discussed, messages from three protocolsAs we have discussed, messages from three protocols
and data from the application layer are encapsulatedand data from the application layer are encapsulated
in the Record Protocol messages.in the Record Protocol messages.
17.3.4 Application Data

17.46
Figure 17.23 Record Protocol general header
17.3 Continued

17.47
Figure 17.24 ChangeCipherSpec message

17.48
Figure 17.25 Alert message

17.49
Figure 17.26 Generic header for Handshake Protocol

17.50
17.3.3 Continued
Table 17.5 Types of Handshake messages

17.51
Figure 17.27 Virtual tributary types
17.3.3 Continued

17.52
Figure 17.28 ClientHello message
17.3.3 Continued

17.53
Figure 17.29 ServerHello message
17.3.3 Continued

17.54
Figure 17.30 Certificate message
17.3.3 Continued

17.55
Figure 17.31 ServerKeyExchange message
17.3.3 Continued

17.56
Figure 17.32 CertificateRequest message
17.3.3 Continued

17.57
Figure 17.33 ServerHelloDone message
17.3.3 Continued

17.58
Figure 17.34 CertificateVerify message
17.3.3 Continued

17.59
Figure 17.35 Hash calculation for CertificateVerify message
17.3.3 Continued

17.60
Figure 17.36 ClientKeyExchange message
17.3.3 Continued

17.61
Figure 17.37 Finished message
17.3.3 Continued

17.62
Figure 17.38 Hash calculation for Finished message
17.3.3 Continued

17.63
17.3.3 Application Data
Figure 17.39 Record Protocol message for application data

security in transport layer ssl

More Related Content

What's hot (20)

Similar to security in transport layer ssl (20)

Recently uploaded (20)

security in transport layer ssl