In the process of obtaining information online, the encrypted information transmission method we come into contact with the most is HTTPS. Whenever you visit a site and a green icon appears in your browser's address bar, it means that the site supports HTTPS information transmission. HTTPS is a mixture of our common HTTP protocol and an encryption protocol, that is, HTTP+S. This S can be TLS (Transport Layer Security) or SSL (Secure Socket Layer), but I prefer another abstract and general term, HTTP+Security.

First of all, HTTPS is not the official name of this encryption technology. HTTPS stands for "HTTP protocol implemented on TLS/SSL", so what implements encryption is actually the TLS/SSL layer below HTTP. .

Let’s take a look at several main mechanisms implemented by TLS/SSL:

1. Certificate: Verify and guarantee the identity of the website through a third-party authoritative certificate authority (such as VeriSign). Prevent others from forging website identities and establishing encrypted connections to unsuspecting users.

2. Key exchange: A unique session key is generated through negotiation between the website server and the user through public key (asymmetric) encryption.

3. Session encryption: Using the session key negotiated through mechanism (2), the session content is encrypted using a symmetric encryption algorithm.

4. Message verification: The message verification algorithm is used to prevent encrypted information from being tampered with during transmission.

Through the above mechanism, the content transmitted between the user and the website is protected, so it can achieve high security. However, no cryptographic method is absolutely safe, and there are actually possible risks in the above mechanisms:

1. Certificate: If someone forges a certificate, the browser will issue a warning to remind the user of the website The certificate may be fake and access should be stopped, but if you ignore the browser's warning, your session information may be stolen by the forger. In addition, if the third-party certificate authority is attacked and the attacker steals the issued certificate key, he can forge the corresponding website certificate and completely deceive the browser's security mechanism. Such examples have indeed happened before.

2. Key exchange: RSA, which is the most commonly used public key encryption algorithm and is generally very secure.

3. Session encryption: AES-256 (CBC Mode), which is a very widely used encryption algorithm. The use of a 256-bit key means that it is highly secure. If a 128-bit key is used ( AES-128) is less secure.

4. Message verification: SHA1, which is a hash algorithm. SHA1 is more secure than MD5, but if SHA256 is used, the security will be better.

The above is very abstract, isn't it? Let's use "passing notes", something that everyone did when they were children, to illustrate it vividly.

HTTP

Suppose you are sitting in the classroom now, and now you really want to say something to the charming TA next to the aisle. Usually at this time you will use "pass a note" ” way to communicate. This method is very similar to the basic working mode of the TCP/IP protocol:

Attract the other party’s attention through small movements;

The other party responds in a variety of possible ways (gaze, body language, etc.) to you;

After you confirm that the other party senses you, pass the note to the other party;

The other party reads the note;

The other party gives you the read Reaction;

How about it? Is this process familiar?

What if the person you want to deliver the note to is far away from you? The HTTP protocol means that you write on the note who you want to pass it to, or where his seat is, and then only the students who need to pass through get the note and pass the note in sequence according to the instructions on the note. That's OK.

At this time, the problem comes: the students on the route can watch and know what you wrote on the note.

This is one of the problems faced by HTTP transmission: man-in-the-middle attack, which means that during the message transmission process, attackers on the transmission path can sniff or eavesdrop on the content of the transmitted data.

HTTPS

HTTPS uses "encryption" to solve this problem. The most famous and original encryption method is the symmetric encryption algorithm, which means both parties agree on a secret code and replace what letters with which letters. Nowadays, a symmetric algorithm called AES (Advanced Encryption Algorithm) is generally used.

The symmetric encryption algorithm means that the key used for both encryption and decryption is the same.

AES mathematically guarantees that as long as the key you use is long enough, cracking is almost impossible (unless a photonic computer is built)

Let’s first assume that there is no key key, the ciphertext cannot be cracked, and then return to this classroom.

You wrote the AES-encrypted content on the note. When you were about to send it out, you suddenly thought, how can he decrypt the content without the key, or in other words, how should you give him the key?

If the key is also written on the note, the middleman can still decipher the eavesdropping note. Maybe in a real environment, you have other ways to send the key to the TA through some secure channel, but it is more difficult to implement on the Internet. After all, the data has to go through those routes no matter what.

So smart humans invented another encryption algorithm-the asymmetric encryption algorithm. This encryption algorithm generates two keys (key1 and key2). Any data encrypted by key1 cannot be decrypted by key1 itself, and key2 is required to decrypt it; any data encrypted by key2 cannot be decrypted by key2 itself, only key1 can decrypt it.

Currently there are many such algorithms, the most commonly used one is RSA. The mathematical principle it is based on is:

The product of two large prime numbers is easy to calculate, but it is very complicated to use this product to calculate which two prime numbers are multiplied. Fortunately, with the current technology, it is indeed difficult to decompose the factors of large numbers, especially when the large number is large enough (usually as large as 2 to the power of 10 binary digits), even a supercomputer will need a lot of time to decrypt it. long time.

Now let’s apply this asymmetric encryption method to the scenario of passing notes in our classroom.

You use RSA technology to generate a pair of keys k1 and k2 before writing the note content.

If you send k1 in clear text, someone may intercept it, but it will be useless. The data encrypted by k1 requires k2 to crack, and k2 is in your own hands.

When k1 is transmitted to the destination, the destination will prepare a transmission key key that will be used for symmetric encryption (AES), and then use the received k1 to encrypt the key and pass it to you.

After you use the k2 on your hand to solve the key, only you and your target person in the whole classroom have this symmetrically encrypted key, and you two can chat as much as you want without fear of eavesdropping~

You may have questions here, why not directly use asymmetric encryption to encrypt information, but instead encrypt the AES key? Because the average consumption time of asymmetric encryption and decryption is relatively long, in order to save time and improve efficiency, we usually only use it to exchange keys instead of directly transmitting data.

However, can using asymmetric encryption really prevent man-in-the-middle attacks? Although it looks very safe, it actually cannot stop nasty man-in-the-middle attacks.

Suppose you are A, your destination is B, and now you have to pass through a malicious classmate M. The malicious thing about a middleman is that it disguises itself as your target.

When you were about to complete the first key exchange with B, M withdrew the note, pretended to be B and forged a key, and then encrypted the key with the k1 you sent. Sent back to you.

You thought you had completed the key exchange with B, but in fact you had completed the key exchange with M.

Colleagues M and B complete a key exchange, making B think that they have completed the key exchange with A.

Now the overall encryption process has become A (encrypted link 1)->M (plaintext)->B (encrypted link 2). At this time, M can still know the transmission between A and B. All news.

At this time, the difference between HTTPS and note transfer is reflected. In the classroom, you are communicating with someone who is almost the same as you; when visiting a website, the other party is often a relatively large (or well-known) service provider. They have abundant resources, and perhaps they can To prove their legitimacy to you.

At this time we need to introduce a very authoritative third party, an organization specifically used to certify the legitimacy of the website, which can be called CA (Certificate Authority). Each website service provider can apply for a certificate from the CA so that they can bring the CA's signature when establishing a secure connection. The security of CA is authenticated by the operating system or browser.

Your Windows, Mac, Linux, Chrome, Safari, etc. will bring a list of CA certificates they consider safe during installation. Only websites that establish secure connections with you have the signatures of these CAs. Only the operating system and browser will consider this link to be safe, otherwise it may be subject to a man-in-the-middle attack.

Once a certificate issued by a CA is used in an illegal way, all certificates previously issued by this CA will be considered unsafe, which makes all CAs very careful when issuing certificates. , so the CA certificate is trustworthy under normal circumstances.

Just as agora.io Web SDK considers data security issues, it limits http access to the getUserMedia interface and can only access it through https. Therefore, accessing the Agora service using http in the Chrome browser (version 47 or above) fails. What should I do?

The Agora Web solution establishes audio and video communication between browsers based on WebRTC technology. In the WebRTC protocol, the browser obtains video (through the camera) and audio (through the microphone) data through the getUserMedia interface. Google Chrome is One of the mainstream browsers that supports WebRTC, in version v47 and above, considering data security issues, http access to the getUserMedia interface is restricted and can only be accessed through https. In addition to the Chrome browser, the Opera browser has also followed up on http restrictions after the v34 version. Firefox does not have this update for the time being. However, considering that https is the secure access method recommended by the WebRTC protocol, it is recommended that customers access Agora web services through https, which is also compatible with various browser platforms.