HTTPS Popular Literacy Posts

---restore content starts---

Why HTTPS is required

HTTP is transmitted in plaintext, which means that any node in the middle of the sender and receiver can know what you're transmitting. These nodes may be routers, proxies, and so on.

For the most common example, a user logs in. User input account, password, using HTTP, as long as the proxy server to do some hands and feet will be able to get your password.

User Login--Proxy Server (tamper)--Actual license server

Encrypt the password on the sending side? Useless, although others do not know your original password is how much, but can get encrypted account password, can still log on.

How HTTPS is secure

HTTPS is actually the meaning of secure HTTP , which is the security upgrade version of HTTP. A little understanding of the network foundation of the students know that HTTP is the application layer protocol, under the HTTP protocol is the transport protocol TCP. TCP is responsible for the transmission, and HTTP defines how the data is packaged.

HTTP-to-TCP (clear text transfer)

What's the difference between HTTPS and HTTP? In fact, there is a layer of encryption layer TLS/SSLbetween HTTP and TCP.

Is Tls/ssl a horse of God?

In layman's words, TLS, SSL is a similar thing, SSL is a cryptographic suite, responsible for the HTTP data encryption. TLS is an upgraded version of SSL. Now, referring to HTTPS, cryptographic suite basically refers to TLS.

Process for transmitting encryption

Originally, the application layer sent the data directly to TCP for transmission, and now changes to the application layer to give the data to Tls/ssl, encrypt the data, and then send to TCP for transmission.

Roughly.

That's what this is about. Encrypting data and then transmitting it, rather than letting the data run in plaintext on a complex and dangerous network, ensures data security to a great extent. In this case, even if the data is intercepted by the middle node, the bad people can not understand.

How HTTPS encrypts the data

Students who understand the basics of security or cryptography should be aware of the common means of encryption. In general, encryption is classified as symmetric, asymmetric (also called public key encryption).

Symmetric encryption

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

The advantage of symmetric encryption is that the efficiency of encryption and decryption is usually high. The disadvantage is that the data sender, the data receiver need to negotiate, share the same key, and ensure that the key is not disclosed to other people. In addition, for multiple individuals with data exchange requirements, the cost of allocating and maintaining a key between 22 is largely unacceptable.

Asymmetric encryption

Asymmetric encryption means that the key (public key) used to encrypt the data is not the same as the key (the private key) used to decrypt the data.

What is a public key? In fact, it is literally the meaning--the public key, anyone can find out. Therefore, asymmetric encryption is also called Public key encryption.

Correspondingly, the private key is a non-public key, which is usually held by the administrator of the website.

Public key, private key two what's the connection?

Simply put, the data that is encrypted by the public key can only be solved by the private key. Data encrypted with the private key can only be solved by the public key.

Many students know that using the private key can solve the public key encryption data, but ignore the point, the private key encryption of data, the same can be decrypted with the public key. This is critical for understanding the entire set of encryption and authorization systems for HTTPS.

An example of asymmetric encryption

• Login User: Xiao Ming
• Authorized website: A well-known social network (hereinafter referred to as XX)

Xiaoming is a well-known social network XX users, XX for security reasons in the landing place with asymmetric encryption. Xiao Ming in the login interface to enter the account number, password, click "Login". Therefore, the browser uses the public key to encrypt the account password of xiaoming, and send the login request to XX. XX's login authorization program through the private key, the account number, password decryption, and verify through. After that, Xiao Ming's personal information (including privacy), through the private key encryption, transfer back to the browser. The browser decrypts the data through the public key and shows it to xiaoming.

• Step one: Xiaoming enters the account password---the browser is encrypted with the public key--Request sent to XX
• Step two: xx with the private key decryption, verification to get Xiao Ming social data, encrypted with the private key-browser with the public key to decrypt the data, and display.

With asymmetric encryption, can you solve the problem of data transmission security? In the preceding emphasis, the private key is encrypted, the public key can be solved, and the public key is encrypted. In other words, asymmetric encryption can only guarantee the security of one-way data transmission.

In addition, there are issues about how the public key is distributed/acquired. These two issues are discussed further below.

Public Key cryptography: two obvious issues

In front of the example of Xiao Ming landing social networking site XX, and mentioned that the simple use of public key encryption there are two more obvious problems.

1. How the public key gets
2. Data transfer only one-way security

Question one: how public keys get

How does the browser get the public key of XX? Of course, Xiao Ming can go online to check, XX can also paste the public key on their home page. However, for a non-success of the tens of thousands of social networking sites, will give users a great deal of convenience, after all, most users do not know what "public key" is something.

Issue two: Data transmission only one-way security

Mentioned earlier, the public key encryption data, only the private key can be untied, so xiaoming's account, password is safe, halfway not afraid to be intercepted.

Then there's a big problem: the private key encrypts the data, and the public key can be undone . Plus the public key is public, Xiaoming's privacy data is equivalent to the online way of a naked run. (Intermediate proxy Server to get the public key, do not hesitate to decrypt Xiaoming's data)

Here are answers to these two questions separately.

Question one: how public keys get

There are two very important concepts involved: A certificate, a CA (certificate authority).

Certificate

It can be understood as a website ID for the time being. This ID contains a lot of information, including the public key mentioned above.

In other words, when Xiao Ming, Xiao Wang, and other users to visit XX, no longer need to find the public key xx. When they visit xx, XX will send the certificate to the browser, tell them that, good, with this inside the public key to encrypt data.

Here's a question, where does the so-called "certificate" come from? This is the CA responsible for the next mentioned live.

CA (certification authority)

Emphasize two points:

1. There are many CAs that can issue certificates (both at home and abroad).
2. Only a handful of CAs are considered authoritative and impartial, and the browser is considered trustworthy by these CA-issued certificates. Like VeriSign. (CA's own forgery of the certificate is not the same thing happened ...) ）

Certificate issuance details here first, can be understood as a simple, the site to the CA submitted a request, CA audit passed, the certificate issued to the site, when users visit the site, the site will give the certificate to the user.

As for the details of the certificate, it is also mentioned later.

Issue two: Data transmission only one-way security

As mentioned above, the data encrypted with the private key can be decrypted and restored with the public key. So, does this mean that the data passed to the user by the website is not secure?

The answer is: YES!!! (three exclamation point to emphasize three parties)

See here, you may be in the mind to think: with the use of HTTPS, data or bare-Ben, so not reliable, but rather than directly with the convenience of HTTP.

But why is the industry increasingly clamoring for website HTTPS? This is obviously against our perceptual knowledge.

because: Although HTTPS uses the public key encryption, but also combines other means, such as symmetric encryption, to ensure authorization, encryption transmission efficiency, security.

In summary, the whole process of simplifying encrypted communication is:

1. Xiaoming visit Xx,xx will his certificate to Xiao Ming (actually to the browser, Xiaoming will not have perception)
2. The browser gets XX's public key A from the certificate
3. The browser generates a symmetric key B with its own, encrypted with public key A and passed to XX (in fact there is a process of negotiation, which is simplified for ease of understanding)
4. XX decryption by private key, get symmetric key B
5. Data communications after the browser and XX are encrypted with key B

Note: For each user who accesses XX, the resulting symmetric key B is theoretically different. such as Xiao Ming, Xiao Wang, small, may be generated is B1, B2, B3.

Reference: (attached original source)

What issues may exist with the certificate

After understanding the process of HTTPS encryption communication, the doubts about the data bare-Ben should be basically dispelled. However, the attentive audience may have another question: how do you make sure that the certificate is valid?

There are two possible cases of certificate illegality:

1. The certificate is bogus: It is not a CA-issued
2. The certificate has been tampered with: for example, the public key of XX website is replaced

As an example:

We know that there is a kind of thing in this world is called agent, so, the above Xiaoming Landing XX website may be such, Xiao Ming's Landing request to the proxy server, the proxy server and then forward the request to the authorization server.

Xiaoming---Evil proxy server--Landing Authorization server
Xiaoming <--Evil Proxy Server <--login Authorization server

Then, there are too many bad people in the world, one day, the proxy server moved a bad mind (also may be invaded), the request of Xiaoming intercepted. At the same time, an illegal certificate was returned.

Xiaoming---Evil Proxy Server--x--> login Authorization server
Xiaoming <--Evil Proxy Server--x--> login Authorization server

If the good xiaoming believed the certificate, then he ran naked again. Of course not, so, what is the mechanism to prevent the release of such things?

Let's take a look at what the "certificate" is, and then we can guess roughly how to prevent it.

Introduction to Certificates

In the formal introduction of the format of the certificate, first in a small advertising, popular science under the digital signature and digest, and then the certificate for non-in-depth introduction.

Why is it? Because the digital signature, digest is the certificate anti-counterfeiting very crucial weapon.

Digital signature and summary

Simply put, "abstract" is the content of the transmission, through the hash algorithm to calculate a fixed length of the string (is not associated with the article summary). The digest is then encrypted with the CA's private key, and the result of the encryption is "digital signature." (this refers to the CA's private key, which is described later)

Clear---hash------the private key is encrypted--digital signature

In combination with the above, we know that this digital signature can only be decrypted by the CA's public key.

Next, let's look at what the mysterious "certificate" actually contains, and then guess roughly how to prevent the illegal certificate.

For more information on digital signatures and summaries, refer to this article.

Certificate format

First shameless paste on a large section of content, certificate format from this Good article "OpenSSL and SSL digital certificate concept Sticker"

There are a number of things we need to focus on here:

1. The certificate contains the name of the institution that issued the certificate--CA
2. Digital signature of the certificate content itself (encrypted with CA private key)
3. Certificate Holder's public key
4. The hash algorithm used in certificate signing

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

1. The CA itself has its own certificate, and the lake is called "Root certificate". This "root certificate" is used to prove the identity of a CA, which is essentially an ordinary digital certificate.
2. Browsers typically have root certificates built into most mainstream authoritative CAs.

Certificate format

1. The certificate version number (version) version number indicates the format version of the certificate, the value can now be: 1) 0:v1 2) 1:v2 3) 2:v3 also for the future version of the predefined 2. The certificate serial number (Serial number) sequence numbers specify a unique "numeric identifier" that is assigned to the certificate by the CA. When the certificate is canceled, the serial number of the certificate is actually placed in a CRL issued by the CA, which is the only reason for the serial number. 3. The signature Algorithm identifier (Signature algorithm) Signature algorithm identifies the "signature algorithm" used to specify the certificate to be issued by the CA. The algorithm identifier is used to specify the CA-issued Certificate: 1) public key algorithm 2) The hash algorithm example:sha256withrsaencryption must be registered with the internationally renowned standards organization (e.g. ISO) 4. Issuer Name (Issuer) This field is used to identify the X.500 DN (dn-distinguished name) name of the CA that issued the certificate. Includes: 1) country (C) 2) provinces (ST) 3) region (L) 4) Organization (O) 5) organizational unit (OU) 6) Universal name (CN) 7) e-mail address 5. Validity period (validity) specifies the validity period of the certificate, including: 1) The date and time when the certificate becomes effective 2) the date and time when the certificate was invalidated each time you use a certificate, you need to check that the certificate is within the validity period. 6. The certificate user name (Subject) specifies the X.500 unique name of the certificate holder. Includes: 1) country (C) 2) provinces (ST) 3) region (L) 4) Organization (O) 5) organizational unit (OU) 6) Universal name (CN) 7) e-mail address 7. Certificate Holder Public key information (Subject public key info) The certificate holder exposes a key information field that contains two important information: 1) The value of the certificate holder's public key 2) exposes the algorithm identifier used by the key. This identifier contains the public key algorithm and the hash algorithm. 8. Extension (extension) The V3 certificate is an extension that is added to the V2 based on a standard or generic form to enable the certificate to carry additional information. Standard extensions are extensions to the V2 version, defined by the version of V3, that have broad application prospects, and anyone can register some other extensions to some authorities, such as ISO, if they are widely applied and may later become standard extensions. 9. IssuerThe unique identifier (Issuer unique Identifier) Issuer Unique identifier is added to the certificate definition in version 2nd. This field is used when the same X.500 name is used for multiple authentication agencies, and a single bit string is used to uniquely identify the issuer's X.500 name. Optional. 10. Certificate Holder Unique identifier (Subject unique Identifier) The unique identifier of the holder of the certificate is included in the 2nd edition of the standard in the certificate definition. This domain is used when the same X.500 name is used for multiple certificate holders, and a single bit string is used to uniquely identify the X.500 name of the certificate holder. Optional. 11. Signature Algorithm (Signature algorithm) certificate issuing authority for the certificate of the above content of the signature algorithm example:sha256withrsaencryption12. Signature value (Issuer ' s Signature) the certificate issuer's signature value for the above content of the certificate

How to identify illegal certificates

As mentioned above, the XX certificate contains the following content:

1. The certificate contains the name of the institution that issued the certificate--CA
2. Digital signature of the certificate content itself (encrypted with CA private key)
3. Certificate Holder's public key
4. The hash algorithm used in certificate signing

The root certificate of the browser's built-in CA contains the following key elements:

1. CA's public key (very important!!!) ）

Well, next to the two previously mentioned illegal certificate scenarios, explain how to identify

A fully forged certificate

This is a relatively simple situation and checks the certificate:

1. Certificate issued by the agency is forged: the browser does not know, directly considered a dangerous certificate
2. The certificate authority does exist, and according to the CA name, find the corresponding built-in CA root certificate and the CA's public key.
3. Using the CA's public key to decrypt the digest of the forged certificate, it is found that the solution is not available. Considered a dangerous certificate

Certificates that have been tampered with

Assume that the agent through some way, get XX certificate, and then the public key of the certificate secretly modified to their own, and then exasperate that the user will be hooked. But it's too simple:

1. Check the certificate, according to the CA name, locate the corresponding CA root certificate, and the CA's public key.
2. Using the CA's public key, the digital signature of the certificate is decrypted to obtain the corresponding Certificate Digest AA
3. Calculates the digest BB of the current certificate according to the hash algorithm used in the certificate signature.
4. Compare AA with BB, find out about inconsistencies--and determine the danger certificate

HTTPS handshake process

Above the long-winded talk about a chase, https how to ensure that the security of data encryption transmission mechanism is basically covered, too technical details are directly skipped.

Finally, there are two final questions:

1. The website is how to give the certificate to the user (browser)
2. How the symmetric key mentioned above is negotiated.

The above two problems, in fact, is the HTTPS handshake stage to do things. HTTPS's data transfer process is similar to HTTP as a whole, and contains two stages: handshake, data transfer.

1. Handshake: Certificate issued, key negotiation (this phase is clear)
2. Data transfer: This phase is encrypted, with the handshake phase negotiated by the symmetric key

Ruan Teacher's article written very good, easy to understand, interested students can see.

Attached: Overview of the operating mechanism of the SSL/TLS protocol: http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

Write it in the back.

Popular articles, some of the content is not rigorous, if there are mistakes please point out:)

---restore content ends---

HTTPS Popular Literacy Posts