HTTPS

HTTP + SSL/TLS

SSL：Secure Sockets Layer 安全套接层

TLS：Transport Layer Security 传输层安全协议

HTTPS加解密流程

用户在浏览器发起HTTPS请求，默认使用服务端的443端口进行连接；
HTTPS需要使用一套CA数字证书，证书内会附带一个公钥Pub，而与之对应的私钥Private保留在服务端不公开；
服务端收到请求，返回配置好的包含公钥Pub的证书给客户端；
客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示HTTPS警告信息，如果通过则继续；
客户端生成一个用于对称加密的随机Key，并用证书内的公钥Pub进行加密，发送给服务端；
服务端收到随机Key的密文，使用与公钥Pub配对的私钥Private进行解密，得到客户端真正想发送的随机Key；
服务端使用客户端发送过来的随机Key对要传输的HTTP数据进行对称加密，将密文返回客户端；
客户端使用随机Key对称解密密文，得到HTTP数据明文；
后续HTTPS请求使用之前交换好的随机Key进行对称加解密；

对称加密：加密与解密用的是同样的密钥

非对称加密：使用一对密钥，公钥和私钥，私钥只能由一方保管，不能外泄，而公钥可以发给任何请求它的人。

对称加密 + 非对称加密的方案：

存在的问题：当服务端向客户端返回公钥A1时，中间人将其替换成自己的公钥B1，传送给浏览器，而浏览器对此并无感知，使用B1加密密钥K发送出去，又被中间人截获，中间人使用自己的私钥B2解密，得到密钥K，再使用服务端的公钥A1加密传送给服务端，完成了通信链路，而服务端和客户端毫无感知。

原因：客户端无法确认收到的公钥是不是真的是服务端发来的。

解决方案：使用公信机构，CA + 数字签名

CA机构拥有自己的一对公钥和私钥；

CA机构在颁发证书时对证书明文信息进行哈希；

将哈希值用私钥进行加签，得到数字签名；

明文数据和数字签名组成证书传递给客户端；

客户端得到证书，分解成明文部分Text和数字签名Sig1；

用CA机构的公钥进行解签，得到Sig2（由于CA机构是一种公信身份，因此在系统或浏览器中会内置CA机构的证书和公钥信息）；

用证书里声明的哈希算法对明文Text部分进行哈希得到H；

当计算得到的哈希值T与解签后的Sig2相等，表示证书可信，没有被篡改；

HTTPS 使用非对称加密+对称加密方案，兼顾性能和安全性；为了保证公钥传输过程中不被篡改，又使用了非对称加密的数字签名功能，借助CA机构和系统根证书的机制保证了HTTPS证书的公信力。