Overview of the operating mechanism of the SSL/TLS protocol (reprint plus personal understanding)

First, the role

HTTP communications that do not use SSL/TLS are non-encrypted traffic. All information is transmitted in plaintext, potentially three major risks.

1, eavesdropping risk (eavesdropping): Third party can learn the content of the communication.
2. Tamper risk (tampering): Third parties may modify the content of the communication.

3. Impersonation risk (pretending): A third party may participate in the communication by impersonating another person's identity.

The SSL/TLS protocol is designed to address these three risks and is intended to achieve:

1, all information is encrypted transmission, third party cannot eavesdrop.

2, with a calibration mechanism, once tampered with, the two sides will immediately find the communication.

3, equipped with identity cards, to prevent identity is impersonating.

Second, history

The history of Internet encrypted communication protocols is almost as long as the Internet.

In 1994, Netscape worked on the SSL protocol (Secure Sockets Layer) version 1.0, but was not published.

In 1995, Netscape released SSL version 2.0, and soon found a serious loophole.

In 1996, the release of SSL 3.0 was widely used.

1999, the Internet Standardization organization ISOC replaced Netscape Company, released the SSL upgrade version of TLS version 1.0.

In 2006 and 2008, TSL was upgraded two times, TLS version 1.1 and TLS 1.2 respectively. The latest change is the 2011 revision of the TLS 1.2.

Currently, the most widely used is TLS 1.0, followed by SSL 3.0. However, the majority of browsers have implemented TLS 1.2 support.

TLS 1.0 is typically marked as SSL 3.1,TLS 1.1 for SSL 3.2,tls 1.2 for SSL 3.3.

Three, the basic operation process

The basic idea of the SSL/TLS protocol is to use public key cryptography, that is, the client requests the public key to the server, then encrypts the information with the public key, and after the server receives the ciphertext, the server decrypts it with its own private key.

However, there are two issues:

1, how steamed bun public key is not tampered with?

WORKAROUND: Place the public key in the House digital certificate. As long as the certificate is trustworthy, the public key is trustworthy.

2, public key encryption calculation is too large, how to reduce the elapsed time?

Workaround, each session, both the client and the server generate a "conversation key" (Session key), which is used to encrypt the information. Because the conversation key is symmetric encrypted,

The operation is very fast. The server public key is used only to encrypt the "conversation key" itself, which reduces the time spent on cryptographic operations.

Therefore, the basic process of the SSL/TLS protocol is this:

1. The client requests and verifies the public key from the server side.

2, the two sides negotiated as "dialogue key".

3, the two sides use "dialogue key" for encrypted communication.

Http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

Overview of the operating mechanism of the SSL/TLS protocol (reprint plus personal understanding)