HTTPS相关

http

明文传输，不安全，所以有了 https;

对称加密

用同样的密钥加密解密，无法避免中间人攻击篡改

https:

非对称加密：

公钥 & 私钥

用公钥加密的数据 只能使用私钥解密，公钥自己也无法解密 同理用私钥加密的数据 只能使用公钥解密，私钥自己也无法解密

通信过程：

服务器先将自己的公钥发送给浏览器，浏览器生成一个随机的数据，用这个服务器的公钥进行加密，再发送给服务器，服务器用自己的私钥解密。 此时双方就得到了一个同样的随机数据，这个随机数据就可以作为对称加密的密钥，对真正需要传输的数据加密传输。 这个过程中，就算攻击者拦截到了服务器的公钥也没有用，因为公钥自己也无法解密自己加密的数据。

简述：

服务器和浏览器双方 用非对称加密协商出一个相同的密钥，然后用这个密钥进行对称加密传输数据。

SSL TLS

这一套独立于 http 协议的流程，就被称为 SSL(安全套接字层) 这个密钥协商的过程被称为 SSL 握手 后续 SSL 经历了 1.0，2.0，3.0 版本的升级，更名为 TLS(也被称为 SSL3.1) 再后续又进行了 TLS 1.1, 1.2, 1.3 版本的升级，升级了一些安全细节，比如把逐渐失去安全性的 MD5/SHA-1 算法更改为 SHA-256。

问题:

问题看似被解决了，但是这里还存在一个场景： 假如攻击者劫持到了服务器的公钥，然后攻击者自己另外生成了一套公钥和私钥，将自己的公钥发送给浏览器 此时浏览器无法知道改公钥是被篡改过的，就用这个公钥加密了后续作为对称加密公钥的随机数据，攻击者收到该数据后，又使用自己的私钥解密得到明文，再用服务器的公钥对其加密，发送给服务器，服务器用自己的私钥解密。 此时虽然通信双方协商出了后续对称加密的密钥，但是攻击者也知道了，后续的加密就没有了意义。

问题的根本在于公钥无法表明自己属于谁，为了解决这个问题，就需要引入一个第三方的机构(CA)。

通信过程：

服务器将自己的公钥，组织名，域名以及所申请的第三方机构名等信息放在一起，形成一个数据集合，然后将这个数据集合发送给该机构， 该机构也有一个公私钥对，它用自己的私钥对这些数据进行加密，得到一个密文，这个密文就叫做签名，然后把签名数据和原始明文放在一起发送给服务器的管理员，这就是所谓的 TLS 证书。 现在服务器传递给浏览器的就不再是自己的公钥，而是这个能表明自己身份的证书，浏览器拿到这个证书后，会先进行验证，拿 CA 机构公开的公钥对证书中的密文进行解密， 如果解密的结果和明文中的一致，则通过验证，拿出明文中的公钥，后续流程就是走上文说过的非对称加密流程了； 如果不一致，浏览器就会弹出风险提示了。 此时攻击者如果篡改了证书中的公钥，则证书签名解密后的结果与证书明文不一致； 如果攻击者自己向 CA 机构申请了一个证书，将该证书发送给了浏览器，证书中的域名和浏览器正在访问的域名又会不一致； 原则上是解决了问题。

CA 机构

我们发现在这个过程中，CA 机构的责任和权力都很大，如何确保 CA 机构是可信任的呢？ 可信任的 CA 机构是系统或浏览器内置的，只有这些机构颁发的证书才会被浏览器信任。

但是假如这些 CA 机构颁发了错误的证书呢？或者颁发证书的工作人员…呢？

CT

这个时候就提出了一个证书透明的方案(CT) 在 CA 机构每次颁发证书的时候，都需要向一个叫日志服务的角色提交证书的详情，日志服务器将其记录，同时向 CA 返回一个 SCT 数据，CA 将 SCT 数据加入到整数的扩展中，把这个携带 SCT 信息的证书颁发给服务器的管理员，在 TLS 握手时，浏览器拿到这个附加了 SCT 信息的证书，除了前面说的验证证书本身，还要向日志服务验证 SCT，日志服务也有自己的公私钥对，浏览器通过其公开的公钥验证 SCT 签名。

看起来有点无意义的套娃，如果日志服务机构篡改或颁发错误的 SCT 呢？

答案是去中心化。

将证书的颁发记录按产生的时间依次排列，计算出每个记录的哈希值，再将相邻两个哈希组合在一起计算新的哈希值，重复该操作直到生成根节点哈希值。 此时如果有人试图将某个证书中的域名篡改成自己的，那根哈希值就会产生变化，所有人都能对这个数据进行监管。

2018 年开始，由 Chrome 和 Safari 牵头，各家浏览器开始强迫执行证书中的 CT 检查，也就是说一个不携带 SCT 信息的证书将被浏览器标注为不安全，如此所有 CA 机构便被强制加入监管体系。