preface

In normal development, iOS does not touch a lot of network knowledge like the front end, usually just an AFN and basically ignore, just post,get and other we do not know. Therefore, most non-trained mobile development networks are relatively weak, and today’s note on HTTPS is expected to make this clearer.

This article is just a primer, you need to look deeper to get into the corresponding protocols to learn one by one.

The body of the

What is the HTTP

Hyper Text Transfer Protocol (HTTP) is a simple request-response Protocol that typically runs on top of TCP.

So what about TCP? It’s a pain in the ass. Below is a set of OSI model diagrams

To make up a bit of foundation, the network seven layer protocol can also be called four layers, I generally brain is

  • The application layerThe application can do HTTP is to transfer the data and header information here, based on TCP/IP
  • The transport layerTransmission over TCP (there are many other protocols on the diagram, but only one process is mentioned here)
  • The Internet layerIP – dependent addressing
  • Network interface layerThe network card and the hardware

The application layer is divided into the presentation layer and the session layer. The network interface layer is divided into the data link layer and the physical layer.

Back to HTTP

It is based on TCP/IP. It only specifies some content to be transmitted and request header information, and then transmits through TCP protocol. Finally, it addresses through IP protocol to find the corresponding network address and transmit data.

The client sends and the server receives the response, thus completing a communication. Without any encryption means, it is not secure, such as middlemen to intercept access, access to transmission and response data, early into the data leak. What to do?

To solve security problems, encryption

We use symmetric encryption, the client and the server use the same key M, the client encrypts the plaintext, the server decrypts the plaintext.

So is the problem solved?

The key is obtained by the middleman

Add a bunch of clients, one of them breaks, the middleman gets the key and then the middleman can manipulate the information as it’s being transmitted. Still no way to complete:

In this way, the middleman with the key can transmit and obtain data indefinitely, and the server and client cannot verify the authenticity of the information.

So what do we do to keep the key secure?

Symmetric encryption key transmission problem

Here, first of all, the most commonly used is AES advanced encryption standard, the need to initialize the vector, the general use of CBC mode.

  • Don’t worry about encryption if you don’t understand it, just think of all encryption as a mathematical calculation. Symmetric encryption can be thought of as a bit operationa^M^M=aSo think of the key as a large enough number.
  • Client A ^M=d, after the server obtains D, d^M obtains the data a required by the server.

The above is just for the convenience of understanding, not a real implementation, in order to have a general understanding of the unclear buddy.

Because of the security problem of symmetric encryption key, it is doomed that it is impossible for us to transmit the key in a fair and square way in the transmission. Whether the key is encrypted or in other ways, it can not guarantee the risk of being intercepted and cracked by the key in the transmission process. Therefore, asymmetric encryption is extended, also called public encryption

Asymmetric encryption

I’ve written about it before if you’re interested in it, asymmetric encryption

Just a quick overview

Asymmetric encryption requires both public and private keys, typically the server controls the private key and the client controls the public key

Generally, the public key is used to encrypt the data before transmission to the server, and the server uses the private key to decrypt the data.

The most common type of RSA, our Apple certificate series is like this, for example, the P12 file that we normally distribute down here, is the private key. In fact, in THE principle of RSA, both public and private keys can be encrypted, and the corresponding keys can be decrypted.

In OpenSSL, encryption with the public key is normal -encrypt, decryption with the public key is -decrypt, encryption with the private key is -sign, and public-verify is called differently.

The transmission process is as follows:

Here we can guarantee that the content L we transmit is unbreakable under the encryption of the public key M. But we still can’t guarantee the security of public key M. Suppose the public key M was tampered with by a middleman.

As the picture above shows, our entire process can still be attacked by a man-in-the-middle.

We’re going to continue to think about how to solve or verify that the public key that we get from the client is real or not.

How does the client distinguish the public key from the false

This problem arises because the client cannot tell whether the middleman or the server is returning the public key.

In HTTPS, the digital certificate + signature method is used to solve this problem (assuming the CA is used).

In most cases, browsers have built-in public keys from a number of third-party authentication authorities, such as VeriSign, Symantec, and GlobalSign. When authenticating a signature, users can directly decrypt the encrypted digital signature from the local third-party public key. Then the client uses the signature generation rule to generate signatures to check whether the two signatures match. If the matching authentication succeeds, the certificate fails to be obtained.

So the whole process is as follows:

The last part of the process, which some people find puzzling here:

    1. The public key of the three-party organization decrypts the encrypted signature in the digital certificate and obtains the signature data generated by the server.(This is the real signature data of the server.)
    1. The data in the purple box is obtained and signature S1 is generated based on the signature rules.
    1. Compare S and S1. If they are equal, the request is safe. If they are not equal, the request fails.

What if the middleman also goes to a third party to ask for the public key.

The middleman takes the certificate information and changes the public key, the website, the encryption method of the public key to his own. Then it decrypts the signature, changes it to its own signature and encrypts it with its own private key. And then passed to the client, at which point the client gets the certificate, gets the public key from the site, decrypts the signature, and then is it hacked again?

Here are a few problems:

  • 1. After the tripartite certification authority is changed, there will be problems on the client, because it is common sense for the authority.
  • 2. The middleman must know the signature generation rules to ensure that the client does not make mistakes when comparing the decryption of the signature.
  • 3. The signature rule requires all the basic information in the certificate to ensure the uniqueness of the signature. Therefore, it is extremely difficult.

So this situation is indeed possible, but if not their own server internal personnel can do this, must have a large number of data to support research cracking, is not necessarily successful. Third parties are often blacklisted when they are discovered, and it is extremely difficult to access large amounts of data transmitted.

HTTPS process

In the above process

  • 1.HTTPS uses asymmetric encryption to transmit the public key of the server.
  • 2. After obtaining the public key of the server, the client generates a symmetric encryption key randomly, encrypts the key using the public key of the server, and transmits the key to the server
  • 3. Finally, the server and client use the symmetric encryption key to interact with each other.

In simple terms, it’s HTTP plus a security authentication process, which is HTTPS.

  1. The client sends the supported summary algorithm scheme and random number to the server
  2. The server sends the digest algorithm and random number to the client
  3. The server sends the certificate to the client
  4. The client authenticates the server
  5. The client generates random numbers(pre-master secret)Encrypted using the public key of the server and sent to the server
  6. The server decrypts itpre-master secret(Equivalent to symmetric encryption key)
  7. Client and server computingkeys
  8. The client sends a completion signal, and the server sends a completion signal.
  9. SSLData transmission phase, data interaction.

Recently, my tutor Tian Bin laughed me to death. I decided to use my coarse drawing technology for a wave of operations and HTTPS forced binding.

One of the most important steps in some online businesses, such as online payments, is to create a trusted transaction environment that allows customers to conduct transactions with peace of mind. SSL/TLS ensures this. SSL/TLS works by binding physical information about websites and companies to encryption keys in digital documents called X.509 certificates. This is roughly the standard form of a public key certificate, a document that securely associates an encryption key with a person or organization.

supplement

For HTTPS access to the same server, it is not necessary to establish TLS handshake every time, because the server certificate, key calculation, and so on need a lot of encryption and decryption, power operation, and so on, very CPU consumption.

To solve this problem, the server maintains a structure with the session ID index that holds the temporary session key and shares it with the browser during the TLS handshake phase. When the browser reconnects to the HTTPS server, during the TLS handshake phase, it transmits its session ID, the server gets it, uses this as an index, and can get the same session key as the browser, avoiding a lot of computation.

advantages

  • Users and servers can be authenticated to ensure a certain degree of security

disadvantages

  • Time consuming and high performance consumption
  • The certificate cost
  • sslCertificate bindingip, aipCannot bind multiple domain names, addedipv4Consumption of (excerpt)
  • Encryption is limited in scope and does not work against hacking, denial of service attacks, server hijacking, etc. The credit chain system of SSL certificates is not secure and can be controlled in some countriesCA rootIn the case of man-in-the-middle attacks (excerpt)

conclusion

There are only so many things about HTTPS in general, so here is just a brief understanding of it, to record it and to make a deeper impression, because after all, we don’t use it very often. But it involves the consolidation of encryption knowledge, so the general people ask HTTPS may also want to know about the use of various encryption schemes and problems.

Remember what to write in the future…

If there is any mistake, please correct me.