An overview of the

SSL, or Secure Sockets Layer, is Layer 5 (session Layer) in the OSI model. It was invented by Netscape in 1994 and comes in versions V2 and V3, while V1 was never made public due to serious flaws. When SSL was developed to V3, it proved itself to be a very good secure communication protocol, so the Internet engineering group IETF renamed it TLS (Transport Layer Security) in 1999 and officially standardized it. The version number was recalculated from 1.0. So TLS1.0 is actually SSLv3.1. The most widely used TLS is 1.2, and previous protocols (TLS1.1/1.0, SSLv3/v2) have been deemed unsafe and will be discontinued by browsers around 2020. TLS is composed of several sub-protocols, such as recording protocol, handshake protocol, warning protocol, password change protocol and extension protocol. It uses many cutting-edge cryptography technologies, such as symmetric encryption, asymmetric encryption and identity authentication.

Concepts presented in the text

concept describe
Symmetric key algorithm
Symmetric-key algorithm Also known as symmetric encryption, encryption and decryption use the same key, or use two keys that can be easily deduced from each other.
Common symmetric encryption algorithms are AES, ChaCha20, 3DES, Salsa20, DES, Blowfish, IDEA, RC5, RC6, and Camellia.
Public key cryptography
Public-key cryptography Because encryption and decryption require two different keys, it is also called asymmetric encryption. It requires two keys, one public and one private. Encrypt the text: the public key is used for encryption and the private key for decryption. Signature: private key encryption, only the corresponding public key can be decrypted. It indicates that the ciphertext is sent by the owner of the public key. The public key may be made public at will, but the private key must never be made available to anyone through any means. Common asymmetric encryption algorithms include RSA, ElGamal, Rabin (a special case of RSA), DSA, and ECDSA. The most widely used is the RSA algorithm.
Encrypt Encrypt Alter the original data with some special algorithm
Key key A parameter entered in a plaintext to ciphertext or ciphertext to plaintext algorithm
Decrypt Decrypt The process of restoring plaintext using a key

Understand symmetric and asymmetric encryption

Encryption can be divided into two categories based on how the key is used:

  • Symmetric encryption
  • Asymmetric encryption

Note: For TLS, the key is a long string of digits, usually in bits. For example, the key length is usually 128, indicating a 16-byte binary string. The key length is 1024 bytes, which is a binary string of 128 bytes.

Symmetric encryption

Symmetric key algorithm (Symmetric key algorithm), also known as Symmetric encryption, private key encryption, and shared key encryption, is a kind of encryption algorithm in cryptography. These algorithms use the same key for encryption and decryption, or two keys that can simply be deduced from each other. In effect, this set of keys becomes a common secret between two or more members in order to maintain exclusive communication links. Compared with public-key encryption, the requirement that both parties obtain the same key is one of the main disadvantages of symmetric key encryption. Common symmetric encryption algorithms include AES, ChaCha20, 3DES, Salsa20, DES, Blowfish, IDEA, RC5, RC6, and Camellia. Symmetric encryption is much faster than public key encryption (asymmetric encryption) and is required in many situations.

Symmetric encryption summary:

  1. At the core of all symmetric encryption algorithms is the XOR operation, expressed as: A XOR B XOR B = A (where B is the symmetric key and A is the plaintext).
  2. In general, symmetric encryption can be of two kinds: stream encryptionandBlock encryption **.
    1. Stream encryption: Only one bit can be encrypted at a time.
    2. Block encryption: Divide the data to be encrypted into blocks and encrypt multiple bits at a time.
  3. In practical applications, symmetric encryption is generally combined with hash algorithm to form a cipher suite to encrypt and hash data at the same time. Symmetric encryption of data cannot guarantee the integrity of the data itself, so it is necessary to add integrity check capability together with hashing algorithm. The integrity check data is called message Authentication Code (MAC). In addition, there are macs with keys, called HMacs.
  4. Symmetric encryption is much faster than asymmetric encryption, so object encryption is generally used for transmitted data.

TLS has a large number of symmetric encryption algorithms to choose from, which are broadly classified as follows:

Note: The use of cryptography suites that are not AEAD is already prohibited in TLS 1.3. AEAD is a paradigm, not a specific encryption standard, which represents an encryption algorithm that includes both encryption and integrity hashing. For example, it can be combined with CBC and SHA1, or it can be directly composed of GCM, which contains encryption algorithm and MAC algorithm.

Symmetric encryption limitation

How to safely exchange symmetric encryption keys is a headache. Some say it would be nice to encrypt the key itself again, but the problem is that if you still use symmetric encryption, you won’t be able to drag the Matryoshka doll. Therefore, we need to find another encryption method, namely asymmetric encryption.

Asymmetric encryption

Solve the symmetric encryption key exchange problem.

Public-key cryptography (English: Asymmetric cryptography) is an algorithm of cryptography, it requires two keys, one is a Public key, the other is a private key; The public key is used for encryption and the private key for decryption. If the plaintext is encrypted using a public key, the original plaintext can only be decrypted using the corresponding private key. The public key used for encryption cannot be used for decryption. Because encryption and decryption need two different keys, it is called asymmetric encryption; Unlike symmetric encryption where encryption and decryption both use the same key. The public key can be made public and released freely. The private key can not be public, must be kept by the user strictly secret, never through any way to anyone, will not be disclosed to the trusted to communicate with the other party. Based on the features of public-key encryption, it can also provide the function of digital signature, so that electronic documents can be as if signed on paper documents. Public key infrastructure (PKI) is implemented in TLS and introduced in HTTP of the world Wide Web as HTTPS and SMTP of E-mail as SMTPS or STARTTLS through the root certificate of a trusted digital certificate authority (DCA) and public key authentication using public key encryption as digital signature.

Asymmetric encryption summary:

  • Asymmetric encryption has two keys: a public key and a private key. The server keeps the private key and the public key can be published freely on the network.
  • One-way. The ciphertext encrypted with the public key can only be decrypted using the private key.
  • Disadvantages: Asymmetric encryption is much slower than symmetric encryption.

Asymmetric algorithms are more difficult to design than symmetric algorithms, and there are only a few in TLS: DH, DSA, RSA, ECC, etc.Asymmetric encryption algorithm can ensure secure exchange of symmetric keys. The client obtains the public key of the server, encrypts the data using the public key, and sends the ciphertext to the server. The server receives the ciphertext and decrypts the data using the private key. However, there are several problems:

  • How do I know if the data is complete? The integrity of the original text has not been checked.
  • How does the client get the correct public key of the server?

Hash algorithm (Abstract algorithm)

The main means to realize integrity check is Digest Algorithm, which is often called hash function and hash function. It has the following characteristics:

  • One-way. The original text cannot be extrapolated from the summary value.
  • Butterfly effect. Small differences in input can lead to drastic changes in output.

The algorithm can generate a unique “fingerprint” for some data. When the receiver receives the data, the same digest algorithm is used to calculate the “fingerprint” and check whether the two are the same. If they are different, the original data is tampered with and discarded.

Note: The digest algorithm is not confidential, and hackers can change the digest as they change it, so true integrity is based on confidentiality. In a hybrid encryption system, the session key is used to encrypt messages and digests, which cannot be modified by hackers. The term is HMAC (Hash message Authentication Code).

How does HTTPS ensure data security

With that in mind, it’s much easier to learn HTTPS. HTTPS is a combination of symmetric encryption and asymmetric encryption, which ensures the security of data transmission.

Mixed encryption

Neither symmetric nor asymmetric encryption alone can be used in real production applications for the following reasons:

encryption Most outstanding Advantages Most prominent Weakness
Symmetric encryption Encryption and decryption speed is very fast, and has special hardware support There are security vulnerabilities in key exchange
Asymmetric encryption The keys do not need to be exchanged, so there is no risk of being exchanged or monitored by hackers The encryption and decryption speed is very slow

From the above discussion we can get the following results:

  1. Since symmetric encryption is fast in encryption and decryption, it is used for data encryption after HTTPS communication is established.
  2. Asymmetric encryption if the encryption and decryption speed is slow, use asymmetric encryption for HTTPS communication connection. It is used to securely exchange keys between two parties.

In this way, you can find the perfect balance between performance and security.

Do you have any questions

Question 1: How do I ensure that the public key obtained by the client is provided by the server?

Since the public key of the server can be published freely on the Internet, this provides opportunities for hackers to forge and replace. It is also easy to solve this problem by using digital certificates.

The digital certificate

Public key certificate (English: Public key Certificate), also known as digital certificate or Identity certificate. Is an electronic file used in public key infrastructure to prove the identity of the public key owner. This file contains the public key information, owner identity information (principal), and digital signature of the file by the digital certificate Authority (issuer) to ensure the overall content of the file is correct. By means of this document, the owner can identify himself to the computer system or other users, thereby gaining trust and authorizing access to or use of certain sensitive computer services. The computer system or other users can verify the contents on the certificate through certain procedures, including whether the certificate is expired or whether the digital signature is valid. If you trust the issuing organization, you can trust the key on the certificate and use the public key to encrypt and communicate with the owner reliably. In short, the certification authority uses its own private key to impose digital signature on the public key of the person (or organization) who needs to be authenticated and generate a certificate, that is, the essence of the certificate is to impose digital signature on the public key. People trust the root certificate of digital certificate certification authority (DCA) and the public key authentication issued by digital signature using public key encryption to form the trust chain architecture, which has been implemented in TLS and widely used in HTTPS of the world Wide Web, SMTPS of E-mail and STARTTLS. The current standard in the industry is X.509 developed by the Telecommunication Standardization Department of the International Telecommunication Union and detailed in RFC 5280 issued by the IETF. In many countries/regions, legislation has recognized that digital signatures made using digital certificates have the same legal effect as personal signatures (for example, the European Union, Hong Kong, Taiwan, the United States and Canada).

Digital Certificate Summary:

  • Digital certificates are used for public key authentication.
  • A certificate generated by a certification authority using its own private key to digitally sign the public key of the person or institution requiring authentication.

Digital certificates and CAS

The trusted digital certificate authority mentioned above is calledCA (Certificate Authority). They specifically sign the public key of a person or organization, and use their own reputation to ensure that the public key can not be forged and trusted. CA to the public key signature is also a format, need to include serial number, purpose, issuer, effective time and so on, these into a package and then signed, complete proof of the public key associated with all kinds of information, formedDigital Certificate.A small CA can be authenticated by a large CA, but a Root CA can only prove itself, which is calledSelf-signed certificateorRoot certificate. The procedure for issuing a CA certificate is as follows:However, CA is not 100% secure, and CA has been compromised by hackers throughout history, so there are additional operations that need to be done to remedy these vulnerabilities, such as the CRL certificate Revocation List and the OCSP Online Certificate Status Protocol (OCSP), in order to promptly revoke problematic certificates.

attestation

After receiving a certificate from the server, the client needs to verify the validity of the certificate. The operating system and browser have built-in root certificates of major CA. When accessing the Internet, as long as the server sends its Certificate, you can verify the signature in the Certificate. Then you can verify the Certificate layer by layer along the Certificate Chain until you find the root Certificate.

Self-signed certificate

A self-signed certificate is a digital certificate that is signed with its own private key. It is available and cost free. Self-issued certificates can be used to encrypt data as well as CA-signed certificates, but because the certificate is not part of a public key infrastructure (PKI) issued certificate, web browsers of other HTTPS visitors who do not trust the certificate display a warning that the certificate is not trusted by their computer or browser. Therefore, self-signed certificates can only be used when there is no need to prove the identity of the service to the user, such as a non-public web server. A non-browser client can connect to an HTTPS server and explicitly trust a self-signed certificate to create secure communication between the client and the server.

Question 2: How do I prevent the signing certificate from being switched?

Virtually any site can apply for a certificate from a third party authority, and middlemen are no exception. Can the middleman intercept the signing certificate and replace it with his own? The answer is no, because in addition to the public key, the signing certificate also contains the domain name of the applicant and other verification information. Although the middleman can switch the signing certificate, the client will consider the certificate as illegal if the domain name is inconsistent when parsing.

HTTPS Handshake Process

RAS handshake process

With these concepts in mind, let’s move on to the HTTPS handshake process. First, let’s look at the RSA handshake process:

  1. Transport layer TCP establishes a connection through a three-way handshake. The TLS handshake process begins.
  2. The first step, the client takes the lead and passesClient HelloThe handshake protocol sends the following to the server:
    1. TSL version number supported by the client.
    2. Client Random number generated by the Client.
    3. List of key suites supported by the client.
    4. Expand the list of

  1. The second step: Server response. Through the serverServer HelloSend the following to the client:
    1. TSL version number.
    2. Random number of the server.
    3. Confirmed password suite.
    4. Expand the list.
    5. Server Certificate
      1. Then send the Server Certificate to the client, which contains your public key.
    6. Server Hello Done
      1. Then, the server sendsServer Hello DoneMessage, the purpose is to tell the client, I have given you what you should give you, the end of the greeting.

  1. The third step: Client response. The client receives the packet from the serverServer HelloAfter handshake agreement, will proceed firstattestationOperation: Use the browser and the built-in CA public key to verify the validity of the signed certificate received from the server. If the authentication is successful, the public key of the server is taken out, which will be used to encrypt the one generated by the clientpre-masterRandom number.
    1. Client Key Exchange: encrypts the pre-master using the server public Key.
    2. Change Cipher Spec: Use the session key to encrypt communication.
    3. Encrypted HandShake Message (Finished) : Digest all data sent before and encrypt it with the session key. The server uses this digest to verify whether data is tampered during TLS.

Why do WE need pre-master random numbers? It must be said that the designers of TLS are very thoughtful, they do not trust the reliability of client or server pseudo-random numbers, in order to ensure that the “completely random” “unpredictable”, three unreliable random numbers mixed together, so that the “random” degree is very high, enough to make hackers hard to guess. In addition, the random number generated by the client is encrypted using the public key of the server, and only the corresponding private key can be decrypted.

  1. The fourth step: The server responds last.
    1. Change Cipher Spec: Use the session key to encrypt communication.
    2. Encrypted HandShake Message (Finished) : Digest all data sent before and encrypt it with the session key. The server uses this digest to verify whether data is tampered during TLS.

RSA handshake Process Summary

  • An RSA handshake requires two RTT delays.
  • TSL contains several sub-protocols, Common protocols include Record Protocol, Alert Protocol, Handshake Protocol, and Change Cipher Spec Protocol. TLS related packet protocols are shown as follows:

  • The RSA handshake is a traditional TLS handshake, not the mainstream handshake in today’s world. Today’s mainstream handshake is achieved using ECDHE instead of RAS.

Key suite

When establishing connections using TLS, browsers and servers need to select a set of encryption algorithms to secure communication. A combination of these algorithms is called a cipher suite. The naming conventions are as follows:

Key exchange algorithm + signature algorithm + symmetric encryption algorithm + digest algorithm for example, ecdhe-RSA-AES256-GMC-SHA384 - ECDHE algorithm is used for key exchange during handshake, - RSA signature and identity authentication are used, - AES symmetric algorithm is used for communication after handshake, key length is 256 bits, - GCM is used for grouping mode, - Digest algorithm SHA384 is used for message authentication and random number generationCopy the code

ECDHE

RSA is a traditional key exchange algorithm. It has the following disadvantages:

  • No “run.” In other words, application data can be sent only after 2*RTT delay.
  • No forward security. As long as the hacker cracked, the data sent before can be cracked.

ECDHE algorithm is widely used at present, it can solve the above two problems.

DH key negotiation algorithm

The ECDHE key negotiation algorithm is evolved from the DH algorithm, so we start with the DH algorithm.

  • Diffie-he LLman algorithm, or DH algorithm for short, is a public key algorithm published by Whitfield Diffie and Martin Hellman in 1976. It has a longer history than RSA public key algorithm.
  • DH implements key exchange or key negotiation. During key negotiation using the DH algorithm, neither of the two communicating parties can independently calculate a session key. The two communicating parties retain some key information and share the other information with the other party. The other party can calculate the same session key together only when they have all the information.
  • Data base: For an integer
    b b     And the prime Numbers
    p p     A primordial root of
    a a     , you can find a unique exponent
    i i     ,
    a i m o d p = b a^i mod p = b     True. So the exponent
    i i     Referred to as
    b b     The to
    a a     Is the modulus of the base
    p p     The discrete logarithm of phi.

    • Base AAA and module PPP are common parameters of the discrete logarithm, that is, exposed. BBB is a real number, and iii is a logarithm. If you know logarithm iii, you can use the formula above to calculate the real number BBB, but conversely, if you know the real number BBB, you can easily predict logarithm iii. Especially when module PPP is a large prime number, even if the base aaa and real BBB are known, it is almost impossible to calculate the discrete logarithm with the current computer computing level.

Assume that AB uses the DH key negotiation algorithm to exchange keys, the procedure is described as follows:

  1. A selects A prime number p=509p=509p=509, base A = 5A =5a=5, and generates A random number IC = 123i_C = 123IC =123. The discrete logarithm formula Yc= aICmodp = 5123MOD509 =215Y_c=a^{i_C} mod P =5 ^{123} mod509=215Yc= aICmodp = 5123MOD509 =215. A then sends B A =5,p=509,Yc= 215A =5,p=509,Y_c= 215A =5,p=509,Yc=215.
  2. B also generates a random number is= 456i_S =456is=456, Then calculate Ys= 5ISmodp =5456mod509=181Y_s=5^{i_S} mod P =5^{456} mod509=181Ys= 5ISmodp =5456mod509=181, SecretKeys=Ycismodp=215456mod509=121SecretKey_s=Y_c^{i_s} modp=215 ^{456} Mod509 = 121 secretkeys = Ycismodp mod509 = 215456 = 121. Pass Ys=181Y_s=181Ys=181 as the public key of the server to A.
  3. Ys=181Y_s=181Ys=181, SecretKeyc=Ysicmodp=181123mod509=121SecretKey_c=Y_s^{i_c} modp=181 ^{123} Mod509 =121SecretKeyc=Ysicmodp=181123mod509=121

As can be seen from the above calculation process, as long as the random numbers IC = 123I_C = 123IC =123 and IS = 456I_S = 456IS =456 generated by A and B respectively are not exposed, hackers know that other parameters cannot be cracked by violence. Disadvantages: Parameters A and P of the static DH algorithm are fixed, and the public key YsY_sYs of the server is fixed. As time goes by, hackers can brute force crack the system by analyzing massive data. Therefore, forward security cannot be provided. The advantage of the static DH algorithm is that the server does not frequently generate parameters A and P during connection initialization, because this process consumes CPU resources.

DHE key negotiation algorithm

The letter E stands for ephemeral. Since static DH can be cracked, I randomly generate temporary A and P during key negotiation. In this way, even if the private key of one communication process is cracked, the other communication process is still secure.

ECDHE key negotiation algorithm

Due to the poor computational performance of DHE algorithm and the need to do a lot of multiplication, in order to provide the performance of DHE algorithm, now widely used ECDHE algorithm emerged.

Elliptic Curve Diffiety-Hermann Key Exchange Elliptic Curve Diffie — Hellman Key Exchange (ECDH) is an anonymous key-agreement protocol, which is a variant of Diffie-Hellman key exchange. Elliptic curve cryptography is used to enhance performance and security. In this protocol, both parties establish secure common encrypted data over an insecure channel using public and private key pairs established by elliptic curve cryptography. The temporary ECDH (ECDH Ephemeral, ECDHE) provides forward security.

Based on DHE algorithm, ECDHE algorithm utilizes ECC elliptic curve characteristics, which can obtain public key and final session key with less computation. The ECDHE key negotiation algorithm used by both parties is described as follows:

  1. Both sides decide in advance which elliptic curve to use and the base point GGG on the curve. These two parameters are public.
  2. Each party generates a random number as the private key DDD and multiplies it with base point GGG to obtain the public key Q(Q=dG)Q(Q=dG)Q(Q=dG), Where the client and the server public key and a private key (Qc, dc) respectively (Q_c, d_c) (Qc, dc), (Qs, ds) (Q_s d_s) (Qs, ds).
  3. Each public key exchange, the client computing point (Xc, Yc) = dc ∗ Qs (X_c Y_c) = d_c * Q_s (Xc, Yc) = dc ∗ Qs, server-side computing point (Xs and Ys) ∗ Qc (X_s Y_s) = = ds d_s * Q_c (Xs and Ys) = ds ∗ Qc. Since the commutative law of multiplication and associative law can be satisfied on elliptic curve, the derivation formula is as follows: Dc = dc ∗ ∗ Qs ds < = = > ds ∗ ∗ G ∗ dc Qc = ds ∗ d_s Q_s = d_c Gd_c * * * G < = = > d_c Q_c = d_s d_s * * * Gdc ∗ Qs = dc < = = > ds ∗ ∗ ∗ ds G Qc = ds ∗ ∗ G direct current (dc), therefore, both sides of the XXX coordinates are the same, XXX is not the final session key, but a pre-master key.

ECDHE handshake process

With that said, back to the ECDHE handshake process, as shown below:

  1. Transport layer TCP establishes a connection through a three-way handshake. The TLS handshake process begins.
  2. The first step, the client takes the lead and passesClient HelloThe handshake protocol sends the following to the server:
    1. TSL version number supported by the client.
    2. Client Random number generated by the Client.
    3. List of key suites supported by the client.
    4. Expand the list of

  1. The second step, the server receivedClient HelloAfter, will returnServer HelloThe message. It reads as follows:
    1. TSL version number.
    2. Random number of the server.
    3. Confirmed password suite.
    4. Expand the list.
    5. Server Certificate
      1. Then send the Server Certificate to the client, which contains your public key.
    6. Server Key Exchange
      1. Because the server has chosen the ECDHE algorithm, this message is included. Inside is the public key (Server Params) of the elliptic curve, used to implement the key exchange algorithm.
    7. Server Hello Done
      1. Then, the server sendsServer Hello DoneMessage, the purpose is to tell the client, I have given you what you should give you, the end of the greeting.

  1. The third step, and the client responds. The client receives the packet from the serverServer HelloAfter handshake agreement, will proceed firstattestationOperation: Use the browser and the built-in CA public key to verify the validity of the signed certificate received from the server. If the authentication is successful, the public key of the server is taken out, which will be used to encrypt the one generated by the clientClient ParamsElliptic curve public key.
    1. Client Key Exchange
      1. The Client also generates an elliptic curve public key (Client Params) from the cipher suite selected by the server.
    2. Change Cipher Spec: Use the session key to encrypt communication.
    3. Encrypted HandShake Message (Finished) : Digest all data sent before and encrypt it with the session key. The server uses this digest to verify whether data is tampered during TLS.

  1. The fourth stepAt this point, the client has all the data to generate the session key: client random number, Server random number, Server elliptic curve public key Server Params. Elliptic curve public key Client Params.
    1. Generate a pre-master random number through Server Params and Client Params.
    2. The master key, that is, the session key, is generated through the random number of the client, the random number of the server, and the pre-master. Since there is no need to exchange the pre-master, 0.5 RTT of waiting is reduced.
    3. At this point, the client can use the session key to encrypt the data and send it to the server.
  2. Step 5, the server finally responds.
    1. Change Cipher Spec: Use the session key to encrypt communication.
    2. Encrypted HandShake Message (Finished) : Digest all data sent before and encrypt it with the session key. The server uses this digest to verify whether data is tampered during TLS.

RAS and ECDHE

  • RAS does not support forward secrecy, ECDHE supports forward secrecy (E).
  • RAS does not support False Start, while ECDHE does. Encrypted application data can be sent after step 4 but before step 5 to reduce the TLS handshake round-trip from 2*RTT to 1 *RTT.

Optimize the HTTPS

Replay attack

Assuming that middleman in some way, intercepting the POST request of the client using session reuse technology, is usually a POST request to change database data, then the broker can intercept the message sent to the server, the server after receive, is considered to be legitimate, then restore sessions, the database of the data has been changed, But the user doesn’t know that. The way to avoid replay attacks is to set a reasonable expiration time for the session key.

reference

HTTPS principle: ECDHE key negotiation algorithm