https加密&认证过程详解

一、https加密过程：

首先我们要知道对称加密和非对称加密

1.1 对称/非对称加密

• 对称加密：加密和解密使用同一个密钥。
• 非对称加密：加密和解密不是使用同一个密钥，密钥成对出现。公钥加密的数据只能由私钥解密，私钥加密的数据只能由公钥解密。

1.2 加密过程

1. 首先是非对称加密：服务器生成公私钥，然后将公钥发送给浏览器。浏览器生成一段随机数据并使用公钥加密后发送给服务器。服务器使用私钥解密后获得这个随机数据。
2. 然后是对称加密：浏览器和服务器都拥有这段随机数据（对称密钥），之后的数据都使用这个密钥进行加密传输。

这样的话，就算在公钥的传输过程中，攻击者获得了公钥，由于没有私钥也无法解密。看起来是安全的了。

1.3 公钥被替换的风险

但是，假如在服务器发送公钥给浏览器的时候，公钥被拦截且被攻击者替换成了自己的公钥然后发送给浏览器。浏览器使用攻击者的公钥加密生成的随机数据然后发送给服务器。攻击者拦截到这段数据然后使用自己的私钥解密得到了明文(对称密钥)。

然后使用最开始的服务器公钥对这段明文进行加密，返回给服务器。这样攻击者也得到了对称密钥，后续的加密也就毫无意义。攻击者就像一个黑中介一样两头骗。

问题的关键就在于：传输的公钥并不能表明自己的身份，不知道他是服务器公钥还是攻击者公钥。

1.4 CA机构和TLS证书

然后可以引入公钥的加密和认证机制，从而防止公钥被篡改。

这里有一个CA机构，它有一对公私钥。服务器端需要将自己的公钥，域名，机构等数据集合信息发送给CA机构，然后CA机构使用自己的私钥进行加密(数据的哈希值进行加密)得到签名。然后将这段明文信息和签名放在一起发送给申请者，这就是TLS证书。

1.5 基于TLS证书的https

1.5.1 认证过程

1. 服务器将申请的TLS证书发送给浏览器，浏览器使用CA机构公开的公钥对TSL证书签名进行解密。如果解密结果和TLS证书明文部分一致则通过认证。
2. 浏览器提取TLS证书公钥部分，并生成一段随机数据，加密后发送给服务器。服务器使用私钥解密得到明文，后续使用它进行对称加密。

1.5.2 CA机构的职责

如果攻击者窃取到TLS证书，然后将公钥部分修改为自己的公钥，那么浏览器那边解密后的明文和证书明文将不一致，从而拒绝访问。

如果攻击者自己也去CA机构申请了证书，然后将拦截到的证书替换成自己的证书发送给浏览器，这样浏览器解密后的明文和证书明文确实一致，但是浏览器访问地址和证书域名对不上，从而拒绝访问。

可以看出CA机构是非常关键的，如果CA机构错误的签发了一张和域名和机构信息都是被攻击站点，但公钥是攻击者的TLS证书，那么浏览器就无法识破其中的玄机。数据传输也就不安全了。

1.6 kubernetes内部https双向认证过程

这里贴下链接：K8s集群https认证过程