HTTP 和 HTTPS

HTTP

• 明文传输

HTTPS

• 加密传输 HTTP +TLS/SSL

HTTPS不是新的应用层协议，只是在HTTP协议上进行加密了。

HTTPS采用了对称加密和非对称加密

对称加密
传输效率比较高

只有一个秘钥，可以用来加密和解密

对称加密有风险，秘钥是服务端传给客户端的，如果秘钥在传输过程被第三方劫持了，那么对称加密就没有任何意义了。

非对称加密
传输效率比较低

有私钥和公钥，公钥用来加密，私钥用来解密
服务端有公钥和私钥，将公钥传给客户端，客户端拿到公钥生成一个随机码，用公钥给这个随机码加密，传给服务端，服务端自身是有私钥的，用私钥给这个随机码(客户端用公钥加密的)解密，拿到随机码之后，服务端用这个随机码给客户端要传输过去的信息进行对称加密，客户端拿到加密的信息之后。
由于客户端是有这个未加密的随机码的，可以用这个随机码来解密。实现对称加密。

中间人攻击
这种加密也会存在一种风险，中间人攻击，黑客可以有自己的公钥和私钥，将服务端传给客户端的公钥，替换成自己的公钥，客户端传给服务端，拦截加密的随机码，用自己的私钥来解密，可以拿到随机码了。
解决方案
利用浏览器对服务端给的公钥进行验证合法性，服务端的公钥是有第三方机构颁布的，和浏览器是有合作的，黑客的公钥是自己的，浏览器是不认可的，会弹出警告，证书不合法。

tip: 有一个问题： HTTPS 一定是安全的吗？

今天面试官问了这样的一个问题，如果黑客去CA机构到了CA证书，对你的请求进行拦截。
黑客将从CA机构拿到的公钥，替换了用户的公钥，黑客拿到了自己公钥加密的随机码，再用自己的私钥进行解密。
这样的话，用户传输的信息就不在安全了。

谷歌提出了一个解决方案，这就是证书透明度（CT）

CT 是一组技术解决方案，它能够审计、监控证书的签发、使用，从而让更透明，它不是证书的替代解决方案，而是证书的有效补充。

• C A机构能够知晓自己签发了哪些证书，可以快速的检测到是否签发恶意证书了。
• 作为网站开发者也知晓了对应证书的签发过程，一旦发现有攻击者伪造了域名对应的证书，可以快速的联系CA机构，吊销该证书。
• 浏览器器厂商能够审计证书的使用情况，发现恶意的证书，可以快速的关闭HTTPS连接，保障用户的安全。

CT 日志服务

CT 日志服务所使用的技术和区块链技术非常类似，通过密码学手段（Merkle hash tree）保证了其数据只能增长，但修改、插入、删除都会被发现。由于审计单条数据的成本并不高，审计员可以是一个单独的服务，也可以是观察者的一项功能，甚至可以作为客户端的一部分

Expect-CT

为了确保浏览器能在访问到缺少 CT 监督的证书（例如 CA 意外发出的证书）时采取措施。
Google 提案增加了一个新的 Expect-CT HTTP Header，该 HTTP Header 用来告诉浏览器期望证使用书透明度服务。

Expect-CT CT 头部允许站点选择报告或强制执行证书透明度要求，这可以防止站点证书错误被忽视的情况。当站点启用 Expect-CT CT Header 时，浏览器会检查该站点使用的证书是否出现在公共CT日志中，这能有效的避免中间人攻击等 HTTPS 威胁，让站点更加安全。

详细可以访问这个链接