Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer (SSL),^[1] are cryptographic protocols designed to provide communications security over a computer network.^[2] Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). 

Client-server applications use the TLS protocol to communicate across a network in a way designed to prevent eavesdropping and tampering.

Since applications can communicate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection. One of the main ways of achieving this is to use a different port number for TLS connections, for example port 443 for HTTPS. Another mechanism is for the client to make a protocol-specific request to the server to switch the connection to TLS; for example, by making a STARTTLS request when using the mail and news protocols.

Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure. The protocols use a handshake with an asymmetric cipher to establish not only cipher settings but also a session-specific shared key with which further communication is encrypted using a symmetric cipher.

During this handshake, the client and server agree on various parameters used to establish the connection's security:

• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions).
• From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.
• The server usually then provides identification in the form of a digital certificate. 
• The client confirms the validity of the certificate before proceeding.
• To generate the session keys used for the secure connection, the client either:
  • encrypts a random number with the server's public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session
  • uses Diffie–Hellman key exchange to securely generate a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server's private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party. This process doesn't depend on RSA to provide secure channel and so RSA is only used for authentication.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the session key until the connection closes. If any one of the above steps fails, then the TLS handshake fails and the connection is not created.

TLS and SSL do not fit neatly into any single layer of the OSI model or the TCP/IP model. TLS runs "on top of some reliable transport protocol (e.g., TCP)," which would imply that it is above the transport layer. It serves encryption to higher layers, which is normally the function of the presentation layer. However, applications generally use TLS as if it were a transport layer, even though applications using TLS must actively control initiating TLS handshakes and handling of exchanged authentication certificates.

Reference：
https://en.wikipedia.org/wiki/Transport_Layer_Security
https://www.thesslstore.com/blog/difference-sha-1-sha-2-sha-256-hash-algorithms/

1 Encryption

Although there are a few different public-key encryption algorithms, the most popular — and fortunately, the easiest to understand — is the RSA algorithm, named after its three inventors Rivest, Shamir and Adelman. To apply the RSA algorithm, you must find three numbers e, d and n related such that ((m^e)^d) % n = m. Here, e and n comprise the public key and d is the private key. When one party wishes to send a message in confidence to the holder of the private key, he computes and transmits c = (m^e) % n. The recipient then recovers the original message m using m = (c^d) % n.

Reference：
http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art012
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/

2 Cipher Suite

A cipher suite is basically a complete set of methods (technically known as algorithms) needed to secure a network connection through SSL (Secure Sockets Layer) / TLS (Transport Layer Security). The name of each set is representative of the specific algorithms comprising it.

We'll show you how these names look like in a short while. In the meantime, let's talk about the algorithms that make up a cipher suite. The algorithms that make up a typical cipher suite are the following:

• key exchange algorithm - dictates the manner by which symmetric keys will be exchanged;
• authentication algorithm - dictates how server authentication and (if needed) client authentication will be carried out.
• bulk encryption algorithm - dictates which symmetric key algorithm will be used to encrypt the actual data; and
• Message Authentication Code (MAC) algorithm - dictates the method the connection will use to carry out data integrity checks.

To be clear, one cipher suite typically consists of one (1) key exchange, 1 authentication, 1 bulk encryption, and 1 MAC algorithm. If you're not familiar with what these algorithms do, I suggest you open those links above in a new browser tabs and read them later.

• Some key exchange algorithms: RSA, DH, ECDH, ECDHE;
• Some authentication algorithms: RSA, DSA, ECDSA;
• Some bulk encryption algorithms: AES, 3DES, CAMELLIA;
• Some MAC algorithms: SHA, MD5

Reference：

• https://www.jscape.com/blog/cipher-suites

2.1 DHE

DHE (DH in ephemeral mode) is used in conjunction with a signing certificate, which can be either RSA or DSA. The server sends its cert which client validates, and also its DH group and ephemeral public key signed under its cert; client generates its ephemeral key in the same group and sends that, plus its cert and signature if client authentication is used.

Ephemeral public key is used to ensure Forward secrecy, which is a property defined relatively to ulterior theft of server secrets (server private/public keys). "DHE_RSA" cipher suites provide forward secrecy because every time a session is created, a NEW private/public key pair is generated, thus not saved by the server -- if the server does not save that key on its disk, then it should be immune to ulterior theft. Conversely, "DH_RSA" implies that the DH private key is stored somewhere on the server's hard disk, and if that key is stolen, then past recorded session can be decrypted.

Reference:

• https://crypto.stackexchange.com/questions/12730/at-what-stage-is-dhe-and-rsa-used-during-the-ssl-tls-handshake
• https://security.stackexchange.com/questions/120140/what-is-the-difference-between-dh-and-dhe
• https://medium.com/asecuritysite-when-bob-met-alice/ephemeral-diffie-hellman-c07c54afabff

3 Session

The asymmetric cryptography (RSA, DH...) results in a shared secret called the master secret. From the master secret are derived the symmetric keys used for encryption.

The distinction relates to the difference between a connection and a session. When a client opens a connection to a server, the two may engage in a new full handshake, with asymmetric cryptography, which results in a new master secret. OR they could agree to reuse a master secret from a previous connection. This latter case is called an "abbreviated handshake". Different connections which work over the same master secret are called a session, and is identified by a session ID which client and server send to each other in their ClientHello and ServerHello messages. See this answer for details on this process.

When a master secret is reused, i.e. for a new connection within a session, new symmetric keys are derived nonetheless, because the derivation works over both the master secret, AND two random values that the client and server send each other in their initial messages. Therefore, symmetric keys are renewed with each connection, but through derivation from a "master secret" which can be remembered for a long time, and reused for many successive connections.

Reference:

• https://security.stackexchange.com/questions/55454/how-long-does-an-https-symmetric-key-last