Scribd
Upload
32 views

SSL Simple Authent

1. The document summarizes the steps in a simple SSL/TLS handshake where the server is authenticated by its certificate but the client is not. It involves a negotiation phase where cryptographic parameters are agreed upon, followed by the client and server sending ChangeCipherSpec messages to signal encryption is enabled, and Finished messages to verify the handshake. 2. After successful verification of the Finished messages, the handshake is complete and the application protocol is enabled for encrypted and authenticated content exchange.

Uploaded by

PeyoBouBou
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
32 views

SSL Simple Authent

1. The document summarizes the steps in a simple SSL/TLS handshake where the server is authenticated by its certificate but the client is not. It involves a negotiation phase where cryptographic parameters are agreed upon, followed by the client and server sending ChangeCipherSpec messages to signal encryption is enabled, and Finished messages to verify the handshake. 2. After successful verification of the Finished messages, the handshake is complete and the application protocol is enabled for encrypted and authenticated content exchange.

Uploaded by

PeyoBouBou
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

SSL - Handshake - Simple

authentification

A simple connection example, illustrating a handshake where the server is


authenticated by its certificate (but not the client), follows:

1. Negotiation phase:
o A client sends a ClientHello message specifying the highest TLS
protocol version it supports, a random number, a list of suggested
CipherSuites, and suggested compression methods.
o The server responds with a ServerHello message, containing the
chosen protocol version, a random number, CipherSuite, and
compression method from the choices offered by the client. The server
may also send a session id as part of the message to perform a
resumed handshake.
o The server sends its Certificate message (depending on the selected
cipher suite, this may be omitted by the server).[12]
o The server sends a ServerHelloDone message, indicating it is done
with handshake negotiation.
o The client responds with a ClientKeyExchange message, which may
contain a PreMasterSecret, public key, or nothing. (Again, this depends
on the selected cipher.)
o The client and server then use the random numbers and
PreMasterSecret to compute a common secret, called the "master
secret". All other key data for this connection is derived from this master
secret (and the client- and server-generated random values), which is
passed through a carefully designed "pseudorandom function".

2. The client now sends a ChangeCipherSpec record, essentially telling the


server, "Everything I tell you from now on will be authenticated (and encrypted
if encryption parameters were present in the server certificate)." The
ChangeCipherSpec is itself a record-level protocol with content type of 20.
o Finally, the client sends an authenticated and encrypted Finished
message, containing a hash and MAC over the previous handshake
messages.
o The server will attempt to decrypt the client's Finished message, and
verify the hash and MAC. If the decryption or verification fails, the
handshake is considered to have failed and the connection should be
torn down.

3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I


tell you from now on will be authenticated (and encrypted with the server
private key associated to the public key in the server certificate, if encryption
was negotiated)."
o The server sends its authenticated and encrypted Finished message.
o The client performs the same decryption and verification.

4. Application phase: at this point, the "handshake" is complete and the


application protocol is enabled, with content type of 23. Application messages
exchanged between client and server will also be authenticated and optionally
encrypted exactly like in their Finished message.

last update

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy