HTTP过程（对称加密和非对称加密，CA，随机数生成密钥的方法）
HTTP协议运行在TCP上，明文传输，客户端和服务器之间不能相互验证身份HTTP是SSL（安全套接字层）HTTP的外壳，运行在SSL上，SSL运行在TCP上，是增加了HTTP的加密和认证机制。它们之间的区别如下：
不同的端口：HTTP和HTTP使用不同的连接方法，使用的端口也不同。前者为80，后者为443
资源消耗：与HTTP通信相比，由于加解密处理，HTTP通信消耗了更多的CPU和内存资源
开销：HTTP通信需要证书，证书通常需要从证书颁发机构购买HTTP的加密机制是一种使用共享密钥加密（SSL）和公钥加密（TLS）的混合加密机制。SSL/TLS是对称加密和非对称加密。
对称加密意味着加密和解密都使用相同的密钥。A和B通过协商确定加密算法（不同客户端和服务器之间的加密算法需要不同）和密钥。
但是有一个问题。A通过明文传输和服务器协商使用加密算法A，但是消息本身没有加密，密钥可能会泄露，所以仍然不安全。因此引入非对称加密来加密协商过程信息。
在密码学中，使用广泛的加密机制非对称加密，如图所示，在私钥加密后，只要是公钥就可以解密，反之，只有私钥加密后才能解密。私钥只有一个人拥有，公钥可以发送给所有人。
基于以上特点，我们可以得出以下结论：
（1） 公钥对所有人都开放，但私钥需要保密并存在于服务器中
（2） 从服务器到客户端（a，b…）的信息传输是不安全的：每个人都可以获得公钥
（3） 但是从客户端（a，b…）到服务器端的信息传输确实是安全的：私钥只存在于服务器端
因此，如何协商加密算法，我们解决了非对称加密算法对于对称加密算法的协商过程。客户端使用公钥对对称加密算法和密钥进行加密，服务器收到后用私钥解密。只有服务器知道客户端和客户端之间使用了什么加密算法和密钥。
让我们回顾一下HTTP通信过程
实际上，sessionkey的生成是多次协商的结果。整个过程都会有问题。在第二步中，如果web服务器发送给客户端的公钥被中间人修改，换句话说，客户端如何验证公钥的正确性需要来自数字证书颁发机构（CA）的证书（SSL）
在步骤2中，服务器向客户机发送SSL证书。SSL证书包含证书的颁发机构有效期公钥证书持有者和签名。第三方认证保证了身份的合法性，解决了公钥获取的安全性。
（数字签名摘要签名和摘要信息具有相同的含义摘要算法和哈希算法具有相同的含义）
以浏览器为例，说明整个验证过程如下：
（1） 首先，浏览器读取证书中的证书所有者有效期等信息，逐一核对
（2） 浏览器开始查找操作系统中内置的可信证书颁发机构CA，并将其与服务器发送的证书中的颁发者CA进行比较，以验证证书是否由合法机构颁发
（3） 否则，浏览器将报告错误，表明服务器发送的证书不可信。
（4） 如果找到，浏览器将从操作系统中获取颁发者Ca的公钥，然后对服务器发送的证书中的数字签名进行解密，得到摘要签名和摘要算法
（5） 浏览器使用摘要算法计算服务器发送的证书的公钥，并将计算值与证书中的摘要签名进行比较
（6） 如果比较结果一致，则证明服务器发送的证书是合法的，并且没有被模拟
（7） 在这种情况下，浏览器中的公钥可用于后续加密
小结：
申请人通过非对称加密算法（RSA）生成一对公钥和密钥，然后将所需的应用信息（**/地区域名等）与公钥一起发送给证书颁发机构（CA）
确认后，CA通过消息摘要算法（MD5，Sha）生成整个应用信息的摘要签名m，并用CA自己的私钥（数字签名）对签名m和摘要算法进行加密
浏览器从操作系统中获取CA公钥，对数字签名进行解密，获得签名和摘要算法，并使用摘要算法计算证书中包含的公钥信息。如果计算的值与摘要签名m相同，则证书中包含的公钥是正确的。
为了保证客户端和服务器之间通信过程的安全，必须使用对称加密算法。然而，在协商对称加密算法的过程中，需要使用非对称加密算法来保证安全性。但是，直接使用非对称加密的过程是不安全的，而且会有中间人篡改公钥的可能，所以客户端和服务器不会直接使用公钥，但是数字证书颁发机构颁发的证书是用来保证非对称加密过程本身的安全性的。这样，通过这些机制协商出一个对称加密算法，双方使用该算法进行加密和解密。从而解决了客户机与服务器之间的通信安全问题。
