Full Handshake Process

The Full Handshake Protocol

The handshake protocol is a series of sequenced messages that negotiate the security parameters of a data transfer session.

Client Hello Messages

The Client Hello is typically the first message in the TLS/SSL session setup sequence. The protocol allows the server to request a hello, but this is application-specific and not part of the normal sequence.

Client Hello Messages

Client Hello Message

The client initiates a session by sending a Client Hello message to the server. The Client Hello message contains:

• Version Number. The version number of the highest version that the client supports. This is sent by the client to the server. Version 2 is used for SSL 2.0, version 3 for SSL 3.0, and version 3.1 for TLS. Although the IETF RFC for TLS is TLS version 1.0, the protocol uses 3.1 in the version field to indicate that it is a later version, with more functionality than SSL 3.0.
  
  
• Client Random. A 4-byte number that consists of the client’s date and time, plus a 28-byte cryptographically-generated pseudorandom number. This is used in the calculation of the Master Secret from which the encryption keys are derived.
  
  
• (Optional) Session Identification. A byte string used to identify an active or resumable session state. Enables the client to resume a previous session. Resuming a previous session can be useful, because creating a new session requires processor-intensive public key operations that can be avoided by resuming an existing session with its established session keys. Previous session information, identified by the SessionID, is stored in the respective client and server session caches. This is empty if the client is not resuming a session.
  
  
• Cipher Suite. The list of cipher suites available on the client. An example of a cipher suite is TLS_RSA_WITH_DES_CBC_SHA, where TLS is the protocol version, RSA is the algorithm that will be used for the key exchange, DES_CBC is the encryption algorithm (using a 56-bit key in CBC mode), and SHA-1 is the hash function.
  
  Note
  
  
  • Microsoft applications typically specify RSA as the key exchange algorithm, RC4 as the encryption method, and MD5 as the Message Authentication Codes.
    
    
• Compression Algorithm. The client’s supported compression algorithms. Compression is optional and is one of the four operations that the Record Protocol might perform on all data after the Hello sequence is finished.
  
  

Server Session Cache Allows Session Resume

The Client Hello is used to either start a new session or to resume an existing session. If the Client Hello includes a Session ID, the client is attempting to resume a session.

The server maintains a session cache to allow fast resumption of recent sessions, similar to a ticket cache in Kerberos. Resuming a session does not require certificate exchanges, so it is much quicker than the normal Hello sequence.

The application determines whether client’s are allowed to resume sessions and how long idle session IDs are valid.

The server uses CryptoAPI to manage both the session ID and the certificate cache.

Note

• The Client Hello can be initiated at any time during an existing session and is not limited to just session initialization. The server application might request a new Hello periodically to request client authentication based on the resource that is requested. Either the client application or the server might request a new handshake to refresh encryption keys.
  
  

TLS 1.0 Cipher Suites

Schannel supports the cipher suites in the following table for TLS 1.0. In this table, the following acronyms are used:

CBC = cipher block chaining

DES = Data Encryption Standard

DHE = Ephemeral Diffie-Hellman

DSS = Digital Signature Standard

The suites are listed in order of preference.

TLS 1.0 Cipher Suites

 

Key Exchange	Cipher	Hash
RSA	RC4 128	MD5
RSA	RC4 128	SHA-1
RSA	3DES EDE CBC	SHA-1
DHE DSS	3DES EDE CBC	SHA-1
RSA	DES CBC	SHA-1
DHE DSS	DES CBC	SHA-1
RSA Export 1024	RC4 56	SHA-1
RSA Export 1024	DES CBC	SHA-1
DHE DSS Export 1024	DES CBC	SHA-1
RSA Export	RC4 40	MD5
RSA Export	RC2 CBC 40	MD5
RSA	None	MD5
RSA	None	SHA-1

SSL 3.0 Cipher Suites

Schannel supports the cipher suites listed under TLS 1.0 Cipher Suites.

SSL 2.0 Cipher Suites

Schannel supports the following cipher suites for SSL 2.0. The suites are listed in order from most secure to least secure.

SSL 2.0 Cipher Suites

 

Cipher	Hash
RC4 128	MD5
DES 192 EDE3 CBC	MD5
RC2 CBC 128 CBC	MD5
DES 64 CBC	MD5
RC4 128 Export 40	MD5

Server Responses to Client Hello

Server Responses to Client Hello

Server Hello Message

The server responds with a Server Hello message. The Server Hello message includes:

• Version Number. The server sends the highest version number that is supported by both sides. This is the protocol version that will be used during the connection.
  
  
• Server Random[32]. ServerRandom[32] is a 4-byte representation of the server’s date and time plus a 28-byte, cryptographically-generated, pseudorandom number. This number, along with the Client Random, is used by both the client and the server to generate the Master Secret from which the encryption keys will be derived.
  
  
• Session Identification (if any). This can be one of three choices.
  
  
  • New session ID. The client did not indicate a session to resume, so a new ID is generated. A new session ID is also generated when the client indicates a session to resume, but the server can’t or won’t resume that session.
    
    
  • Resumed Session ID. The ID is the same as indicated in the Client Hello. The client indicated a specific session ID to resume and the server is willing to resume that session.
    
    
  • Null. This is a new session, but the server is not willing to resume it at a later time, so no ID is returned.
    
    
• Cipher Suite. The server chooses the strongest cipher that both the client and server support. If there are no cipher suites that both parties support, the session is ended with ahandshake failure alert.
  
  
• Compression Algorithm. If used, specifies the compression algorithm to use.
  
  

Server Certificate Message

The server sends its certificate to the client. The server certificate contains the server’s public key. The client uses this key to authenticate the server and to encrypt the Premaster Secret. The Server Certificate message includes:

• The server’s certificate list. The first certificate in the list is the server’s X.509v3 certificate that contains the server’s public key.
  
  
• Other validating certificates. All other validating certificates, up to but not including the root certificate from the CA, signed by the CA.
  
  

The client also checks the name of the server in the certificate to verify that it matches the name the client used to connect. For example, if the user types http://www.contoso.com as the URL in the browser, the certificate contains a subject name of www.contoso.com or *.contoso.com. Internet Explorer warns the user if these names do not match; other client applications typically fail the connection directly.

(Optional) Server Key Exchange Message

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. The step is only required when the server’s certificate does not contain a public key that is suitable for key exchange or when the cipher suite mandates the use of an ephemeral key for the key exchange operation. This message is also used when the server uses a DSS certificate. In this case, the server public key is not suitable for key exchange, and so an ephemeral DH key is created by the server and sent in the Server Key Exchange message.

In these situations, the server must create and send a temporary key that is used instead of the server’s public key. The key that is created depends on the cipher suite. With export versions of RSA that do not allow a public key greater than 512 bits, the temporary shorter key is signed with the unusable public key for authenticity.

Why is this important? The client will need this key to encrypt the Premaster Secret, whichis discussed below, in the Client Key Exchange message.

Note

• This message is not used in non-export versions of Microsoft applications, since non-export RSA certificates will always include the server’s public key in its certificate.
  
  

(Optional) Client Certificate Request Message

The server must always present its certificates to the client, but the client is not always required to authenticate itself. Therefore, the client is not always required to send its certificates to the server. If the server does not require client authentication, then this message is not sent.

This step might be used for Web sites such as a banking Web site, where the server must confirm the identity of the client before providing sensitive information. If the application requires mutual authentication, the server sends a Client Certificate Request. The Client Certificate Request message includes:

• The type of certificate required (typically RSA or DSS)
  
  
• A list of acceptable CAs
  
  

Server Hello Done Message

This message indicates that the server is finished and awaiting a response from the client. This message has no content. It signals that the Server Hello sequence is finished.

Client Responses to Server Hello

The client receives the server’s message and checks the certification hierarchy of the server’s certificate.

Client Responses to Server Hello

Client Certificate Message (Required if Requested)

If the server sent a Client Certificate Request, the client sends its certificate to the server for client authentication. The client’s certificate contains the client’s public key. The Client Certificate message includes theclient’scertificate list. The first certificate in the list is the client’s X.509v3 certificate that contains the client’s public key. After that are other validating certificates, up to but not including the root certificate from the CA, signed by the CA.

Client Key Exchange Message

The client sends a Client Key Exchange message after computing the premaster secret using the two random values that are generated during the Client Hello message and the Server Hello message. Before it is transmitted to the server, the premaster secret is encrypted by the public key from the server’s certificate. Both parties compute the master secret locally and derive the session key from it.

If the server can decrypt this data and complete the protocol, the client is assured that the server has the correct private key. This step is crucial to prove the authenticity of the server. Only the server with the private key that matches the public key in the certificate can decrypt this data and continue the protocol negotiation.

The Client Key Exchange message includes:

• Client’s protocol version. The server will verify that it matches the original value sent in the Client Hello message. This measure guards against rollback attacks. Rollback attacks work by manipulating the message in order to cause the server and the client to use a less secure, earlier version of the protocol.
  
  
• Pre-master secret. This is the client-generated number (48-byte for RSA), encrypted with the server’s public key, that is used with the Client Random and the Server Random to create the Master Secret.
  
  

Certificate Verify Message (Required if Client Certificate Is Sent)

This message is sent only if the client previously sent a Client Certificate message. The client is authenticated by using its private key to sign a hash of all the messages up to this point. The server verifies the signature with the public key of the signer, which ensures that it was signed with the client’s private key. This message contains a long signature to verify the client’s certificate, if one was requested and sent.

For RSA, the signature consists of:

• An MD5 hash of all previous handshake messages.
  
  
• An SHA-1 hash of all previous handshake messages.
  
  
• Both hashes, which are concatenated and encrypted with the client’s private key.
  
  

For DSS, the signature consists of:

• An SHA-1 hash of all previous handshake messages.
  
  
• Encrypted with the client’s private key.
  
  

Change Cipher Spec Message

The Change Cipher Spec message notifies the server that all future messages including the Client Finished message are encrypted using the keys and algorithms just negotiated. At this point, client and server are authenticated and the client has sent the pre-master secret. Both the client and the server have calculated the Master Secret. Up until now, however, any encryption has used the client’s or server’s private/public keys. The Change Cipher Spec message tells the server that the client is ready to use the Write Key for all further encryption.

Note

• The Change Cipher Spec message is not part of the Handshake Protocol. The TLS RFC defines a separate protocol for Change Cipher Spec. This allows developers to define a specific Change Cipher Spec message.
  
  

Computing the Master Secret Key and Subsequent Keys

The Handshake sequence securely exchanges data that is used to create the Master Secret. This secret, however, is never used by itself in encryption; rather, several keys are derived from the Master Secret. These keys are then used for message authentication and encryption.

Note

• The details in this section and the next (hashing in the Record Layer) provide a glimpse inside the computational “black box” and are meant to illustrate the complexity that is necessary to secure communications. The key material exchange specifics change over time as new algorithms are developed.
  
  

Computing the Master Secret

The Master Secret results from the pseudorandom material that is exchanged in the Client Hello message and Server Hello message that is discussed earlier in the sections on the Client and Server Final messages. Both the server and the client create the Master Secret key. It is never exchanged.

To create the Master Secret key, the system passes the following as variables to a pseudorandom function (PRF):

• The 48-byte Pre-Master Secret.
  
  
• The literal phrase “master secret”
  
  
• The concatenation of Client Random number and Server Random number.
  
  

The result is the Master Secret.

MAC Secret and Write Encryption Keys

To enable message encryption and hashing, four keys need to be created on both the server and the client:

• Client Write MAC Secret
  
  
• Server Write MAC Secret
  
  
• Client Write Key
  
  
• Server Write Key
  
  

These keys are never exchanged.

To produce these keys, the Master Secret is passed to the PRF until enough output has been generated to yield a value that is divided into six parts. (The last two parts are only generated for non-export block ciphers.)

Client Write MAC Secret

This key is added to client message hashes. The client uses the key to create the initial hash. The server uses it to authenticate client messages.

Server Write MAC Secret

This key is added to server message hashes. The server uses the key to create the initial hash. The client uses it to authenticate server messages.

Client Write Key

The client uses this key to encrypt messages. The server uses the key to decrypt client messages.

Server Write Key

The server uses this key to encrypt messages. The client uses the key to decrypt server messages.

Finished Message

The Finished message is a hash of the entire conversation which provides further authentication of the client. This message is a complicated verification that the client who is sending the Finished message is truly the client who started the Hello conversation. It is the first message that the Record Layer encrypts and hashes with the Write Key and the Write MAC Secret.

Construction of the message at the Handshake Protocol

To generate the message contents, the system passes the following as variables to a pseudorandom function (PRF):

• The Master Secret.
  
  
• The literal phrase “client finished”.
  
  
• The concatenation of an MD5 hash of all previous handshake messages and an SHA-1 hash of all previous handshake messages.
  
  

The Handshake protocol passes the result to the Record Layer.

Completing the message at the Record Layer

The Record Layer hashes the data using HMAC with the Client Write MAC Secret, which is derived from the Master Secret. Then, the Record Layer encrypts the data with the Client Write Key, which is also derived from the Master Secret.

Server Finished Messages

If the server has a copy of the private half of its public key pair, it can decrypt the ClientKeyExchange message and generate a matching set of encryption and MAC keys. The server responds to the client with a request to communicate with secret key cryptography, so that both parties have acknowledged that they will use the cryptography and keys that they have agreed upon.

Server Finished Messages

Change Cipher Spec Message

This message notifies the client that the server will begin encrypting messages with the keys that were just negotiated. The server switches its record layer security state to symmetric encryption using the session keys.

Finished Message

This message is a hash of the entire exchange to this point using the session key and the MAC Secret. If the client can successfully decrypt this message and validate the contained hashes, the client is assured that the TLS/SSL handshake was successful, and the keys computed on the client machine match those computed on the server.

This message is the same as the Client Finished message with these differences:

• The literal phrase “server finished” is used instead of “client finished”.
  
  
• The hashed handshake messages include the client’s Client Finished message.
  
  
• The server uses the Server Write MAC Secret and Server Write Key for hashing and encrypting at the Record Layer.
  
  

Application Data Flow

So far in this process, client and server applications have been authenticated through the use of certificates and public/private keys, a Premaster Secret and other data have been exchanged to create the Master Secret, and both the server and the client have successfully proven that they have not changed identities throughout the Hello sequence. Now the applications can begin to communicate, using the established keys and parameters. The Record Layer fragments, compresses, hashes, and encrypts all further communications. When necessary, it decrypts, verifies, decompresses, and reassembles the communication

Record Protocol

The Record Protocol

When the record protocol receives the data from the application layer, it might perform the following tasks:

• Fragments the data into blocks or reassembles fragmented data into its original structure. Schannel does not support fragmentation at the Record Layer.
  
  
• Numbers the sequence of data blocks in the message to protect against attacks that attempt to reorder data.
  
  
• Compresses or decompresses the data using the compression algorithm negotiated in the handshake protocol. Schannel does not support compression at the Record Layer.
  
  
• Encrypts or decrypts the data using the encryption keys and cryptographic algorithm negotiated during the handshake protocol.
  
  
• Applies an HMAC (or, for SSL 3.0, a MAC) to outgoing data. It then computes the HMAC and verifies that it is identical to the value that was transmitted in order to check data integrity when a message is received.
  
  

Once the record protocol has completed its operations on the data, it sends the data to the application for transmission. If the data is incoming, it is sent to the appropriate process for reception.

HMAC Hashing in the Record Layer

Fragmented, compressed application data is hashed as it passes through the Record Layer before being encrypted.

Note

• The details in this section provide a glimpse inside the computational “black box” and are meant to illustrate the complexity necessary to secure communications. The key material exchange specifics change over time as new algorithms are developed.
  
  

The MAC consists of two values that are hashed:

• The secret key value: Client or Server Write MAC Secret (derived from the Master Secret).
  
  
• A concatenation of:
  
  
  • The record’s sequence number.
    
    
  • Packet type.
    
    
  • Protocol version.
    
    
  • Packet length.
    
    
  • The non-encrypted application data.
    
    

The result of this hashing and the original compressed data fragment are then encrypted and passed down to TCP.

When the message is decrypted at its destination, a new hash is computed, based on the compressed fragment and the MAC Secret. The new hash is compared to the hash that was sent in the message. If they match, the message’s data integrity is verified.

Note

• Data can be encrypted and decrypted, but you cannot reverse engineer a hash. Hashing is a one-way process. Running the process backward does not recreate the original data. This is why a new hash is computed and then compared to the sent hash.
  
  

Resuming a Secure Session

Once a secure session has been established between a client and a server, the client can attempt to resume the session in the future, using the same keys used in the previous session. If the server is able to resume the session, then the abridged version of the Handshake Protocol below will occur. If not, then a full handshake will occur.

Resume Session Messages

• The client sends a Client Hello message using the Session ID of the session to be resumed.
  
  
• The server checks its session cache for a matching Session ID. If a match is found and the server is able to resume the session, it sends a Server Hello message with the Session ID.
  
  Note
  
  
  • If a session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake.
    
    
• The server must send a Change Cipher Spec message to notify the client that the server will begin encrypting messages with a new set of encryption and MAC keys, based on the cached Master Secret and the Client Random Server Random values from the current connection. This ensures that every connection has its own set of encryption keys. The server switches its record layer security state to symmetric encryption using the session keys.
  
  
• The server sends a Server Finished message.
  
  
• The client must send a Change Cipher Spec message to notify the server that the client will start using the session keys for hashing and encrypting messages.
  
  
• The client sends a Client Finished message.
  
  
• The client and server can now resume application data exchange over the secure channel.
  
  

Renegotiation

Renegotiation Methods

Renegotiation can originate from either the client or the server with the following exceptions:

• No client-side renegotiation in Windows 2000 and Windows XP.
  
  
• No renegotiation in SSL 2.0.
  
  

Server Renegotiation Scenarios

The server can request renegotiation in two situations:

• After the initial handshake, the client requests an access-protected resource. The server can initiate a renegotiation to ask for client authentication. This is the case where the server sends the Hello Request. When the client receives a Hello Request, it begins a new handshake by sending a Client Hello message.
  
  
• To refresh keys. This is performed in the same way as the second case, above.
  
  

Note

• Schannel does not allow the client to ignore the Hello request. The client must initiate a new handshake by sending a Client Hello message, or the server will close the connection with a fatal error.
  
  

Typical Server Renegotiation

Server Initiated Renegotiation

Server-initiated renegotiation uses the following procedure:

• The client and server successfully complete a full TLS/SSL handshake.
  
  
• The client requests for an access-protected resource.
  
  
• The server sends a Hello Request message to the client.
  
  
• The client receives the Hello Request message.
  
  Note
  
  
  • Schannel does not allow the client to ignore the Hello request, but other client’s might. The client must initiate a new handshake by sending a Client Hello message or the Windows server closes the connection.
    
    
• The client sends a Client Hello message to the server to initiate a new full handshake.
  
  

Client Renegotiation Scenarios

The client can also initiate a renegotiation anytime by sending a Client Hello message. This is usually performed to refresh encryption keys.

Typical Client Renegotiation

Client Initiated Renegotiation

Client-initiated renegotiation uses the following procedure:

• The client and the server successfully complete a full SSL handshake.
  
  
• The client needs to refresh encryption keys. The client sends a Client Hello message to the server.
  
  
• The server receives the Client Hello message. The server has no way of knowing that this message is not application data, and so it passes the message on. It is returned as an “extra” buffer containing the unprocessed Client Hello message with a flag signaling that it is a renegotiation.
  
  Note
  
  
  • The server might not respond to the renegotiation request right away. In the most general case, the server might have already sent some application data at the same time that the client is requesting the renegotiation, or it might decide to send some data before responding to the renegotiation request. However, the client will never send more application data after it has initiated a renegotiation.
    
    
• The server sends the Server Hello group of messages to the client.
  
  
• The client receives the Server Hello messages. The client has no way of knowing that this message is not application data, and so it passes the message on. It is returned as an “extra” buffer containing the unprocessed server hello messages with a flag signaling that it is a renegotiation
  
  
• The client sends the next set of handshake messages, which are sent to the server, and the handshake proceeds as usual.
  
  

The Schannel Session Cache

The first time that a client connects to a server, a full handshake is performed. Once this is complete, the Master Secret, Cipher Suite, and certificates are stored in the session cache on the respective client and server machines. TLS/SSL supports a reconnect operation that can be used to enable a client and server to resume a previously-negotiated session. This allows subsequent connections between the same client and server to use a reconnect handshake rather than a full handshake. This is desirable in many cases because the TLS/SSL reconnect requires far less CPU and network bandwidth because there is no need for a key exchange or certificate exchange. But there are cases in which reconnects can be troublesome; such as during performance testing or when the client never reconnects to the same Web server.

Schannel supports reconnects by use of the Schannel session cache because it keeps a list of previous TLS/SSL sessions that are established with the current authenticated logon data that is used by a security principal to establish its identity. The sessions are referenced by the TLS/SSL session ID. Schannel currently maintains up to ten thousand cached sessions for a maximum of ten hours.

How Schannel Uses Certificate Mapping

When a server application requires client authentication, Schannel automatically attempts to map the certificate that is supplied by the client to a user account. You can authenticate users who log on with a client certificate by creating mappings, which relate the certificate information to a Windows user account. After you create and enable a certificate mapping, each time a client presents a client certificate; your server application automatically associates that user with the appropriate Windows user account.

Types of Mapping

In most cases, a certificate is mapped to a user account in one of two ways: a single certificate is mapped to a single user account (one-to-one mapping), or multiple certificates are mapped to one user account (many-to-one mapping). By default schannel will use the following four certificate mapping methods, in order of preference.

S4U Certificate mapping

This is new for Windows Server 2003. Schannel uses the UPN from the client certificate and attempts an S4U logon using the Kerberos security package. The CA that issued the client certificate must have NTAuth trust. The domain of the server and the user must be running in Windows Server 2003 function level. This is the only mapping method that works even when the server is in a different forest than the client user.

User Principal Name mapping

Enterprise CAs place an entry, called a user principal name (UPN), in each certificate. The UPN looks very much like an e-mail name. The UPN is unique within an Active Directory forest. The UPN finds the user’s account in Active Directory, and that account is logged on. UPN mappings are implicit and therefore do not require administrators to create and maintain.

Schannel uses the UPN from the client certificate, and queries Active Directory for a matching user account. The CA that issued the client certificate must have NTAuth trust.

One-to-One Mapping also known as subject/issuer mapping

A method that maps a single user certificate to a single Active Directory user account. Unlike UPN mapping, the administrator must explicitly map a certificate to a user’s account. This certificate can come from any source, as long as the root CA for that certificate is trusted for client authentication. The client certificate can be renewed, etc without affecting this process as long as the subject and issuer name fields do not change.

For example, suppose that users obtain certificates from a CA that is approved by your company. You then take these user certificates and map them to the Active Directory user accounts. This allows users to connect to the server, using TLS from anywhere by providing their client certificate.

Schannel builds an “altSecurityId” string from the client’s certificate’s subject and issuer name fields, and queries Active Directory for a user account with a matchingaltSecurityId property.

Many-to-One Mapping

Many-to-one mapping involves mapping many certificates to a single user account. Many-to-one mapping works the same way as one-to-one mapping, but it maps all client certificates issued by a given CA to the same user account. This certificate can come from any source, as long as the root CA for that certificate is trusted for client authentication.

Schannel builds an “altSecurityId” string from the client’s certificate’s issuer name field, and queries Active Directory for a user account with a matchingaltSecurityId property.

Network Ports Used by TLS/SSL

Port Assignments for Common Applications over TLS/SSL

 

Service Name	TCP
smtp	25
https	443
nntps	563
ldaps	636
ftps-data	989
ftps	990
telnets	992
imaps	993
pop3s	995
ms-sql-s	1433
mfst-gc-ssl	3269
tftps	3713

Related Information

• RFC 2246 in the IETF RFC Database
  
  
• RFC 3546 in the IETF RFC Database
  
  
• RFC 2817 in the IETF RFC Database

原文链接

https://technet.microsoft.com/en-us/library/cc783349(v=ws.10).aspx