1. HTTPS较HTTP优势
1. HTTP从发送端来说，发送数据是明文传输，发送过程敏感信息可能被窃取
2. HTTP从服务端来说，服务器对请求来者不拒，不会区分来源是否合法
3. 从数据传输过程来说，数据可能被修改或者替换，这就涉及“中间人攻击”问题
HTTPS=HTTP+加密+认证+完整性检查
2. HTTPS加密
加密方式：对称加密、非对称加密、数字签名、数字证书
2.1 对称加密
加密和解密使用同一个密钥，如下图所示，发送端明文数据通过key加密，接收端收到数据后通过同一把key解密
对称加密缺点：无法确保密钥传输过程不被第三方知道。如果被第三方知道，那么便可以轻松获取sender发送数据并且解密，同时也可以获取recipient返回数据并解密
2.2 非对称加密
加密和解密使用两把不同钥匙，如下图所示发送端通过pubkey加密，接收端收到数据后通过privatekey解密。非对称加密设计思路是，pubkey加密的数据只能通过privatekey解密；同样privatekey加密的数据只能通过pubkey解密。
但这样又出现问题：服务器以明文方式将pubkey发送给浏览器，若这个pubkey被第三方劫持，由于pubkey可以解析privatekey加密内容，所以从服务器返回信息不具有安全性，这只能保证从浏览器到服务器的安全性
2.3 非对称+对称加密
- 某网站拥有用于非对称加密的公钥A、私钥A’。
- 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
- 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
- 服务器拿到后用私钥A’解密得到密钥X。
- 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。
缺点：
- 某网站有用于非对称加密的公钥A、私钥A’。
- 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
- 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
- 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
- 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
- 服务器拿到后用私钥A’解密得到密钥X。
根本原因是浏览器无法确认收到的公钥是不是网站自己的
3. HTTPS认证 & HTTPS完整性检查
数字证书（CA)
数字证书可以解决针对2.3中浏览器无法确认得到公钥是正确的公钥问题
网站在使用https前，需要向CA机构申领一份数字证书，证书包含证书持有者信息、公钥信息、
server把证书传输给client，client从证书里获取公钥，证书如同身份证证明该公钥对应该网站（server端在申请ca时会填写对应域名就是对应这个网站）
证书从server传输给client端时，如何防止数字证书被篡改： 数字签名
数字签名制作过程：
1. CA机构拥有非对称加密的pubkey和privatekey
2. CA机构对证书明文T进行hash计算 (hash作用：证书明文比较长，hash后得到固定长度信息，提高加解密效率)
3.对hash(T) 使用private key进行加密计算得到数字签名S
数字签名S+证书明文数据T共同组成数字证书，这样一份数字证书就 颁给浏览器
浏览器验证过程：
1. 浏览器拿到证书，获取到数字签名S和证书明文T
2. CA机构的pubkey对数字签名S进行解密得到S'
3.对证书明文T进行hash计算得到T',理论上T'=S',通过这个可以校验证书是否被篡改
至此，校验通过后，client/server便可以通过pubkey/privatekey进行数据加密/解密进行数据传输
每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？
显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？
服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥
参考： https://zhuanlan.zhihu.com/p/43789231
