secure socket layer
DESCRIPTION
Uploaded from Google DocsTRANSCRIPT
![Page 1: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/1.jpg)
What are SSL and TLS?
• SSL – Secure Socket Layer
• provide a secure transport connection between applications
(e.g., a web server and a browser)
• SSL was developed by Netscape
• SSL version 3.0 has been implemented in many web browsers
(e.g., Netscape Navigator and MS Internet Explorer) and web (e.g., Netscape Navigator and MS Internet Explorer) and web
servers and widely used on the Internet
• SSL v3.0 was specified in an Internet Draft (1996)
• it evolved into TLS specified in RFC 2246
• TLS can be viewed as SSL v3.1
![Page 2: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/2.jpg)
The Secure Socket Layer (SSL) Protocol
� SSL was originally designed to primarily protect HTTP sessions:
• In the early 1990’s there was a similar protocol called S-HTTP
• However, as S-HTTP capable browsers were not free of charge
and SSL version 2.0 was included in browsers of Netscape
Communications, it quickly became predominant
• SSL v.2 contained some flaws and so Microsoft Corporation
developed a competing protocol called Private Communicationdeveloped a competing protocol called Private Communication
Technology (PCT)
• Netscape improved the protocol and SSL v.3 became the de-
facto standard protocol for securing HTTP traffic
• Nevertheless, SSL can be deployed to secure arbitrary
applications that run over TCP
• In 1996 the IETF decided to specify a generic Transport Layer
Security (TLS) protocol that is based on SSL
![Page 3: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/3.jpg)
SSL (Secure Socket Layer)
• transport layer security service
• originally developed by Netscape
• version 3 designed with public input
• subsequently became Internet standard known as TLS
(Transport Layer Security)
• uses TCP to provide a reliable end-to-end service• uses TCP to provide a reliable end-to-end service
• SSL has two layers of protocols
![Page 4: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/4.jpg)
Broad overview
• SSL runs on top of TCP
– Provides an API similar to that of TCP
• Technically, SSL runs in the application layer
– Advantage: does not require changes to TCP
• From the programmer’s point of view, it is in the transport layerlayer
– Same API as for TCP
– Runs only with TCP, not UDP
• Primarily used for HTTP traffic
![Page 5: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/5.jpg)
Location of SSL and TLS in the Internet model
![Page 6: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/6.jpg)
Where SSL Fits
HTTP SMTP POP3
80 25 110
HTTPS SSMTP SPOP3
443 465 995
Secure Sockets Layer
Transport
Network
Link
![Page 7: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/7.jpg)
Services Provided by SSL
• SSL encrypts data so that no one who intercepts is able to readit.
• SSL can assure a client that they are dealing with the realserver they intended to connect to.
• SSL can prevent any unauthorized clients from connecting tothe server.
Services
7
Fragmentation
Compression
Message Integrity
Confidentiality
Framing
Services
![Page 8: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/8.jpg)
SSL architecture
SSL Record Protocol
SSL
Handshake
Protocol
SSL Change
Cipher Spec
Protocol
SSL
Alert
Protocol
applications
(e.g., HTTP)
SSL Record Protocol
TCP
IP
![Page 9: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/9.jpg)
Architecture
HANDLES COMMUNICATION
WITH THE APPLICATION
INITIALIZES SECURE
COMMUNICATION
ERROR HANDLING
• Record Protocol to transfer application and TLS
information
• A session is established using a Handshake Protocol
WITH THE APPLICATION
ProtocolsINITIALIZES COMMUNCATION
BETWEEN CLIENT & SERVER
HANDLES DATA
COMPRESSION
TLS Record Protocol
Handshake
Protocol
Alert
ProtocolChange
Cipher Spec
![Page 10: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/10.jpg)
SSL Components
• SSL Handshake Protocol
– negotiation of security algorithms and parameters
– key exchange
– server authentication and optionally client authentication
• SSL Record Protocol
– fragmentation
– compression– compression
– message authentication and integrity protection
– encryption
• SSL Alert Protocol
– error messages (fatal alerts and warnings)
• SSL Change Cipher Spec Protocol
– a single message that indicates the end of the SSL handshake
![Page 11: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/11.jpg)
Key Exchange Algorithms
• To Exchange an authenticated and confidential message, the client
and server each need six cryptographic secrets (Four keys and two
initialization vector).
• To create these secrets, one pre-master secret must be established
between the two parties.
• SSL defines six key-exchange methods to establish this pre-master secret
![Page 12: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/12.jpg)
Null
• There is no key exchange in this method.
• No pre-master secret is established between the client and
the server.
RSA key Exchange; Server Public key
• In this method, the pre-master secret key is 48byte
random number created by the client encrypted with the
server’s RSA public key and sent to the server.
• The server needs to send its RSA Encryption/Decryption
certificate.
![Page 13: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/13.jpg)
Anonymous Diffie-Hellman Key Exchange
• This is the simplest and most insecure method.
• The premaster secret is established between the client and
server using Diffe-Hellman (DH) protocol.
• The Diffe-Hellman half keys are sent in plaintext.
• It is called Anonymous Diffie-Hellman because neither party
is known to the other.
• The most serious disadvantage of this method is the Man-
in-the-Middle attack.
![Page 14: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/14.jpg)
Ephemeral Diffie-Hellman Key Exchange
• To thwart the Man-in-the-Middle attack, the Ephemeral Diffie-
Hellman key exchange can be used.
• Each part sends a Diffie-Hellman key signed by its private key.
• The receiving needs to verify the signature using public key of
the sender.
• The public key for verification are exchanged using either RSA
or DSS digital signature certificate.
![Page 15: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/15.jpg)
Fixed Diffie-Hellman
• Another solution is the fixed Diffie-Hellman method.
• All entities in a group can prepare fixed Diffie-Hellman
parameters (g and p).
• Then each entity can create a fixed Diffie-Hellman half-key (gx ).
• For additional security, each individual half-key is inserted into
a certificate verified by a Certificate Authority (CA)
Fortezza
• Fortezza is a registered trademark of the U.S. National Security
Agency (NSA).
• It is a family of security protocols developed for the Defense
Department.
![Page 16: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/16.jpg)
Encryption/Decryption Algorithms
• There are several choices for the Encryption/Decryption
Algorithm. These are divided into six group as shown in figure.
• All block protocols use an 8-byte initialization vector(IV) except
for Fortezza which used 20-byte IV.
![Page 17: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/17.jpg)
The NULL category simply defines the lack of an
encryption/decryption algorithm.
NULL
Two RC algorithms are defined in stream mode.
One RC algorithm is defined in block mode.
Stream RC
Block RC
All DES algorithms are defined in block mode.
DES
IDEA
The IDEA algorithm defined in block mode is IDEA_CBC, with a 128-
bit key.Fortezza
The one Fortezza algorithm defined in block mode is
FORTEZZA_CBC.
![Page 18: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/18.jpg)
Hash Algorithms for Message Integrity
NULL
The two parties may decline to use an algorithm. In this case, there isThe two parties may decline to use an algorithm. In this case, there is
no hash function and the message is not authenticated.
MD5
The two parties may choose MD5 as the hash algorithm. In this case, a
128-key MD5 hash algorithm is used.
SHA-1
The two parties may choose SHA as the hash algorithm. In this case, a
160-bit SHA-1 hash algorithm is used.
![Page 19: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/19.jpg)
• The combination of key exchange, hash, and encryption
algorithms defines a cipher suite for each SSL session.
• Each suite starts with the term SSL followed by the key
exchange algorithm.
• The word “WITH” separates the key exchange algorithm from
Cipher Suite
the encryption and hash algorithm.
• DHE-RSA (Ephemeral Diffie-Hellman with RSA digital Signature.
• DH is fixed Diffie-Hellman
• DHE is Ephemeral Diffie-Hellman
• DH-anon is anonymous Diffie-Hellman
![Page 20: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/20.jpg)
SSL Cipher Suite List
![Page 21: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/21.jpg)
Client Hello - Cipher Suites
INITIAL (NULL) CIPHER SUITE
PUBLIC-KEY
ALGORITHM
SYMMETRIC
ALGORITHM
HASH
ALGORITHM
CIPHER SUITE CODES USED
IN SSL MESSAGES
SSL_NULL_WITH_NULL_NULL = { 0, 0 }
SSL_RSA_WITH_NULL_MD5 = { 0, 1 }
SSL_RSA_WITH_NULL_SHA = { 0, 2 }
SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0, 3 }
SSL_RSA_WITH_RC4_128_MD5 = { 0, 4 }
SSL_RSA_WITH_RC4_128_SHA = { 0, 5 }
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0, 6 }
SSL_RSA_WITH_IDEA_CBC_SHA = { 0, 7 }
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0, 8 }
SSL_RSA_WITH_DES_CBC_SHA = { 0, 9 }
SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0, 10 }
![Page 22: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/22.jpg)
Compression Algorithms
Compression is optional in SSLv3. No specific compression algorithm
is defined for SSLv3. Therefore, the default compression method is
NULL.
![Page 23: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/23.jpg)
Cryptographic Parameter Generation
• To achieve message Integrity and Confidentiality, SSL needs
Six cryptographic secrets, Four keys and two Initialization
Vectors.
• The Client needs one key for message authentication (HMAC)
and one key for encryption and one for IV for blockand one key for encryption and one for IV for block
encryption. Server needs the same.
• SSL requires that the keys for one direction be different from
those for other directions. If there is a attack in one direction,
the other direction is not affected.
![Page 24: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/24.jpg)
Cryptographic Parameter Generation
Calculation of master secret from pre-master secret
![Page 25: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/25.jpg)
Calculation of key Material from Master Secret
![Page 26: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/26.jpg)
Extractions of Cryptographic Secrets from Key Material
![Page 27: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/27.jpg)
A Session and Connections
![Page 28: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/28.jpg)
Session State
Session State Parameters
![Page 29: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/29.jpg)
Connection State
Connection state parameters
![Page 30: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/30.jpg)
SSL Architecture
SSL Record Protocol
SSL
Handshake
Protocol
SSL Change
Cipher Spec
Protocol
SSL
Alert
Protocol
applications
(e.g., HTTP)
SSL Record Protocol
TCP
IP
![Page 31: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/31.jpg)
Four SSL protocols
![Page 32: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/32.jpg)
Processing done by the Record Protocol
![Page 33: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/33.jpg)
SSL Record Protocol
![Page 34: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/34.jpg)
Record Header
• Three pieces of information
– Content type
• Application data
• Alert
• Handshake• Handshake
• Change_cipher_spec
– Content length
• Suggests when to start processing
– SSL version
• Redundant check for version agreement
![Page 35: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/35.jpg)
Protocol (cont’d)
• Max. record length 214 – 1
• MAC
– Data
– Headers
– Sequence number – Sequence number
• To prevent replay and reordering attack
• Not included in the record
![Page 36: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/36.jpg)
Calculation of MAC
![Page 37: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/37.jpg)
Alerts defined for SSL
SSL uses the Alert Protocol for reporting errors and abnormal
Condition. It has only one message type Alert Message that describe
The problem and its level (Warning or Fatal). Table 17.4 shows the types
Of Alert Message defined in SSL.
![Page 38: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/38.jpg)
Movement of parameters from pending state to
active state
![Page 39: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/39.jpg)
Movement of parameters from pending state to
Active state
First the client sends a ChangeCipher Spec Message. After the
client sends this message, it moves the write(Outbound) parameters
from pending to active.
After the receiver receives this message, it moves the read (inbound)After the receiver receives this message, it moves the read (inbound)
parameters from the pending to the active state. Now the server can
verity and decrypt the messages.
Finished message sent by the client can be signed and encrypted by
the client and verified and decrypted by the server.
![Page 40: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/40.jpg)
Handshake Protocol
![Page 41: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/41.jpg)
SSL Handshake Protocol – overview
client server
client_hello
server_hello
certificate
server_key_exchange
certificate_request
server_hello_done
Phase 1: Negotiation of the session ID, key exchange
algorithm, MAC algorithm, encryption algorithm, and
exchange of initial random numbers
Phase 2: Server may send its certificate and
key exchange message, and it may request
the client to send a certificate. Server signals
end of hello phase.server_hello_done
certificate
client_key_exchange
certificate_verify
change_cipher_spec
finished
change_cipher_spec
finished
end of hello phase.
Phase 3: Client sends certificate if requested and may
send an explicit certificate verification message.
Client always sends its key exchange message.
Phase 4: Change cipher spec and finish handshake
![Page 42: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/42.jpg)
Phase I of Handshake Protocol
![Page 43: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/43.jpg)
Phase I of Handshake Protocol
Client Hello : The client sends the Client Hello Message. It contains the
following
• The Highest SSL version number the Client Support.
• A 32-byte random number (from Client) that will be used for
Master Secret Generation
• A session ID that defines the session.• A session ID that defines the session.
• A cipher suite that define the list of algorithm that the client
can support.
• A list of compression methods that the client can support.
![Page 44: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/44.jpg)
Phase I of Handshake Protocol
Server Hello : Server responds to the client with a ServerHello message.
It contains the following
• SSL version number. This number us the lower of two version
numbers. The highest supported by the Client and the highest
supported by the Server.
• A 32-byte random number (from Server) that will be used for• A 32-byte random number (from Server) that will be used for
Master Secret Generation
• A session ID that defines the session.
• Selected cipher set from the client list.
• Selected compression methods from the client list.
![Page 45: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/45.jpg)
After Phase I of Handshake Protocol
After Phase I, the Client and Server know the following
• The version of SSL
• The algorithm for key exchange, Message Authentication and
Encryption
• Compression Method• Compression Method
• The two random number for key Generation
![Page 46: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/46.jpg)
Client Hello
– Protocol version
• SSLv3(major=3, minor=0)
• TLS (major=3, minor=1)
– Random Number
• 32 bytes
• First 4 bytes, time of the day in seconds, other 28 • First 4 bytes, time of the day in seconds, other 28
bytes random
• Prevents replay attack
– Session ID
• 32 bytes – indicates the use of previous
cryptographic material
– Compression algorithm
![Page 47: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/47.jpg)
Handshake Phase 1 – Establish Security Capabilities
• Client Hello (a list of client’s preferences)� version: highest SSL version supported by client
� client’s random• also includes a timestamp
• against replay attacks
� session ID• nonzero means client wants to use an existing session state for a
new connection state (abbreviated handshake);• nonzero means client wants to use an existing session state for a
new connection state (abbreviated handshake);
• zero means new connection on a new session
� compression methods supported by client
� Cipher Suite• a list that contains the combination of crypto algorithms supported
by the client in the order of preference
• each entry is a key exchange algorithm and a cipher spec
![Page 48: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/48.jpg)
Handshake Phase 1 – Establish Security Capabilities
• Server Hello (response to client’s requests)
� version: version proposed by client if also supported by server;otherwise highest supported by server
� server’s random
� same structure as client’s, but independent of client’s random� same structure as client’s, but independent of client’s random
� session ID
� if client offered one and it is also supported by server, then the same ID (abbreviated handshake)
� otherwise a new ID assigned by server
� compression methods chosen from the client’s list
� Cipher Suite selected from the client’s list
![Page 49: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/49.jpg)
After Phase I of Handshake Protocol
After Phase I, the Client and Server know the following
• The version of SSL
• The algorithm for key exchange, Message Authentication and
Encryption
• Compression Method• Compression Method
• The two random number for key Generation
![Page 50: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/50.jpg)
Handshake Protocol
• The most complex part of SSL
• Allows server and client:
– to authenticate each other
– to negotiate encryption and MAC algorithms
– to create cryptographic keys to be used
– in general, to establish a session and then a connection
• handshake is done before any data is transmitted
– so cannot assume a secure record protocol
![Page 51: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/51.jpg)
Handshake Protocol
• a series of messages in 4 phases
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
• Handshake message format
≥≥≥≥
• Handshake message format
• Message types
![Page 52: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/52.jpg)
Handshake
Protocol
![Page 53: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/53.jpg)
Handshake Phase 2: Server Auth. and Key Exchange
• Certificate is needed except for anon-DH (anon-DH is not usedmost of the time)
• Certificate is the basis for server authentication
• if fixed DH, then certificate contains enough information forkey exchange (so server key exchange message is notneeded)
![Page 54: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/54.jpg)
Phase II of Handshake Protocol
In Phase-II, the server authenticates itself if needed.
• Sender may send its certificate, its public key and may also request
certificates from the client.
• At the end server announced that the server hello process is done.
![Page 55: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/55.jpg)
Handshake Phase 2: Server Auth. and Key Exchange
Certificate :
• If it is required, the server sends a Certificate message to
authenticate itself.
• The message includes a list of certificates of type X.509.
• The certificate is not needed if the key-exchange algorithm is
anonymous Diffie-Hellman.
ServerKeyExchange:
• After the Certificate message, the server sends a
ServeKeyExchange message that includes its contribution to the
pre-master secret.
• If this message is not required if the key-exchange method is RSA
or fixed Diffie-Helman.
![Page 56: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/56.jpg)
Handshake Phase 2: Server Auth. and Key Exchange
Certificate Request:
• Server may require the client to authenticate itself.
• In this case, the server sends a CertificateRequest message in
PhaseII that asks for certification in Phase III from the client.
• The server cannot request a certificate from the client if it is
anonymous Diffie-Hellman.
ServerKeyExchange:
• The last message in Phase-II is the ServerHellDone message
which is a signal to the client that Phase-II is over and that the
client needs to start Phase III.
![Page 57: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/57.jpg)
Four cases in Phase II
![Page 58: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/58.jpg)
Handshake Phase 2: Server Auth. and Key
Exchange
• Server Key Exchange
– not needed for
• fixed DH and RSA key exchange
– message content depends on the key exchange method agreed
• Anon-DH• Anon-DH
– message contains public DH parameters and server’s
DH public key
• Ephemeral DH
– same as anon-DH plus a signature on them
– Signatures contain random values (that are exchanged in hello
phase) to resist against replay attacks
![Page 59: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/59.jpg)
Handshake Phase 2: Server Auth. and Key
Exchange
• Server Key Exchange
– not needed for
• fixed DH and RSA key exchange
– message content depends on the key exchange method agreed
• Anon-DH• Anon-DH
– message contains public DH parameters and server’s
DH public key
• Ephemeral DH
– same as anon-DH plus a signature on them
– Signatures contain random values (that are exchanged in hello
phase) to resist against replay attacks
![Page 60: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/60.jpg)
Handshake Phase 2: Server Auth. and Key
Exchange
• Certificate Request Message
– although not common in practice, server may request client to send its certificate
• to authenticate the client
– two fields: certificate type and acceptable CAs
• a list of them
– Certificate types
• fixed DH (certificate may be signed with RSA or DSS)
• ephemeral DH (certificate may contain RSA or DSS key)
• signature only (not used for key exchange but for auth.)
– Certificate may contain RSA or DSS key
• Server Hello Done message
– server is finished and will wait for client’s response
![Page 61: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/61.jpg)
Handshake Phase 3: Client Auth. and Key
Exchange
• Upon receipt of server hello done
– client checks the server certificate and server hello parameters
– after that client starts sending its own messages
• Client’s Certificate
– is sent if requested and available– is sent if requested and available
![Page 62: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/62.jpg)
Phase III of Handshake Protocol
![Page 63: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/63.jpg)
Handshake Phase 3: Client Auth. and Key
Exchange
• Client Key exchange message
– content depends on the key exchange method agreed
– RSA
• 48-byte pre-master secret is encrypted using server’s RSA key (obtained at phase 2)
– fixed-DH– fixed-DH
• client DH parameters are in client certificate, so key exchange message is null
– Anon or ephemeral DH
• Client DH parameters and DH public key are sent
• no signature even for ephemeral DH
– no client authentication and authenticated key exchange so far(only key exchange)
![Page 64: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/64.jpg)
Four cases in Phase III
17.64
![Page 65: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/65.jpg)
Handshake Phase 3: Client Auth. and Key
Exchange
• Certificate Verify message
– in client key exchange message, the client is not authenticated
• anyone could send the key exchange message
– a method for authentication is the certificate verify message
• client shows ownership of private key that corresponds to• client shows ownership of private key that corresponds tothe public key in client certificate by signing a hash thatcontains the master secret and handshake messages
• except for fixed DH that does not contain a signature key
– what about authentication for fixed DH case?
• no real authentication but the attacker cannot produce thepre-master and master secrets since it does not know the DHprivate key (so there is a kind of an implied auth.)
![Page 66: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/66.jpg)
Handshake Phase 4: Finish
� At the end of Phase 3, both client and server can calculate keys
• Phase 4 is wrap-up phase
• Change cipher spec messages
– to make the pending cipher spec the current one
![Page 67: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/67.jpg)
Phase IV of Handshake Protocol
![Page 68: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/68.jpg)
Handshake Phase 4: Finish
ChangeCipherSpec : The client sends a ChangeCipherSpec
message to show that it has moved all
of the cipher suite set and the
parameters from pending state to the
active state. This message is actually
part of the ChangeCipherSpec Protocol.
Finished : The next message is also sent by the client. It
is finished message that announces the end of
the handshaking protocol by the client.
![Page 69: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/69.jpg)
Handshake Phase 4: Finish
• Finished message
� a MAC on exchanged handshake messages using the master
secret
� to verify that handshake is successful and both parties have
the same master secretthe same master secret
� client’s finished is verified by server and vice versa
� the connection state of the record protocol that encrypts and
MACs the finished message is the new one
� so this is also verification of all the keys that are recently
created
![Page 70: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/70.jpg)
SSL Overhead
• 2-10 times slower than a TCP session
• Where do we lose time
– Handshake phase
• Client does public-key encryption
• Server does private-key encryption (still public-key • Server does private-key encryption (still public-key
cryptography)
• Usually clients have to wait on servers to finish
– Data Transfer phase
• Symmetric key encryption
![Page 71: Secure Socket Layer](https://reader034.vdocuments.mx/reader034/viewer/2022051512/544f0c44b1af9f066e8b4c40/html5/thumbnails/71.jpg)
SSL Applications
• HTTP – original application
• Secure mail
– Server to client connection
– SMTP/SSL?
• Telnet, ftp ..• Telnet, ftp ..
• Resources: http://www.openssl.org/related/apps.html