HTTPS：TLS握手过程

===TLS handshake===
When the connection starts, the record encapsulates a “control” protocol—the handshake messaging protocol  (”content type” 22). This protocol is used to exchange all the information required by both sides for the exchange of the actual application data by TLS. It defines the messages formatting or containing this information and the order of their exchange. These may vary according to the demands of the client and server—i.e., there are several possible procedures to set up the connection. This initial exchange results in a successful TLS connection (both parties ready to transfer application data with TLS) or an alert message (as specified below).

====Basic TLS handshake====
A typical connection example follows, illustrating a [[Handshaking|handshake]] where the server (but not the client) is authenticated by its certificate:

Negotiation phase:
* A client sends a ”’ClientHello”’ message specifying the highest TLS protocol version it supports, a random number, a list of suggested [[cipher suite]]s and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a ”session ID”. If the client can use [[Application-Layer Protocol Negotiation]], it may include a list of supported application [[Communications protocol|protocols]], such as [[HTTP/2]].
* 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. To confirm or allow resumed handshakes the server may send a ”session ID”. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.0 should not be selected.
* The server sends its ”’Certificate”’ message (depending on the selected cipher suite, this may be omitted by the server).These certificates are currently [[X.509]], but RFC 6091 also specifies the use of [[OpenPGP]]-based certificates.
* The server sends its ”’ServerKeyExchange”’ message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE and DH_anon ciphersuites.
* The server sends a ”’ServerHelloDone”’ message, indicating it is done with handshake negotiation.
* The client responds with a ”’ClientKeyExchange”’ message, which may contain a ”PreMasterSecret”, public key, or nothing. (Again, this depends on the selected cipher.) This ”PreMasterSecret” is encrypted using the public key of the server certificate.
* 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 [[pseudorandomness|pseudorandom]] function.
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.
* Finally, the client sends an authenticated and encrypted ”’Finished”’ message, containing a hash and MAC over the previous handshake messages.
* 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.
Finally, the server sends a ”’ChangeCipherSpec”’, telling the client, “Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated).”
* The server sends its authenticated and encrypted ”’Finished”’ message.
* The client performs the same decryption and verification.
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. Otherwise, the content type will return 25 and the client will not authenticate.

====Client-authenticated TLS handshake====
The following ”full” example shows a client being authenticated (in addition to the server as in the example above) via TLS using certificates exchanged between both peers.

Negotiation Phase:
* A client sends a ”’ClientHello”’ message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
* The server responds with a ”’ServerHello”’ message, containing the chosen protocol version, a random number, cipher suite 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.
* The server sends its ”’Certificate”’ message (depending on the selected cipher suite, this may be omitted by the server).
* The server sends its ”’ServerKeyExchange”’ message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE and DH_anon ciphersuites.
* The server requests a certificate from the client, so that the connection can be [[mutually authenticated]], using a ”’CertificateRequest”’ message.
* The server sends a ”’ServerHelloDone”’ message, indicating it is done with handshake negotiation.
* The client responds with a ”’Certificate”’ message, which contains the client’s certificate.
* The client sends a ”’ClientKeyExchange”’ message, which may contain a ”PreMasterSecret”, public key, or nothing. (Again, this depends on the selected cipher.) This ”PreMasterSecret” is encrypted using the public key of the server certificate.
* The client sends a ”’CertificateVerify”’ message, which is a signature over the previous handshake messages using the client’s certificate’s private key. This signature can be verified by using the client’s certificate’s public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
* 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.
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 was negotiated). ” The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
* Finally, the client sends an encrypted ”’Finished”’ message, containing a hash and MAC over the previous handshake messages.
* 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.
Finally, the server sends a ”’ChangeCipherSpec”’, telling the client, “Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). ”
* The server sends its own encrypted ”’Finished”’ message.
* The client performs the same decryption and verification.
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 encrypted exactly like in their ”Finished” message.

====Resumed TLS handshake====
Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations: resumed sessions. Resumed sessions are implemented using session IDs or session tickets.

Apart from the performance benefit, resumed sessions can also be used for [[Single sign-on]], as it guarantees that both the original session and any resumed session originate from the same client. This is of particular importance for the [[FTPS|FTP over TLS/SSL]] protocol, which would otherwise suffer from a man-in-the-middle attack in which an attacker could intercept the contents of the secondary data connections.{{cite web|author=Chris |url=http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html |title=vsftpd-2.1.0 released – Using TLS session resume for FTPS data connection authentication |publisher=Scarybeastsecurity. blogspot.com |date=2009-02-18 |accessdate=2012-05-17}}