HTTPS加密

 

https 加密

http众所周知是明文传输的无状态的,相对而言https更加安全一些,得益于https的加密策略。 https的加密涉及了 对称加密 非对称加密以及数字签名的设计…

对称加密

由服务器端生成一份 密钥X 明文传输给浏览器端。浏览器端用密钥加密后传输给服务器端,服务器再解密。双方各持同一份密钥。

但是在这个过程万一被人拦截下密钥X 就很不安全

非对称加密

服务器持一对 公钥A 公钥B

服务器明文把公钥A发送给浏览器,浏览器传输数据时候用公钥A 去加密,服务器用私钥B 解密,暂时来看是安全的

但是如果当一种情况 公钥A 被拦截了, 服务器用私钥加密后发送数据给浏览器的时候被中间人用拦截的公钥去解密了。。 这就很不安全了

改良后的非对称加密

服务器浏览器双方各持一对公私钥匙🔑 A public A private, B public B private

然后双方互换各自的公钥,各自保存各自的私钥。 服务器把 A pub 给 浏览器, 浏览器把 B pub 给服务器。这样服务器发送数据的时候用B pub 加密,浏览器用 B private 解密,浏览器发送数据的时候用A pub 加密,服务器用 A private 解密。

挺好的,这样确实挺好 但是为什么https没采用呢,主要 因为如此操作 耗时太久

对称加密+非对称加密

服务器持有 A pub B private 一对公私钥

服务器把A pub 明文给到浏览器,浏览器生成一个随机的密钥x,浏览器传输给服务器的时候先用A pub 加密后再传输。服务器接收到后再用密钥解密,解密后拿到密钥x 。这样就又能遵循对称加密了拥有共同的一个密钥,并且没有第三方知晓。后面就可以用密钥加密解密传输了。

但是考虑一个问题,如果这个公钥A pub 又被中间人拦截了… 并且替换上了自己的假公钥 Fake pub(还有相对应的 fake private), 随后浏览器收到后生成密钥x

中间拦截人又根据自己的假密钥fake private 去解密得到了 密钥x, 随后就能用A pub 冒充网站继续传输数据了。这也太坏了。。 那么有没有什么方法可以让网站可以识别得到的公钥是不是有效的正确的呢??

ca机构证书的颁发

如果这个公钥是一个官方机构颁发的,是不是会就安全一些呢,就是ca颁发的数字证书,这个证书中包含了持有者的一些信息,域名啊 等等

那么这个证书是怎么生成的呢?

ca机构会持有公私钥

先把证书的明文内容hash处理

随后把hash的值用私钥加密

最后生成 信息明文T + 加密后的值S (这里应该叫 数字签名

浏览器怎么处理识别证书的

拿到证书后 会用公钥将数字签名S解密后生成R, 用证书提供的hash规则将明文T做hash处理,处理后生成的值理应跟 R 的值相同 这样就能证明证书有效 公钥有效

证书会被篡改吗?

其实就算可以篡改证书的明文信息,但是篡改人没有ca的私钥,他无法生成加密后的S。 这样一来 一对比 R 跟 hash后的篡改原文 肯定不一致的。

证书会被替换吗?

如果替换证书 域名一对比还是能对比出来不一致。

如何证明CA机构的公钥可靠性

操作系统,浏览器会默认装一些他们信任的《《根证书》》。这些根证书可能还会默认信赖其他机构的证书 这样一来 可能就形成了类似了 证书链一样 层层信任。 而且 如果真的如果你机器上没有某网站的信任证书 他会提醒你安装一个 证书。