TLS protocol literacy (handshake, asymmetric encryption, certificates, electronic signatures, etc.)

The best way to learn the TLS protocol is to look at the RfC, but if there is no basic understanding of the secure transport protocol, it is difficult to read the details and design principles of the RFC, so here in order to be able to further understand the TLS protocol, put some basic knowledge here, is a sweep blind.

1. The difference between TLS and SSL: SSL is the predecessor of TLS, and TLS makes some improvements that make it more secure. In fact, the supported protocol version is attached when the client initiates a connection request to the server, and the protocol version here identifies the SSL or TLS (3.1 for TLS)

2. TLS uses symmetric encryption during true transmission because symmetric encryption is more efficient. The key used for symmetric encryption is negotiated using a specific algorithm during the handshake. The old version of SSL uses the RSA negotiation algorithm, which uses the server's public key to encrypt the symmetric key generated randomly by the transport client. This approach has some security implications, and the latest Diffie-hellman algorithm can be more secure by not passing any information about symmetric keys during the negotiation process.

3. The client authenticates the server using a certificate. Certificates are generally issued by other agencies, which contain the public key of the certificate and hash the contents of the certificate at the end and encrypt the hash value with the issuing authority's own private key (electronic signature). The client can decrypt the electronic signature at the end of the certificate with the public key of the issuing authority in the certificate, and verify that the decrypted hash value is consistent with the hash value of the certificate body to verify that the certificate is actually issued for the alleged issuing authority. The process of verifying the issuer can be continuously recursive until a trusted issuer is validated, or the electronic signature verification fails. The procedure described above only verifies the trustworthiness of the certificate itself, and cannot verify that the server providing the certificate actually holds the relevant certificate . On how to verify that the server is indeed the holder of the certificate, this I do not quite understand, there may be two ways: 1. To have the server encrypt a piece of text with the private key corresponding to the public key in the certificate, the client decrypts the ciphertext with the public key of the certificate and verifies that the server's private key corresponds to the public key of the certificate (how to protect the person in the loop ) 2. Verify the CN in the certificate and the CN of the server (this is my problem also how to prevent people in the loop machine to forge information?) ）

This is roughly the key point, and there is time to fill in the details later.

Resources:

Https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_Public-Key_Cryptography#How_CA_ Certificates_are_used_to_establish_trust

Https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_SSL

Http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_FORWARD_SECRECY

TLS protocol literacy (handshake, asymmetric encryption, certificates, electronic signatures, etc.)