typora-root-url: img
typora-copy-images-to: img
Copy the code

Think HTTPS from a design perspective

After we understand the content of HTTP protocol, we understand that HTTP has many security risks, so we later launched the security protocol -HTTPS, we might as well stand in the design perspective to design a secure HTTP connection protocol, see what problems exist in HTTP, how can we design to ensure security. To understand HTTPS security protocol is how to ensure HTTP securityCopy the code

First we need to think about what we need to secure in order to achieve HTTPS’s so-called security:

1. First, we need to ensure that the messages sent between the server and client are secure

2. Second, we must ensure that the connection between the server and the client is secure

3. Finally, we need to ensure that the server will not be connected by other forged clients, and through this way to break the encryption mode

Security of server/client information interaction

First of all, let’s consider how to ensure that the client sends the message to the server and the server returns the result. The process is as follows:

At this time we first think of the scheme – encryption, we use encryption algorithm to encrypt the data is not on the line, so what encryption algorithm to choose? The most common encryption algorithms in the development process are as follows: MD5, SHA1 algorithm or the symmetrical encryption algorithm aes, des, or rsa asymmetric algorithms, each of which can look for data encryption transmission, but we don’t forget that the third point we want to ensure that other client connection won’t crack the encryption mode, to know on the Internet, Is not just a client and a server interaction, can have countless clients interact with the server at the same time, this time if we want to prevent other client cracking encryption, looks the algorithm the irreversible just right, but we don’t forget, a client interact with the server needs to be done, So this encryption is not reversible algorithm, otherwise the client can’t to deal with the server-side data, the server cannot handle the client data, then only is symmetric or asymmetric encryption algorithm encryption algorithm can meet the, we continue to think, if there are more than one client to connect server at the same time, the following figure:

So it seems that either encryption will work, which raises the question, what if a hacker (malicious machine) intercepts our request and acts as an intermediary, are our two encryption algorithms safe? The diagram below:

As you can see, our client and the server is unknown malicious machine intercept forwarding the request, then we before encryption if the key is the encryption method directly and, if it is symmetric encryption then end, for intermediate machine, still can decrypt the client and server’s news, for hackers is transparent, Security is only a little bit better than no encryption, not at all can be called a trusted security protocol, but using asymmetric encryption? We all know asymmetric encryption is a bunch of keys, each side holds its own private key, public public key, public key encryption USES only the private key can decrypt, interception, so that even if have intermediate machine only can get the client and the server’s public key, but we don’t forget that the client should be hold the server’s public key, transmitted to the server is encrypted with the public key, Server private key decryption, the response process is that the private key of the client decrypts the client public key held by the server. Even if the intermediate machine intercepts the public key of both sides, it cannot decrypt the information encrypted by the public key of both sides. In this way, the problem of data transmission security between the client and the server seems to be perfectly solved

New risk – Public key transfer mode

We have just compared the use of public-private key asymmetric encryption as a client-server transmission of encryption, it seems that we should be safe, but is this really the case? In fact, the same as symmetric encryption, asymmetric encryption such a direct transmission of encryption, but only a little bit of security, if the hacker intercepts the client request, will pass their own public key to the server and the client, and the client/server public key hold what will happen? Yes, it would be horrible to imagine that the intermediate machine would have the ability to decrypt double-ended messages! Why is that? Imagine if the client encrypts the message using the so-called server’s public key, sends it, and then the message is intercepted by the intermediate machine. The so-called server’s public key belongs to the intermediate machine, and the private key can be decrypted to retrieve the plaintext message. Then, it disguises the encryption with the intercepted real public key of the client and forwards it to the server. Similarly, the so-called client-side public key encryption of the server is completely useless to the intermediate machine. How to solve this problem? Can we change a public key transmission mode to avoid interception by intermediate machines as far as possible to ensure security?

There are two possible ways to transfer a public key:

1. The server sends the public key to each connected client

2. Store the public key in a place (such as an independent server or file system). When the client needs to obtain the public key, it can access the public key in this place to match the public key with the server

The first scheme, the one we just overturned, obviously has the potential to be intercepted, so it seems we can only use the second scheme to transfer the public key? So we can not help but have a question, that is, how does the client know the address of the remote server where the public key is stored and the authentication and encryption mode, and every time the connection is established, it has to obtain the address once, which also has a certain test to the server’s ability to withstand pressure? And how to ensure that hackers and other malicious access users can not get public keys through this way, so security is also a more troublesome problem

Introduce a third-party CA organization

Due to the above mentioned problem, so for the individual, if in the development of web sites at the same time, have to spend a lot of money and energy on the development of public service, it is not reasonable, so do you have any special to do this, we managed to help us to complete the company, only need to pay the cost of money can experience the service can’t? So responsible for third-party CA certificate authentication institutions emerged, we only need to apply the corresponding server information, and submit the corresponding data, pay remuneration to, the CA will provide us with the corresponding service client authentication service, greatly reduce our operation and complexity, but this time we can’t help but have a problem again, Can the CA ensure that only clients obtain the certificate and pass the authentication, and intercept abnormal clients? If not, wouldn’t hackers be able to get certified? Now the question is how do you authenticate the user

Verifying certificate Validity

Actually want to solve the problems of the certification, we can find some inspiration from life, we all have a unique id, proving identity, so that identify the id and the corresponding person, also can identify criminals, so, now that the computer comes from life, design out of things should also follow the normal logic, Why don’t we give each certificate a unique id like number? Of course the computer is dead and there is no way to simply bind the machine to the certificate number, so you need to design a logical certificate verification process. Let’s think about how we develop software in order to identify software that has been tampered with, believing that a word pops up in our head, MD5/SHA1? Yes, so can our certification be designed in accordance with this idea?

Now we assume that, after the client to get the certificate, to be able to get a public key from the certificate information, certificate signature hash and the period of validity, that is to say, the certificates of built-in calculated the whole signature hash value, if this time we according to the client’s signature of the signature algorithm is a calculation, and the default certificate to calculate good hash comparison, found inconsistencies, If the certificate is the same, it means that the certificate is real and has not been tampered with. We can try to connect to the server, because the certificate has been obtained and the public key has been obtained. The following is the process of encrypted communication

At this point, it seems that a secure encryption HTTPS crude design, also seems to solve these security problems, but we have to mention that there is a very important point above, that is, the storage of the certificate server must ensure security, the third party is not absolutely safe? The answer is no, because in the history of HTTPS, third-party organizations have been successfully hacked using legitimate certificates. It can only be said that there is no absolute security in the computer world, but relatively speaking, security has been improved too much

HTTPS Authentication Process

We have designed a simple version of HTTPS, so let’s take a look at the general process of certificatinghttps. First, we can apply for a certificate:

As you can see, to apply for the certificate, you need to provide a lot of content, including the domain name, signature hash algorithm, encryption algorithm is one of the most important, generated through the calculation of the three certificates and determine the encrypted authentication algorithm, and in the process also need to provide the service side own public key, is used to generate a certificate, the CA mechanism using your private key encryption certificate, Generate a certificate and pass it to the server

2. After receiving the certificate request, the client TCP three-way handshake connection (which carries a random client-random number), and the server transmits the certificate information (including the expiration time, signature algorithm, hash signature of the current certificate, the server public key, and certificate authority) to the client. And pass a random number

3. After the client receives the certificate, use the browser’s built-in CA certification, for the certificate issuing authority/check step by step, one by one to determine normal certificate of source, and the calibration certificate expiration time, determine whether or not available, according to the certificate of signature algorithm, calculate the corresponding signature hash, and certificate the built-in hash signature comparison, determine if it’s not tamper with the certificate, After the certificate is fully authenticated, the certificate authentication is complete

4. The client generates a random symmetric key (pre-master), encrypts the two-end random number combination with the public key of the certificate (the public key of the server), and sends the key to the server. After receiving the certificate, the server authenticates the random number combination to carry out HTTP communication

Note that HTTPS uses the signature algorithm (MD5/SHA256), symmetric encryption, and asymmetric encryption to complete the entire interaction. During the authentication, only the signature algorithm and asymmetric encryption are used to ensure the security and stability of the channel. A sessionID is maintained to prevent frequent channel creation from consuming a lot of resources and ensure channel long-term connection reuse as far as possible. Moreover, we need to know that asymmetric encryption is safe, but compared with symmetric encryption, the encryption and decryption steps are complex, resulting in a longer time. Therefore, after establishing HTTPS channels, Symmetric encryption will be used to complete the subsequent data interaction, and the random symmetric key combination of the two parties mentioned above is used in the process of the first interaction after establishing the connection. Random + sever. Random + pre-master are combined to encrypt the handshake with the public key, and the handshake message is sent to the server to confirm whether the handshake process is tampered according to the hash algorithm of the certificate signature. After the verification, After confirming that the current connection is secure, the two ends use the agreed symmetric encryption algorithm to encrypt, decrypt, and transmit data. Then a complete HTTPS protocol is completed

Related video

Android programmers in advanced learning /OkHttp principle analysis