SSL/TLS Brown Bag (Ⅲ)

This article will introduce some special processes.

Client Authentication

Generally client will validate server's certificates(chain). A non-anonymous server can optionally request a certificate from the client. This is mutual authentication.🤔
I use OpenSSL to simulate this process. For more information about how to use OpenSSL command, please refer https://www.openssl.org/docs/man1.0.2/man1/openssl-s_server.html
https://www.openssl.org/docs/man1.0.2/man1/openssl-s_client.html
Server: openssl s_server -cert cert.pem -key private.key -CAfile issuer.pem -port 443 -CApath ./ -Verify 2
Client: openssl s_client -connect 10.0.0.156:443 -servername mml.mml.cn -cert cert.pem -key private.key
There are some messages during this process. Let's check them.

Certificate Request

Server request a certificate from the client by this message. This message tell client what kind of certificate that server need. It specify Signature Algorithm and Certificate type. Distinguished Name is important because it represent the client certificate's issuer. Client should sent the certificate which issued by the Distinguished Name.

Client Certificate

This message conveys the client's certificate chain to the server.This message is only sent if the server requests a certificate. If no suitable certificate is available, the client must send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. If the client does not send any certificates, the server may at its discretion either continue the handshake without client authentication, or respond with a fatal handshake_failure alert.

Certificate Verify

This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters). When sent, it must immediately follow the client key exchange message.
Here message refers to all handshake messages sent or received, starting at client hello and up to, but not including, this message, including the type and length fields of the handshake messages. Client hash all messages and sign them.

Session Resumption

If there is already a SSL session previously. The next time client and server may resume this session if they both support this feature. The cost of full SSL handshake is so large. session resumption will save resources. After server hello, the data transport is started.
There are two kinds of session resumption: Session ID and Session Ticket.

Session ID

Client hello message carries Session ID. And also server hello message carries Session ID. It means Client and Server should maintain the state information associated with that session(Key, ciphers, and so on),while not a big deal for client application this can become a significant use of resources for a server which is handling potentially thousands of connections.
OpenSSL can simulate Session ID resumption process.
Server: openssl s_server -cert cert.pem -key private.key -CAfile issuer.pem -port 443
Client: openssl s_client -connect 10.0.0.156:443 -servername mml.mml -reconnect -no_ticket
-no_ticket means don't use session ticket.

Session Ticket

If Client support Session Ticket, client hello message will carry an empty Session Ticket extension. Server hello message will reply a Session Ticket to client. This ticket is encrypted by server and contains the session state. Client also need store the session state. Client just need send this ticket to server by client hello once it want to resume a session.
*Please note: Session Ticket will destroy the security model. Because the key which encrypt the Ticket may weaker than the session key.*

For more information about TLS1.2, please refer RFC5246