Learn HTTPS by looking at the picture
preamble
When I talked about HTTPS before, my concept was that it was more secure and required the server to be configured with a certificate, but there was no concrete idea in my head of what exactly HTTPS was, why it was more secure, and how the whole process was implemented. So, I spent a few days learning the implementation of the whole set of HTTPS mechanisms by referring to some articles, and wanted to summarize what I learned in an article so that more students who were previously unsure of what HTTPS actually is would have an introductory understanding.
Many of the articles I've read explain it through a lot of text and protocol diagrams, but it tends to get a bit boring, in this article I'll be illustrating the evolution from HTTP to HTTPS graphically through a flowchart so that you can understand it a bit more easily. Of course, this is just the introductory level, if you want to learn more in-depth knowledge of HTTPS, you still have to dive into one protocol after another and read some big parts to achieve full understanding.
This article will also be synced to my personal website.
What does HTTP look like?
HTTP is an application layer protocol, which is based on TCP/IP, so it simply specifies some content to be transmitted, along with header information, which is then transmitted over the TCP protocol, relying on the IP protocol for addressing, as depicted by the simplest diagram.
The client makes the request and the server responds, it's that simple. There is nothing encrypted throughout the process, so it is insecure and a man-in-the-middle can intercept and access the data transmitted and responded to, causing a data breach.
How about a cipher?
Since the data in the above figure is transmitted in clear text, the simplest way we can think of to improve security is to encrypt the data before transmission, as follows.
This type of encryption is called. symmetric encryption . An encryption method in which the same secret key is used for encryption and decryption is called symmetric encryption.
Okay, we've encrypted the data. Problem solved?
What about multiple clients?
This is one client, but on the WWW, it's thousands of clients, what happens?
Applying the same secret key A for all clients is clearly unreasonable in this way; crack one user and all user information will be stolen.
Think about it, is there another way?
I'm sure we can all think of whether the problem would be solved if a different secret key was used for each client to transmit.
How is the symmetric encryption secret key transmitted?
We apply a different symmetric encryption secret key to each client, so how is this secret key known to the client or server, it can only be generated at one end and then transmitted via HTTP to the other end:.
So how is this process of transmitting the secret key, and how is encryption guaranteed? If intercepted by an intermediary, the secret key can also be accessed. Perhaps you'll say, encrypting the secret key again, and how does that ensure that the process of encrypting the secret key, is encrypted?
It's like we've walked intowhile(1) It's not coming out.
asymmetric encryption
(located) at symmetric encryption It's not going to work.， Let's think differently.， There is also an encryption method called asymmetric encryption， for exampleRSA。
asymmetric encryption There will be a pair of secret keys： public key harmony private key。 public key Encrypted content， only private key It can be unlocked.， private key Encrypted content， all public key All can be unlocked（ Of course. harmony The secret keys come in pairs. public key）。
The private key is only stored on the server side, and the public key can be sent to all clients.
in transmission public key during the course of， There's definitely a risk of the middleman getting access too， But in the current situation， At the very least, the client is guaranteed to pass public key Encrypted content， The middleman is unbreakable.， owing to private key Only saved on the server side， only private key It can be cracked. public key Encrypted content。
Now we also have the problem of what if the public key is tampered with by a man in the middle.
MITM：Man-in-the-MiddleAttack
The client gets the public key It's a fake.， How to solve this problem？
Third Party Certification
public key hacked， It is because the client cannot distinguish between the incoming public key It's the middleman, after all.， Or the server.， This is also an authentication problem in cryptography。
In HTTPS, the use of Certificate + Digital Signatureto solve this problem.
Here it is assumed that the encryption method is MD5, which encrypts the information of the website and then encrypts it again through the private key of a third party organization to generate a digital signature.
Digital certificate = website information + digital signature
If the man-in-the-middle intercepts and replaces the server's public key with its own, the presence of a digital signature will cause the client to verify that the signature does not match, which prevents the man-in-the-middle from replacing the public key.
After installation, the browser will have built-in public keys of some authoritative third-party certification bodies, such as VeriSign, Symantec and GlobalSign, etc. When verifying the signature, it will directly get the public key of the corresponding third-party body from the local, decrypt the encrypted digital signature of the private key to get the real signature, and then the client will use the signature generation rules to generate the signature to see if the two signatures match, and if they match, the certification will be passed, and if they do not match, the certificate will be obtained and failed.
Why do you need a signature?
You can think about why there is such a thing as a digital signature.
The third party certification body is an open platform, we can apply and so can the middleman.
If there is no signature and only third-party institutional private key encryption is applied to the website information, the following problems exist.
Because there is no authentication, the middleman also applies to a third-party authentication authority and then intercepts and replaces all the information with its own, which the client can still decrypt and cannot tell if it is the server's or the middleman's, which ends up causing data leakage.
symmetric encryption
After safely getting the server's public key later， The client will generate a random symmetric secret key， Use of servers public key encrypted， Transferring to the server， thereafter， pertinentApplication DataThen encryption/decryption is performed by this randomly generated symmetric secret key, and the server decrypts/encrypts by that symmetric secret key.
Overall flow chart
There are many more specifics in HTTPS, and a reference can be made by the following diagram.
conclude
HTTPS That is, usingSSL/TLS Protocol for encrypted transmission， Let the client get the server's public key， The client then generates a random symmetric encryption the secret key， use public key encrypted， Transferring to the server， All subsequent messages are encrypted and decrypted by this symmetric secret key， Complete the entireHTTPS process。
Reference Articles
https://en.wikipedia.org/wiki/HTTPS
https://www.instantssl.com/https-tutorials/what-is-https.html
https://tasaid.com/blog/20161003001126.html
https://www.west.cn/faq/list.asp?unid=1346
https://www.cnblogs.com/zhangshitong/p/6478721.html
https://www.wired.com/2016/04/hacker-lexicon-what-is-https-encryption/
The Hangzhou tournament will start soon, June 2, waiting for you to meet!
Recommended>>
1、What data from the voting results of the 2016 US election is worth analyzing
2、frp intranet penetration application 1 accessing web services placed on the intranet through an external ip
3、Introduction to ECMAScript 6
4、What can you do with frontend technology in the era of frontend after frontend and backend separation
5、How to install OpenLDAP on a server