HTTPS

工作流程

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

采用混合加密（对称加密和非对称加密）的方式是因为非对称加密保密性高，但CPU消耗、时间消耗大，只用在第一次连接，后面的持续的长连接采用对称加密，因为第一个连接使对称加密的密钥有保障，可以采用消耗更低的对称加密

CA颁发机构

考虑中间人攻击的情况，非对称加密的算法都是公开的，所有人都可以自己生成一对公钥私钥。

当服务端向客户端返回公钥A1的时候，中间人将其替换成自己的公钥B1传送给浏览器。

而浏览器此时一无所知，傻乎乎地使用公钥B1加密了密钥K发送出去，又被中间人截获，中间人利用自己的私钥B2解密，得到密钥K，再使用服务端的公钥A1加密传送给服务端，完成了通信链路，而服务端和客户端毫无感知。

所以通过数字签名防伪

1. CA机构拥有自己的一对公钥和私钥
2. CA机构在颁发证书时对证书明文信息进行哈希
3. 将哈希值用私钥进行加签，得到数字签名

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

1. 客户端得到证书，分解成明文部分Text和数字签名Sig1
2. 用CA机构的公钥进行解签，得到Sig2（由于CA机构是一种公信身份，因此在系统或浏览器中会内置CA机构的证书和公钥信息）
3. 用证书里声明的哈希算法对明文Text部分进行哈希得到T
4. 当自己计算得到的哈希值H与解签后的Sig2相等，表示证书可信，没有被篡改

与 HTTP 的区别

1. http是明文传输，https 则是具有安全性的 SSL 加密传输。
2. http协议的端口为80，https的端口为443
3. https 需要 SSL 证书，费用更高。同时握手阶段需要更多的数据开销，时间也更久