故事+图文,一次性解决你对HTTPS认证过程的所有疑惑

发布网友 发布时间：2024-09-25 20:32

我来回答

共1个回答

热心网友 时间：2024-10-03 04:30

讲解HTTPS认证原理的文章非常多，也算是做web开发的基础知识了。但是这类文章看过去都有一个特点——知识点超级多，很乱。

证书、签名、公钥、私钥、哈希、CA证书、网站证书、对称非对称加解密……一堆概念夹杂在一起，导致很多人对这块只能说个所以然，却无法做到完全理解。

这里我就用从签发证书到数据加密交互，按流程完整解释，并在其中穿插图片和问题，来完整解释这个原理。

某天，我做了一个网站，如果直接开放给所有人访问，那么就属于无证经营，每个访问我网站的人，都会收到浏览器如下的警告。

为了解决这个问题，我需要去工商局也就是证书颁发机构CA（CertificateAuthority），去获取一个证书，来证明我这个网站是安全的。

CA机构要求我提供身份证、店铺信息等一系列申请信息，整合成一个server.req的文件，提交给他。

CA机构会有专门的人进行审查，确认我的资质、合法性。审查通过后，他们就开始了证书签发工作。

1.首先，他们觉得我的网站信息太长了，不好用来做检查或者对比，于是用一个哈希算法（可以是sha256），将其变成一个固定长度的字符串，这个字符串被他们叫做摘要（Digest）。

2.接着，他们请出了CA机构中的最高领导，将这个摘要加上领导名字重新在纸上写了一遍，然而写出来时却是一串看不懂的线条。这是领导独有的写法，除了他自己，任何人都无法模仿。而且普通人也根本看不懂。

这个领导的名字叫做CA私钥。而这个看似瞎写的过程，叫做私钥签名，即对摘要重写并暗含了自己的名字，只是一般人根本看不懂罢了。

3.接着他们把我的网站信息、CA签名打包成了一个证书，颁发给我，叫我好好保管，如果有顾客问我，我就可以把这个证书拿出来给他们看。

我疑惑地问道：“你这个签名写得乱七八糟，谁也看不懂啊，顾客咋确认我这个是合法的证书？”CA证书的机构笑了笑，说：“你只管提供就好了，顾客们自有办法”。

最终整个颁发的过程如下所示：

那天，我游荡在街头，无意发现一个我很感兴趣的店，我进入了店内，却发现这家店是新开的。

如果我不确认这家店的合法性，那么很有可能进入一家黑店，被宰或者被犯罪都有可能。

此刻我必须确认这个店家的证书是CA机构签发的，还是他自己造假的证书。

而我正好认识一位和CA私钥一起出生长大的兄弟CA公钥（公私钥都是同时生成的），虽然无法模仿领导的笔迹，但是能够勉强看懂。

CA公钥确认了签名是CA私钥所写，而且能够正确解读出签名中的摘要信息。他还将其与经营证书上所有文字生成的新摘要进行比对，发现确实一致，因此他认定这是合法的证书。

上面这个过程，就叫做验签，如下所示

可是，一般能解读出签名是CA私钥所写就够了，为什么还要比对一下摘要信息呢？

因为签名公钥只能识别出这个字是私钥所写，但是私钥曾经为别人写过很多的签名。万一造假者把签名换成了其他正规店铺里抄来的签名，那怎么办？所以肯定得确认下这个签名的内容是不是和证书上所写的店铺是同一家。

上面的过程是单向认证，即客户端验证服务端。

如果商家担心碰到居心不良的顾客，那么同样可以让顾客提供类似签发过程的证书，以证明自己也是可信的顾客，这就是双向认证。

上面的店家和顾客，通过证书验证，确认了各自的身份。接着便决定互相进行快递交易。但因为路上不安全，经常有强盗或者小偷出没，如何保证快递不被盗取很重要。

顾客打算把钱（通信数据）放在一个密码箱里，然后设置好密码，再快递过去。这个密码叫做会话密钥，任何人拿到密码都能打开密码箱，所以也叫对称密钥

但是店家该怎么知道这个密码呢？

如果顾客直接把密码箱的密码快递过去，密码在路上被小偷看到了，那后面发出去的钱岂不是就能被小偷解开并拿到了？

这时候顾客想起来，当时拿到的商家经营证书里，携带了一个叫公钥的东西，通过这个东西，可以把密码箱密码变成另一串看不懂的数字，只有商家自己能够解读这个数字。

于是顾客用公钥生成了一个加密后的密码，并成功送到了店家手中。

店家拿到后，使用自己的私钥成功解读出了这个密码。接着店家和顾客就都把密码箱设置成密码，进行快递，除了店家和顾客，其他人都无法知道这个密码是多少，劫匪们也就无从下手了。

上面过程中，还有几个关键问题，这里提出，可以先自己思考，再看答案：

Q:为什么不使用非对称密钥加密传输数据，而要用对称密钥这样绕一大圈？

A:对称算法的加解密性能比非对称算法快很多，所以非对称只用于会话密钥的传输即可，只需要一次。

Q:为什么数据开始传输之后不需要再做验签，难道者中间的数据就不会再被人篡改或者替换吗？

A:不会，有3个原因保证：

1.会话密钥是会话级别，动态生成的，只有这一次连接才会用到。因此以前废弃的会话密钥不用担心被人拿去利用。

2.建立连接并传递会话密钥之前，已经通过验签确认过对方身份是可信的。

3.没有任何第三方知道会话密钥是什么。因此第三方攻击人无法用正确的会话密钥加密数据，即无法做到伪造会话密钥来欺骗接收者的目的。

Q:CA根证书可能被造假吗？例如黑客修改了用户机器中的CA证书，导致CA的公钥被替换了，后面访问了黑客所在的网址时，就会验签成功。

A:如果真的能修改的话，那么是可行的。但是操作系统基本会内置著名CA的公钥，除非黑客已经能直接触碰你的操作系统底层了，否则基本办不到。

上文的顾客就是客户端（也可以是浏览器），店家就是服务端（网站），工商局就是可信CA机构（或者某域内自己设置的颁发机构也行）。

而一些要点总结如下：

CA私钥用于签名，CA公钥用于验签

要先生成摘要，再签名。目的是为了验签后确认来源是所签的服务端。

服务端公钥用于加密，服务端私钥用于解密。

传输数据使用对称密钥进行加密和解密。

热心网友 时间：2024-10-03 04:22

讲解HTTPS认证原理的文章非常多，也算是做web开发的基础知识了。但是这类文章看过去都有一个特点——知识点超级多，很乱。

证书、签名、公钥、私钥、哈希、CA证书、网站证书、对称非对称加解密……一堆概念夹杂在一起，导致很多人对这块只能说个所以然，却无法做到完全理解。

这里我就用从签发证书到数据加密交互，按流程完整解释，并在其中穿插图片和问题，来完整解释这个原理。

某天，我做了一个网站，如果直接开放给所有人访问，那么就属于无证经营，每个访问我网站的人，都会收到浏览器如下的警告。

为了解决这个问题，我需要去工商局也就是证书颁发机构CA（CertificateAuthority），去获取一个证书，来证明我这个网站是安全的。

CA机构要求我提供身份证、店铺信息等一系列申请信息，整合成一个server.req的文件，提交给他。

CA机构会有专门的人进行审查，确认我的资质、合法性。审查通过后，他们就开始了证书签发工作。

1.首先，他们觉得我的网站信息太长了，不好用来做检查或者对比，于是用一个哈希算法（可以是sha256），将其变成一个固定长度的字符串，这个字符串被他们叫做摘要（Digest）。

2.接着，他们请出了CA机构中的最高领导，将这个摘要加上领导名字重新在纸上写了一遍，然而写出来时却是一串看不懂的线条。这是领导独有的写法，除了他自己，任何人都无法模仿。而且普通人也根本看不懂。

这个领导的名字叫做CA私钥。而这个看似瞎写的过程，叫做私钥签名，即对摘要重写并暗含了自己的名字，只是一般人根本看不懂罢了。

3.接着他们把我的网站信息、CA签名打包成了一个证书，颁发给我，叫我好好保管，如果有顾客问我，我就可以把这个证书拿出来给他们看。

我疑惑地问道：“你这个签名写得乱七八糟，谁也看不懂啊，顾客咋确认我这个是合法的证书？”CA证书的机构笑了笑，说：“你只管提供就好了，顾客们自有办法”。

最终整个颁发的过程如下所示：

那天，我游荡在街头，无意发现一个我很感兴趣的店，我进入了店内，却发现这家店是新开的。

如果我不确认这家店的合法性，那么很有可能进入一家黑店，被宰或者被犯罪都有可能。

此刻我必须确认这个店家的证书是CA机构签发的，还是他自己造假的证书。

而我正好认识一位和CA私钥一起出生长大的兄弟CA公钥（公私钥都是同时生成的），虽然无法模仿领导的笔迹，但是能够勉强看懂。

CA公钥确认了签名是CA私钥所写，而且能够正确解读出签名中的摘要信息。他还将其与经营证书上所有文字生成的新摘要进行比对，发现确实一致，因此他认定这是合法的证书。

上面这个过程，就叫做验签，如下所示

可是，一般能解读出签名是CA私钥所写就够了，为什么还要比对一下摘要信息呢？

因为签名公钥只能识别出这个字是私钥所写，但是私钥曾经为别人写过很多的签名。万一造假者把签名换成了其他正规店铺里抄来的签名，那怎么办？所以肯定得确认下这个签名的内容是不是和证书上所写的店铺是同一家。

上面的过程是单向认证，即客户端验证服务端。

如果商家担心碰到居心不良的顾客，那么同样可以让顾客提供类似签发过程的证书，以证明自己也是可信的顾客，这就是双向认证。

上面的店家和顾客，通过证书验证，确认了各自的身份。接着便决定互相进行快递交易。但因为路上不安全，经常有强盗或者小偷出没，如何保证快递不被盗取很重要。

顾客打算把钱（通信数据）放在一个密码箱里，然后设置好密码，再快递过去。这个密码叫做会话密钥，任何人拿到密码都能打开密码箱，所以也叫对称密钥

但是店家该怎么知道这个密码呢？

如果顾客直接把密码箱的密码快递过去，密码在路上被小偷看到了，那后面发出去的钱岂不是就能被小偷解开并拿到了？

这时候顾客想起来，当时拿到的商家经营证书里，携带了一个叫公钥的东西，通过这个东西，可以把密码箱密码变成另一串看不懂的数字，只有商家自己能够解读这个数字。

于是顾客用公钥生成了一个加密后的密码，并成功送到了店家手中。

店家拿到后，使用自己的私钥成功解读出了这个密码。接着店家和顾客就都把密码箱设置成密码，进行快递，除了店家和顾客，其他人都无法知道这个密码是多少，劫匪们也就无从下手了。

上面过程中，还有几个关键问题，这里提出，可以先自己思考，再看答案：

Q:为什么不使用非对称密钥加密传输数据，而要用对称密钥这样绕一大圈？

A:对称算法的加解密性能比非对称算法快很多，所以非对称只用于会话密钥的传输即可，只需要一次。

Q:为什么数据开始传输之后不需要再做验签，难道者中间的数据就不会再被人篡改或者替换吗？

A:不会，有3个原因保证：

1.会话密钥是会话级别，动态生成的，只有这一次连接才会用到。因此以前废弃的会话密钥不用担心被人拿去利用。

2.建立连接并传递会话密钥之前，已经通过验签确认过对方身份是可信的。

3.没有任何第三方知道会话密钥是什么。因此第三方攻击人无法用正确的会话密钥加密数据，即无法做到伪造会话密钥来欺骗接收者的目的。

Q:CA根证书可能被造假吗？例如黑客修改了用户机器中的CA证书，导致CA的公钥被替换了，后面访问了黑客所在的网址时，就会验签成功。

A:如果真的能修改的话，那么是可行的。但是操作系统基本会内置著名CA的公钥，除非黑客已经能直接触碰你的操作系统底层了，否则基本办不到。

上文的顾客就是客户端（也可以是浏览器），店家就是服务端（网站），工商局就是可信CA机构（或者某域内自己设置的颁发机构也行）。

而一些要点总结如下：

CA私钥用于签名，CA公钥用于验签

要先生成摘要，再签名。目的是为了验签后确认来源是所签的服务端。

服务端公钥用于加密，服务端私钥用于解密。

传输数据使用对称密钥进行加密和解密。