it_worker365

   ::  ::  ::  ::  :: 管理

https://www.cnblogs.com/zhangshitong/p/6478721.html

HTTPS要使客户端与服务器端的通信过程得到安全保证,必须使用的对称加密算法,但是协商对称加密算法的过程,需要使用非对称加密算法来保证安全,然而直接使用非对称加密的过程本身也不安全,会有中间人篡改公钥的可能性,所以客户端与服务器不直接使用公钥,而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法,就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

上面的文章非常好,取自上文

A -> B 通信:直接方式会被拦截篡改等,不安全

 对称加密算法S服务于客户端和服务端

 对称加密算法S服务于客户端和服务端

 对称加密算法A/B...服务于不同的客户端和服务端

 服务端针对不通的客户端有不通的加密算法,通过协商告诉客户端使用何种加密算法,但协商过程会产生鸡生蛋蛋生鸡的问题

解决上面的问题,需要非对称加密,私钥加密的内容,公钥可以解密,公钥加密的东西,私钥可以解密,私钥私有,公钥发送给所有发送人

虽然服务器端向A、B……的方向还是不安全的,但是至少A、B向服务器端方向是安全的。

要达到Web服务器针对每个客户端使用不同的对称加密算法,同时,我们也不能让第三者知道这个对称加密算法是什么,怎么办?

使用随机数,就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法

 如果需要每个客户端都保存公钥,则需要客户端获取公钥,在获取过程中当有中间第三者篡改如下图:

使用数字证书来解决上面的问题

所以,我们不能直接将服务器的公钥传递给客户端,而是第三方机构使用它的私钥对我们的公钥进行加密后,再传给客户端。客户端再使用第三方机构的公钥进行解密。

下图就是我们设计的第一版“数字证书”,证书中只有服务器交给第三方机构的公钥,而且这个公钥被第三方机构的私钥加密了:

182017-2-20-292372-f3dd4b7370df950e

如果能解密,就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端,客户端是无法使用第三方的公钥进行解密的。

192017-2-20-292372-3b7c21b3525c0e64

第三方机构不可能只给你一家公司制作证书,它也可能会给中间人这样有坏心思的公司发放证书。这样的,中间人就有机会对你的证书进行调包,客户端在这种情况下是无法分辨出是接收的是你的证书,还是中间人的。因为不论中间人,还是你的证书,都能使用第三方机构的公钥进行解密。像下面这样:

第三方机构向多家公司颁发证书的情况:

202017-2-20-292372-66e00dc26cea3112

客户端能解密同一家第三机构颁发的所有证书:

212017-2-20-292372-5bf2c898914e749f

最终导致其它持有同一家第三方机构证书的中间人可以进行调包:

222017-2-20-292372-b2bd3805bc25fd2c

辨别同一机构下不同证书的这个职责,我们应该放在哪?

客户端在拿到证书后,自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢?

我们从现实中找灵感。比如你是HR,你手上拿到候选人的学历证书,证书上写了持证人,颁发机构,颁发时间等等,同时证书上,还写有一个最重要的:证书编号!我们怎么鉴别这张证书是的真伪呢?只要拿着这个证书编号上相关机构去查,如果证书上的持证人与现实的这个候选人一致,同时证书编号也能对应上,那么就说明这个证书是真实的。

我们的客户端能不能采用这个机制呢?像这样:

232017-2-20-292372-ac2b0d452a4e8b05

可是,这个“第三方机构”到底是在哪呢?是一个远端服务?不可能吧?如果是个远端服务,整个交互都会慢了。所以,这个第三方机构的验证功能只能放在客户端的本地了。

客户端本地怎么验证证书呢?答案是证书本身就已经告诉客户端怎么验证证书的真伪。

也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号,如果生成的证书编号与证书上的证书编号相同,那么说明这个证书是真实的。

同时,为避免证书编号本身又被调包,所以使用第三方的私钥进行加密。

这地方有些抽象,我们来个图帮助理解:

证书的制作如图所示。证书中的“编号生成方法MD5”就是告诉客户端:你使用MD5对证书的内容求值就可以得到一个证书编号。

242017-2-20-292372-60fd73c3f79e8641

当客户端拿到证书后,开始对证书中的内容进行验证,如果客户端计算出来的证书编号与证书中的证书编号相同,则验证通过:

252017-2-20-292372-4dbf41053fb6fb25

但是第三方机构的公钥怎么跑到了客户端的机器中呢?世界上这么多机器。

其实呢,现实中,浏览器和操作系统都会维护一个权威的第三方机构列表(包括它们的公钥)。因为客户端接收到的证书中会写有颁发机构,客户端就根据这个颁发机构的值在本地找相应的公钥。

说到这里,想必大家已经知道上文所说的,证书就是HTTPS中数字证书,证书编号就是数字签名,而第三方机构就是指数字证书签发机构(CA)。

 

CA如何颁发给我们的网站管理员,而我们的管理员又如何将这个数字证书放到我们的服务器上。

我们如何向CA申请呢?每个CA机构都大同小异,我在网上找了一个:

262017-2-20-292372-6eb448d41e6bc2fb

拿到证书后,我们就可以将证书配置到自己的服务器上了。那么如何配置?这是具体细节了,留给大家google了。

 

posted on 2018-08-06 12:24  it_worker365  阅读(311)  评论(0编辑  收藏  举报