Why you need HTTPS

HTTP is in plaintext, which means that any node in between the sender and the receiver can know what you’re sending. These nodes may be routers, proxies, and so on.

The most common example is when a user logs in. The user enters an account number, a password, and if HTTP is used, all you have to do is fiddle with the proxy server to get your password.

User login –> proxy server (tampering) –> actual authorization server

Encrypt the password at the sending end? Useless, although others do not know how much your original password is, but can get encrypted after the account password, so can log in.

How does HTTPS ensure security

HTTPS stands for secure HTTP, a more secure version of HTTP. For those of you who know the basics of networks, HTTP is an application-layer protocol, and below HTTP is the transport protocol TCP. TCP takes care of the transport, while HTTP defines how the data is wrapped.

HTTP –> TCP (plaintext transport)

How is HTTPS different from HTTP? TLS/SSL is a layer of encryption between HTTP and TCP.

What is TLS/SSL?

In layman’s terms, TLS and SSL are similar things. SSL is an encryption suite that encrypts HTTP data. TLS is an upgraded version of SSL. Now when I say HTTPS, cryptosuite basically means TLS.

The process of transmitting encryption

Instead of sending data directly to TCP, the application layer sends the data to TLS/SSL, encrypts the data, and then sends it to TCP for transmission.

Roughly as shown in the figure.

That’s the way it is. Encrypting data and transmitting it, rather than letting it run naked across a complex and dangerous network, goes a long way to securing it. That way, even if the data is intercepted by intermediate nodes, the bad guys can’t read it.

How does HTTPS encrypt data

Those who are familiar with the basics of security or cryptography should be aware of common encryption methods. Generally speaking, encryption is classified into symmetric encryption and asymmetric encryption (also known as public-key encryption).

Symmetric encryption

Symmetric encryption means that the key used to encrypt the data is the same key used to decrypt the data.

Symmetric encryption has the advantage of high encryption and decryption efficiency. The disadvantage is that the data sender and the data receiver need to negotiate and share the same key, and ensure that the key is not disclosed to others. In addition, for multiple individuals with data exchange requirements, the cost of allocating and maintaining a key between two individuals is basically unacceptable.

Asymmetric encryption

Asymmetric encryption means that the key used to encrypt the data (the public key) is different from the key used to decrypt the data (the private key).

What is a public key? That’s literally what it means — a public key that anyone can look up. Therefore asymmetric encryption is also called public-key encryption.

A private key, on the other hand, is a private key held by the administrator of a web site.

What’s the connection between the public and private keys?

In simple terms, data encrypted with a public key can only be unlocked with a private key. Data encrypted with the private key can only be unlocked using the public key.

Many of you know that you can decrypt data encrypted by a public key using a private key, but you forget that data encrypted by a private key can also be decrypted using a public key. This is key to understanding HTTPS’s entire encryption and authorization system.

Take an example of asymmetric encryption

  • Login user: Xiao Ming

  • Authorized Website: a well-known social networking website (hereinafter referred to as XX)

Xiaoming is a user of XX, a well-known social networking website. XX used asymmetric encryption in the login place for security consideration. Xiao Ming enters the account number and password in the login interface and clicks “login”. Therefore, the browser uses the public key to encrypt xiaoming’s account password, and sends a login request to XX. The login authorization program of XX decrypts the account and password through the private key and verifies them. After that, xiaoming’s personal information (including privacy) is encrypted through the private key and transmitted back to the browser. The browser decrypts the data through the public key and displays it to Ming.

  • Step 1: Xiaoming input the password of the account –> encrypt the browser with the public key –> send the request to XX

  • Step 2: XX decrypts with the private key, verifies that the data is successful –> obtain Xiaoming social data, encrypts with the private key –> browser decrypts the data with the public key, and displays it.

Can asymmetric encryption solve the problem of data transmission security? The public key can unlock the data encrypted by the private key, and the public key is encrypted. In other words, asymmetric encryption can only guarantee the security of one-way data transmission.

In addition, there is the issue of how public keys are distributed/acquired. These two questions will be discussed further below.

Public-key encryption: two obvious problems

The example of Xiaoming logging on social networking site XX was given in the previous section, and it was mentioned that there are two obvious problems in using public key encryption alone.

  1. How to Obtain a public key

  2. Data transmission is secure only in one direction

Question 1: How do I obtain the public key

How does the browser get the public key of XX? Of course, Xiao Ming can check online, XX can also post the public key on his home page. However, for a social networking site that can win or lose tens of millions of yuan at every turn, it will cause great inconvenience to users, after all, most users do not know what a “public key” is.

Problem 2: Data transmission is secure only in one direction

As mentioned above, only the private key can unlock the data encrypted by the public key, so Xiao Ming’s account number and password are safe, and he is not afraid of being intercepted halfway.

Then there’s the big problem: the public key can unlock the data encrypted by the private key. Plus the public key is public, Ming’s private data is equivalent to running naked on the Internet in a different way. (After the intermediate proxy server gets the public key, it can decrypt Xiaoming’s data without hesitation.)

The following are the answers to these two questions.

Question 1: How do I obtain the public key

There are two very important concepts involved here: certificates and CA (certificate Authority).

certificate

For now, think of it as an ID card for a website. The ID card contains a lot of information, including the public key mentioned above.

In other words, when users such as Xiao Ming, Xiao Wang and Xiao Guang access XX, they no longer need to search for the public key of XX all over the world. When they access XX, XX sends the certificate to the browser and tells them to encrypt the data with the public key inside.

Here’s a question. Where did the “certificate” come from? This is where the CA comes in.

CA (Certificate Authority)

Two points are emphasized:

  1. There are many cas (both domestic and foreign) that can issue certificates.

  2. Only a few cas are considered authoritative and impartial, and the certificates issued by these cas are considered trustworthy by browsers. Such as VeriSign. (It’s not unheard of for CAS to forge their own certificates…)

A website submits an application to the CA. After the CA approves the application, the CA issues a certificate to the website. When the user accesses the website, the website gives the certificate to the user.

As for the details of certificates, they will also be covered later.

Problem 2: Data transmission is secure only in one direction

As mentioned above, data encrypted with the private key can be decrypted and restored with the public key. So does this mean that the data the site sends to its users is not secure?

The answer is yes!! (Three exclamation marks to indicate the third power of emphasis)

At this point, you may be thinking: if you use HTTPS, the data is still running naked, so unreliable, it is better to use HTTP directly.

But why is the industry clamoring for HTTPS? Well, that’s clearly against our sensibilities.

HTTPS uses public-key encryption, but it also combines other methods, such as symmetric encryption, to ensure the efficiency and security of authorization and encrypted transmission.

In summary, the whole process of simplified encrypted communication is as follows:

  1. When Xiao Ming visits XX, XX gives his certificate to Xiao Ming (actually to the browser, xiao Ming will not know).

  2. The browser obtains the public key A of XX from the certificate

  3. The browser generates its own symmetric key B, encrypts it with public key A, and passes it to XX.

  4. XX decrypts using the private key and obtains the symmetric key B

  5. Browser and data communication after XX are encrypted with key B

Note: The generated symmetric key B is theoretically different for each user accessing XX. For example, xiao Ming, Xiao Wang and Xiao Guang might produce B1, B2 and B3.

Refer to the following picture :(attach the source of the original picture)

Possible problems with the certificate

After understanding the process of HTTPS encrypted communication, the doubts about data streaking should be basically eliminated. However, attentive viewers may have a question: how to ensure that the certificate is valid?

There are two possible cases of an invalid certificate:

  1. The certificate was forged: it was not issued by the CA at all

  2. The certificate has been tampered with: for example, the public key of XX website has been replaced

Here’s an example:

As we know, there is a kind of thing called proxy in the world. Therefore, it is possible that Xiaoming landed on XX website above. Xiaoming’s login request first went to the proxy server, and the proxy server forwarded the request to the authorization server.

Xiaoming –> evil proxy server –> Login authorization server Xiaoming <– evil proxy server <– login authorization server

Then, there are too many bad guys in the world, and one day, the proxy server took a bad turn (or maybe was hacked) and blocked Ming’s request. At the same time, an invalid certificate was returned.

Xiaoming –> Evil proxy server — X –> Login authorization server xiaoming <– evil proxy server — X –> login authorization server

If the kind Xiao Ming believed the certificate, he would run naked again. Of course not. What mechanism, then, is there to prevent the release of such things?

Let’s take a look at what certificates are and get a rough idea of how you can prevent them.

Introduction of the certificate

Before the formal introduction to the format of the certificate, we will introduce the digital signature and abstract, and then we will give a non-in-depth introduction to the certificate.

Why is that? Because digital signature, digest is the key weapon of certificate anti-counterfeiting.

Digital signature and digest

To put it simply, “digest” is a fixed length string calculated by the hash algorithm for the transmitted content. Then, the CA’s private key is used to encrypt the digest, and the result is a “digital signature”. (The CA’s private key is mentioned here, more on that later.)

Plaintext hash > Digest > Private key encryption > Digital signature

This digital signature can only be decrypted by the CA’s public key.

Next, let’s take a look at what the mysterious “certificate” actually contains, and get a rough idea of how to prevent illegal certificates.

See this article for more information on digital signatures and abstracts.

Certificate format

OpenSSL and SSL Digital Certificates concept Post

There are a few things to focus on here:

  1. The certificate contains the name of the authority that issued the certificate – CA

  2. Digital signature of the certificate content itself (encrypted with the CA private key)

  3. Public key of the certificate holder

  4. Hash algorithm used to sign the certificate

In addition, one thing needs to be added, that is:

  1. CA itself has its own certificate, known as “root certificate”. This “root certificate” is used to prove the identity of the CA. It is essentially a common digital certificate.

  2. Browsers typically have built-in root certificates for most major authoritative cas.

Certificate format

Version Indicates the format Version of an X.509 certificate. The current value can be: 1) 0: v1 2) 1: v2 3) 2: V3 Predefined for future versions. Serial Number Specifies the unique "numeric identifier" assigned to the certificate by the CA. When a certificate is cancelled, the serial number of the certificate is actually put into a CRL issued by the CA, which is the only reason for the serial number. 3. Signature Algorithm Identifier The Signature Algorithm identifier is used to specify the Signature Algorithm used when the CA issues the certificate. Algorithm identifier Specifies the algorithm used by the CA to issue the certificate: 1) public key algorithm 2) Hash algorithm Example: sha256WithRSAEncryption Must be registered with international standards organizations (such as ISO) 4. Issuer 500 DN-distinguished Name (Issuer) of the CA that issues certificates. Including: 1) country (C) 2) Province (ST) 3) Region (L) 4) Organization (O) 5) Unit department (OU) 6) Common name (CN) 7) Email address 5. Validity Specifies the Validity period of the certificate. The value can be: 1) Validity period 2) Validity period Each time you use a certificate, check whether the certificate is within the Validity period. 6. Certificate User Name (Subject) Specifies the X.500 unique name of the certificate holder. Including: 1) country (C) 2) Province (ST) 3) Region (L) 4) Organization (O) 5) Unit department (OU) 6) Common name (CN) 7) Email address 7. Subject Public Key Info The certificate holder Public Key information field contains two important information: 1) the value of the certificate holder's Public Key 2) the algorithm identifier used by the Public Key. This identifier contains both the public key algorithm and the hash algorithm. X.509 V3 certificates are extensions to v2 in standard or plain form to enable the certificate to carry additional information. A standard extension is an extension defined by X.509 V3 that is a promising addition to V2. Anyone can register other extensions with an authority, such as ISO, that, if widely used, may become a standard extension. The Issuer Unique Identifier was added to the certificate definition in version 2. This field is used to uniquely identify the issuer's X.500 name with a one-bit string when the same X.500 name is used for multiple certification authorities. Optional. Certificate holder Unique Identifiers include x. 509 certificate definitions in version 2 of the standard. This field is used to use a one-bit string to uniquely identify the x.500 name of the certificate holder when the same X.500 name is used for multiple certificate holders. Optional. 11. The Signature Algorithm (Signature Algorithm) certificate issuing institution to the certificate of the above content of Signature Algorithm example: sha256WithRSAEncryption12. Issuer's Signature Indicates the Signature value of the certificate issuing authority on the certificateCopy the code

How to identify an illegal certificate

As mentioned above, the XX certificate contains the following:

  1. The certificate contains the name of the authority that issued the certificate – CA

  2. Digital signature of the certificate content itself (encrypted with the CA private key)

  3. Public key of the certificate holder

  4. Hash algorithm used to sign the certificate

The built-in CA root certificate contains the following key contents:

  1. CA public key (very important!!)

Ok, next for the above mentioned two kinds of illegal certificate scenarios, explain how to identify

A completely forged certificate

In this case, the certificate is simply checked:

  1. The certificate authority is forged: the browser does not recognize the certificate and considers it a dangerous certificate

  2. The certificate authority does exist. Locate the built-in CA root certificate and the CA public key based on the CA name.

  3. The CA public key is used to decrypt the summary of the forged certificate, but it cannot be solved. Considered a hazard certificate

A tampered certificate

Suppose the agent somehow obtains XX’s certificate, secretly modifies the certificate’s public key to its own, and gleefully assumes that the user is about to take the bait. But too simple:

  1. Check the certificate and locate the CA root certificate and the CA public key based on the CA name.

  2. The CA public key is used to decrypt the digital signature of the certificate and obtain the corresponding certificate abstract AA

  3. Based on the hash algorithm used to sign the certificate, the summary BB of the current certificate is calculated

  4. AA and BB are compared and found to be inconsistent –> judged to be dangerous certificate

HTTPS Handshake Process

How HTTPS ensures the security of encrypted data transmission is covered in this article, but the technical details are skipped.

And then there are two final questions:

  1. How does the site give the certificate to the user (browser)

  2. How is the symmetric key mentioned above negotiated

The above two questions are essentially what the HTTPS handshake phase does. The data transfer process of HTTPS is similar to that of HTTP, including two phases: handshake and data transfer.

  1. Handshake: Certificate delivery and key negotiation (both in plaintext)

  2. Data transfer: This phase is encrypted, using the symmetric key negotiated during the handshake phase

Author: Program Monkey CAM

Original: http://www.cnblogs.com/chyingp/p/https-introduction.html#undefined

, end,

Long press concern public number