Ciencias Naturales Para esta área, el modelo desarrolla tres cartillas, por consiguiente, es la que más se aproxima al conocimiento y contexto del niño, el

The handshake presented here includes some optional elements that are not always used, but the order in which the messages are exchanged is important. Also for final integrity checking, both client and server need to maintain a copy of all the messages that are exchanged during the handshake. The handshake is performed as shown in Figure 4.12 and described as follows:

● The client, who is typically the initiator of the session, sends a client hello message to the server. This message includes an ordered list (based on preference) of cipher suites the client can support. In TLS context, cipher suite is the certificate types and encryption and integrity checking methods the client can understand. The client also includes a nonce to provide liveliness and anti-replay protection.

Client Server Client hello Server hello Server certificate Server done Client certificate Certificate verify Client certificate request

Finished Client key exchange

Change cipher spec

Finished Change cipher spec

● After checking the cipher suites supported by the client, the server in turn sends a server hello message and possibly counters with its own cipher suites. The message also includes a nonce from the server and a session ID assigned by the server for the session to be established. By now the client and the server have agreed on the cipher suites to use. The session ID can be used by the client at any later time when resuming a TLS session with that server, if desired.

● To accommodate authentication to the client, the server sends its certificate in a server certificate message. Often, to save signaling overhead, this message is piggybacked with the server hello. The name and public key of the server are included in a certificate, which is signed by a CA. The CA signature proves that the public key and name actually belong to the server.

● The client uses the public keys included in the server certificate to verify the server certificate and authenticity. The client extracts server’s public key for encryption of future messages to server as well.

● If the server requires client authentication, it asks for client certificate, using a client certificate request, otherwise the server sends a server done, which can also be piggybacked over the server hello and server certificate messages.

● The client then generates a random number called pre-master secret and encrypts the number with the public key of the server (obtained from the certificate) and sends it inside a client key exchange message to the server. This number is called pre-master key, since it is later used to create the master key between client and server and therefore is hidden from public. Only the server is able to decrypt the pre-master key using its own private key. Note that without client authentication, nothing prevents a rouge client to create the same pre-master secret.

● If required by the server, the client sends its own signing certificate using the client certificate

message. To prove to the server that it is owner of the certificate, the client hashes all the messages exchanged up to this point (except the client hello) and signs the hash with its private key. The client sends the signature in certificate verify message. The client also sends a change cipher spec message to the server to indicate that the following messages will be protected using the cipher suites and keys that were just negotiated and established. The client also sends a finished message to confirm the use of the new master (calculated as described in the following).

● The server decrypts the pre-master secret with its own private key. Also if client authentication was required and certificate verify message was provided by the client, the server verifies the authentication provided by the client.

● Now that both client and server have the pre-master key, they both can create the master key by hashing the client nonce, the server nonce, and the pre-master secret. Now both the client and server share this master key. At this point, the handshake process is complete and keys are exchanged.

● The server sends a change cipher spec message to indicate to the client that the following messages will be protected using the cipher suites and keys that were just negotiated and established. The server also sends a finished message to the client at this point.

As we see, the handshake protocol not only provides a means for negotiation of security mechanisms and exchange of cryptographic parameters, but also provides for mutual authentication and establishment of a secure channel for the following communications. In a way, the handshake protocol within TLS provides for the record layer what IKE does for IPsec without requiring a separate protocol.

The master key generated during TLS handshake protocol is used for generating future symmetric keys to provide encryption and message authentication services for data traffic exchanged through the TLS record protocol.