( I am cutting the wind, a 5-year-old child who is still learning to read and understanding this is a prodigy, a genius, I also bow )
Hello friends. Today I want to write about a topic that I used to be very vague for a long time, and it has been causing me a headache for a few days – SSL / TLS. The purpose of my article is to help those who are still confused with this concept to understand in the simplest and most pure way , and to consolidate the knowledge I have gathered.
To this end, I try to avoid using too many technical terms or academic definitions, but instead use images associated with reality. Hopefully my article can help “someone” who is crazy about SSL / TLS feel better.
If you ever wonder why there is a page, http: //, if there is a page, https: //, then how the data you send is transmitted over the internet, what kind of encryption can other parties be unable to decode? Then this article is for you!
First, I want to go over some concepts (short):
– What is SSL?
SSL is a protocol that increases security when parties communicate with each other over the internet.
(For you who “fear” from the protocol on google translation: You can understand the protocol like a rule board. Both parties understand and adhere to these rules, thereby communicating effectively with each other.)
– When does SSL use?
If you visit a website and see the url starting with https: // , then SSL is in use. The “s” in https stands for “secured”, which means it’s safer than http.
In short, SSL is used when the internet connection between parties needs to be secure.
But how to ensure safety?
Suppose there are two parties sending request response back and forth, client and server. The client is for example Chrome browser, the server is facebook for example.
If using http , the client simply sends the request and the server will return the response. Life is very light and peaceful. The client doesn’t need to know if he sent the request to the right place or not, and neither does the server. No matter how sensitive the information in the request response is.
When using https , the client will be much more cautious. The client will be aware that the request he sent can completely be blocked by another party in the middle of the road, and then stand in the middle of both pretending to be a client and pretending to be a server, and read all the correspondence between the two sides. That is very dangerous.
To avoid this situation, the client side needs a way to check if they are sending the request to the correct server or not . Or in this example is the request the client sent is correct to facebook.com or not.
To do this, every time a connection is needed, the client side will not immediately send sensitive data of any kind to the server, but will take a number of steps to ensure the correct server is then transmitting the data.
This process is called handshake , the specific steps are as follows:
(Leave this photo to prepare for the text below, hope readers won’t be bored)
Source: cloudfare.com
- First , the client sends to the server a hello message to start the handshake process. This message will contain some information, such as the version of SSL that the client supports, and a string of random bytes called the client random . Please note this sequence of bytes, its effects I will talk about below.
- When receiving a hello message from the client , the server will also send the client back a hello message. This message contains the SSL certificate of the server, and also a string of random bytes called the server random . (and some other miscellaneous things, I combed it out to save the trouble)
Here comes a new concept, it is an SSL certificate .
SSL and SSL certificates are two different things . SSL certificate, as you know, while SSL certificate is a file containing the server information such as name and address.
This certificate is like an identity card. You give your ID to someone else, that person can make sure you are you right? (Correct, right?) - Upon receiving the server’s SSL certificate , the client side will proceed to confirm if the certificate is “standard” or not. The word “standard” can be confusing, so let me explain a little more about the purpose of the server sending certificates back to the client.
As mentioned above, a certificate is like an identity card. However, the identity card also has the ID card that proves that identity. Anything can be fake, so it is not possible to immediately guarantee that the certificate server sent is standard.
To determine if the server’s certificate is valid or not, the client will need to check the certificate issuer.
Usually the issuer of the certificate is a trusted organization, and this organization will confirm for you to see if the server’s certificate is valid (standard here is that this type of certificate is actually issued to the server ” abcxyz.com “. , myself (the third party) is the issuer), like you ask the State to confirm whether the identity card of Mr. A and Mr. B is correct.
Once the third party has confirmed that the certificate is indeed the server you want, then you can trust that server and proceed to the next steps. - After seeing that the certificate is ok, the server is trusted by the client. The next step is that the two sides need to agree on an encryption way that only one of the parties can decode it .
To do this, the client sends another string of bytes to the server, called the premaster secret . This premaster secret has been encrypted using a public key.
Where do the public keys come from? It turns out that the certificate that the server sent back contains a public key already!
The client will use this public key to encrypt the premaster secret.
To decrypt this premaster secret requires a private key, and of course this private key is securely stored on the server side. Therefore, only the server can decrypt the premaster secret. - Server proceeds to decode premaster secret.
- Did you notice?
At this point, both the server and client sides have:- client random
- server random
- premaster secret.
Both sides will use these 3 keys to generate a new key, called the session key .
You can imagine the process like mixing three paint colors together.
If both sides know what the 3 colors are, they will be able to mix the same color. But deviating one color only, the result will be completely different.
This session key can be used to encrypt and decrypt as well. - The client is ready , and will send a “finish” message to the server. This message will be encrypted by… guess what? Session key!
- The server is ready , too , and will respond in response to a “finish” message encrypted by the session key.
- Handshake is complete!
From this point the server and client will communicate with each other using messages encrypted by the session key . Since this session key is generated by “mixing paint” during the handshake, it will be difficult for a third party to obtain. Therefore, the exchange of information between the server and the client is guaranteed.
Thus, by using SSL, we make sure we connect to the right objects we want, and after connecting, the packets going back and forth between the two parties are also securely encrypted.
However, there will still be a way to bypass SSL .
As we just learned, in order for the client to trust the server and perform the handshake, the client side must trust the server’s SSL certificate.
So what if the hacker wants to stand between the client and the server, catch every request from the client and pretend to be the server to return the response to the client? The hacker will still have to send an SSL certificate back to the client, but the client can immediately detect that the certificate is not “standard”, and proceed to disconnect.
However, if the hacker is able to install his certificate into the client’s system , so that the system will always trust the certificate, the client will still happily handshake. 
This is exactly how proxy software works. If you are on mac, you now understand why proxies always ask you to install the root certificate right?
To avoid bypassing by installing this root certificate we can use SSL pinning.
What is SSL pinning … see you in the next article! (I will also mention a self-signed certificate too)
Hope I can help some of you who are still vague about this SSL case can find some light. My article still has many shortcomings. We look forward to your comments for me to improve.
P / s: A little more. The title of the article includes the phrase TLS, you probably see it often and are wondering what it is. It can be understood that SSL was born before, there were many disadvantages, TLS was born later, with the same purpose as SSL, but it was better. In fact nowadays, TLS is being used more and more, SSL is slowly drifting into the past. SSL handshake is now mostly TLS handshake, however because the term SSL is popular for a long time, people continue to use this phrase.