HTTPS principle

We all know that HTTPS can encrypt information so that sensitive information cannot be obtained by third parties. Therefore, many banking websites or e-mails and other services with higher security levels will use the HTTPS protocol.

Introduction to HTTPS

HTTPS is actually composed of two parts: HTTP +  SSL  / TLS, that is, a module that processes encrypted information is added to HTTP. The information transmission between the server and the client is encrypted by TLS, so the transmitted data is encrypted data. Specifically how to encrypt, decrypt, and verify, see the figure below.

1. The client initiates an HTTPS request

This is nothing to say, that is, the user enters an https URL in the browser, and then connects to the 443 port of the server.

2. Server configuration

A server using the HTTPS protocol must have a set of digital certificates, which can be made by yourself or applied to an organization. The difference is that the certificate issued by yourself needs to be verified by the client before you can continue to access, while the certificate applied by a trusted company will not pop up a prompt page (startssl is a good choice, with a 1-year free service). This certificate is actually a pair of public key and private key. If you don’t understand the public key and private key, you can imagine it as a key and a lock, but you are the only person in the world who has this key, you can give the lock to others, and others can use this lock to lock important things Lock it and send it to you, because only you have the key, so only you can see what's locked by this lock.

3. Send the certificate

This certificate is actually the public key, but contains a lot of information, such as the certificate authority, expiration time, and so on.

4. Client Parse Certificate

This part of the work is done by the client's TLS. First, it will verify whether the public key is valid, such as the issuing authority, expiration time, etc. If an exception is found, a warning box will pop up, indicating that there is a problem with the certificate. If there is no problem with the certificate, then a random value is generated. This random value is then encrypted with the certificate. As mentioned above, lock the random value with a lock, so that unless there is a key, you cannot see the locked content.

5. Transmission of encrypted information

This part transmits the random value encrypted with the certificate. The purpose is to let the server get this random value, and then the communication between the client and the server can be encrypted and decrypted through this random value.

6. Service segment decryption information

After decrypting with the private key, the server obtains the random value (private key) sent by the client, and then encrypts the content symmetrically through this value. The so-called symmetric encryption is to mix the information and the private key together through a certain algorithm , so that unless the private key is known, the content cannot be obtained, and both the client and the server know the private key, so as long as the encryption algorithm is strong enough, The private key is complex enough, and the data is secure enough.

7. Transmission of encrypted information

This part of the information is the information encrypted by the private key of the service segment and can be restored on the client side

8. Client decryption information

The client decrypts the information sent by the service segment with the previously generated private key, and obtains the decrypted content. In the whole process, even if the third party monitors the data, there is nothing they can do.

Author: Zhu Qilin
Source: http://zhuqil.cnblogs.com 
The copyright of this article belongs to the author and the blog garden. Reprints are welcome, but this statement must be retained without the author's consent, and a link to the original text should be given in an obvious position on the article page, otherwise it will be reserved. The right to pursue legal responsibility.

 

 

 

 

Location of SSL

SSL is between the application layer and the TCP layer. The application layer data is no longer directly passed to the transport layer, but to the SSL layer, which encrypts the data received from the application layer and adds its own SSL header .

 

The performance of RSA is very low. The reason is that it takes a lot of CPU cycles to find large prime numbers, calculate large numbers, and divide data. Therefore, general HTTPS connections only use asymmetric encryption in the first handshake, and exchange symmetric encryption keys through handshakes. , after the communication goes symmetric encryption.

 

http://www.cnblogs.com/ttltry-air/archive/2012/08/20/2647898.html

 

HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,TLS/SSL中使用了非对称加密,对称加密以及HASH算法。握手过程的具体描述如下:


1.浏览器将自己支持的一套加密规则发送给网站。 
2.网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器
。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。 
3.浏览器获得网站证书之后浏览器要做以下工作: 
a) 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。 
b) 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。 
c) 使用约定好的HASH算法计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。 
4.网站接收浏览器发来的数据之后要做以下的操作: 
a) 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。 
b) 使用密码加密一段握手消息,发送给浏览器。 
5.浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密

      这里浏览器与网站互相发送加密的握手消息并验证,目的是为了保证双方都获得了一致的密码,并且可以正常的加密解密数据,为后续真正数据的传输做一次测试。另外,HTTPS一般使用的加密与HASH算法如下:


      Asymmetric encryption algorithm: RSA, DSA/DSS 
      Symmetric encryption algorithm: AES, RC4, 3DES 
      HASH algorithm: MD5, SHA1, SHA256

 

 

Summarize:

Server uses RSA to generate public and private keys

Put the public key in the certificate and send it to the client, and save the private key by yourself

The client first checks the validity of the certificate with an authoritative server. If the certificate is valid, the client generates a random number, which is used as the communication key. We call it a symmetric key, and encrypt this random number with the public key. number and send it to the server

The server decrypts the key to obtain the symmetric key, and then the two parties encrypt and decrypt the communication using the symmetric key.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327054200&siteId=291194637