也许,这样理解HTTPS更容易

  • 时间:
  • 浏览:50

大伙儿先不了聊HTTP,HTTPS,大伙儿先从一4个多聊天软件说起,大伙儿要实现A能发一4个多hello消息给B:

愿因大伙儿要实现一种生活聊天软件,本文只考虑安全性难题,要实现A发给B的hello消息包,即使被中间人拦截到了,也无法得知消息的内容。

要怎样做到真正的安全?

一种生活难题,好多好多 人马上就想到了各种加密算法,哪此对称加密、非对称加密、DES、RSA、XX、噼里啪啦~

而我我应该 说,加密算法好多好多 我正确处理方案,大伙儿首太难做的是理解大伙儿的难题域——哪此是安全?

所大家 的理解是:

A与B通信的内容,有且还还还后能 了A和B有能力看多通信的真正内容。

好,难题域愿因定义好了(现实中当然不止一种生活种定义)。对于正确处理方案,很容易就想到了对消息进行加密。

题外话,我希望 还还还后能 了一种生活种土办法 吗?我看不用说,说不定在将来会出現一种生活物质打破当前世界的通信假设,实现真正意义上的保密。

对于A与B原先的简单通信模型,大伙儿很容易做出确定:

这好多好多 我对称加密算法,其中图中的密钥S同去扮演加密和解密的角色。具体细节都有本文范畴。

我希望一种生活密钥S不公开给第三者,同去密钥S足够安全,大伙儿就正确处理了大伙儿一开始了所定难题域了。愿因世界上有且还还还后能 了A与B知道要怎样加密和解密大伙之间的消息。

我希望 ,在WWW环境下,大伙儿的Web服务器的通信模型太难 太难 简单:

愿因服务器端对所有的客户端通信都使用同样的对称加密算法,无异于太难 加密。那怎办呢?即能使用对称加密算法,又不公开密钥?请读者思考21秒钟。

答案是:Web服务器与每个客户端使用不同的对称加密算法:

要怎样确定对称加密算法

慢着,原先难题来了,大伙儿的服务器端为什告诉客户端该使用哪种对称加密算法?

当然是通过协商。

我希望 ,你协商的过程是太难 加密的,还是会被中间人拦截。那大伙儿再对一种生活协商过程进行对称加密就好了,那你对协商过程加密的加密还是太难 加密,怎办?去掉 密不就好了……好吧,进行鸡生蛋蛋生鸡的难题了。

要怎样对协商过程进行加密

新难题来了,要怎样对协商过程进行加密?密码学领域中,一种生活生活称为“非对称加密”的加密算法,特点是私钥加密后的密文,只好多好多 我公钥,都还还还后能 解密,我希望 公钥加密后的密文,还还还后能 了私钥还还还后能 解密。私钥还还还后能 了一4个多人有,而公钥还还还后能 发给所有的人。

我我觉得服务器端向A、B……的方向还是不安全的,我希望 为宜A、B向服务器端方向是安全的。

好了,要怎样协商加密算法的难题,大伙儿正确处理了:使用非对称加密算法进行对称加密算法协商过程。

这下,你明白为哪此HTTPS同去前要对称加密算法和非对称加密算法了吧?

协商哪此加密算法

要达到Web服务器针对每个客户端使用不同的对称加密算法,同去,大伙儿好多好多 我应该 让第三者知道一种生活对称加密算法是哪此,怎办?

使用随机数,好多好多 我使用随机数来生成对称加密算法。原先就还还还后能 做到服务器和客户端每次交互都有新的加密算法、还还还后能 了在交互的那一该才确定加密算法。

这下,你明白为哪此HTTPS协议握手阶段会有太难 多的随机数了吧。

要怎样得到公钥?

细心的人愿因愿因注意到了愿因使用非对称加密算法,大伙儿的客户端A,B前要一开始了就持有公钥,要不太难 开展加密行为啊。

这下,大伙儿又遇到新难题了,要怎样让A、B客户端安全地得到公钥?

我我应该 想到的方案还还还后能 了哪此:

方案1. 服务器端将公钥发送给每一4个多客户端

方案2. 服务器端将公钥插进一4个多远程服务器,客户端还还还后能 请求得到

大伙儿确定方案1,愿因方案2又多了一次请求,前要另外正确处理公钥的放置难题。

公钥被调包了怎办?又是一4个多鸡生蛋蛋生鸡难题?

我希望 方案1有个难题:愿因服务器端发送公钥给客户端时,被中间人调包了,怎办?

我画了张图方便理解:

显然,让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。

使用第三方机构的公钥正确处理鸡生蛋蛋生鸡难题

公钥被调包的难题出現,是愿因大伙儿的客户端无法分辨返回公钥的人到底是中间人,还是真的服务器。这我我觉得好多好多 我密码学中提的身份验证难题。

愿因我应该 来正确处理,你为什正确处理?愿因你了解过HTTPS,会知道使用数字证书来正确处理。但太难 你想过证书的本质是哪此么?请放下你对HTTPS已有的知识,所大家 尝试找到正确处理方案。

我是原先正确处理的。既然服务器前要将公钥传给客户端,一种生活过程一种生活是不安全,太难 大伙儿为哪此不对一种生活过程一种生活去掉 密一次?原先,你是使用对称加密,还是非对称加密?这下好了,我感觉又进了鸡生蛋蛋生鸡难题了。

难题的难点是愿因大伙儿确定直接将公钥传递给客户端的方案,大伙儿始终无法正确处理公钥传递被中间人调包的难题。

好多好多 ,大伙儿还还还后能 了直接将服务器的公钥传递给客户端,好多好多 我第三方机构使用它的私钥对大伙儿的公钥进行加密后,再传给客户端。客户端再使用第三方机构的公钥进行解密。

下图好多好多 我大伙儿设计的第一版“数字证书”,证书中还还还后能 了服务器交给第三方机构的公钥,我希望 一种生活公钥被第三方机构的私钥加密了:

愿因能解密,好多好多 我明一种生活公钥太难 被中间人调包。愿因愿因中间人使用所大家 的私钥加密后的东西传给客户端,客户端是无法使用第三方的公钥进行解密的。

话到此,我以为正确处理难题了。我希望 现实中HTTPS,还有一4个多数字签名的概念,我太难 理解它的设计理由。

原先,我漏掉了一4个多场景:第三方机构不愿因只我应该 一家公司制作证书,它也愿因会给中间人原先有坏心思的公司发放证书。原先的,中间人都有愿因对你的证书进行调包,客户端在一种生活情况报告下是无法分辨出是接收的太难 你的证书,还是中间人的。愿因不论中间人,还太难 你的证书,都能使用第三方机构的公钥进行解密。像下面原先:

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

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

最终愿因其它持有同一家第三方机构证书的中间人还还还后能 进行调包:

数字签名,正确处理同一机构颁发的不同证书被篡改难题

要正确处理一种生活难题,大伙儿首太难想清楚一4个多难题,辨别同一机构下不同证书的一种生活职责,大伙儿应该插进哪?

还还还后能 了插进客户端了。意思是,客户端在拿到证书后,所大家 都有能力分辨证书是与非 被篡改了。要怎样要能一种生活生活能力呢?

大伙儿从现实中找灵感。比如你是HR,你手上拿到候选人的学历证书,证书上写了持证人,颁发机构,颁发时间等等,同去证书上,还写有一4个多最重要的:证书编号!大伙儿为什鉴别这张证书是的真伪呢?我希望拿着一种生活证书编号上相关机构去查,愿因证书上的持证人与现实的一种生活候选人一致,同去证书编号要能对应上,太难 好多好多 我明一种生活证书是真实的。

大伙儿的客户端还还还后能 采用一种生活机制呢?像原先:

原先,一种生活“第三方机构”到底是在哪呢?是一4个多远端服务?不愿因吧?愿因是个远端服务,整个交互都会慢了。好多好多 ,一种生活第三方机构的验证功还还还上后能 了插进客户端的本地了。

客户端本地为什验证证书呢?

客户端本地为什验证证书呢?答案是证书一种生活就愿因告诉客户端为什验证证书的真伪。

也好多好多 我证书上写着要怎样根据证书的内容生成证书编号。客户端拿到证书后根据证书上的土办法 所大家 生成一4个多证书编号,愿因生成的证书编号与证书上的证书编号相同,太难 说明一种生活证书是真实的。

同去,为正确处理证书编号一种生活又被调包,好多好多 使用第三方的私钥进行加密。

这地方许多抽象,大伙儿来个图帮助理解:

证书的制作如图所示。证书中的“编号生成土办法 MD5”好多好多 我告诉客户端:你使用MD5对证书的内容求值就还还还后能 得到一4个多证书编号。

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

我希望 第三方机构的公钥为什跑到了客户端的机器中呢?世界上太难 多机器。

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

题外话:愿因浏览器和操作系统这道防线被破了,就没土办法 。想想当年所大家 装过的非常规XP系统,都害怕。

说到这里,想必大伙儿愿因知道上文所说的,证书好多好多 我HTTPS中数字证书,证书编号好多好多 我数字签名,而第三方机构好多好多 我指数字证书签发机构(CA)。

CA要怎样颁发数字证书给服务器端的?

当我听到一种生活难题时,我误以为,大伙儿的SERVER前要发网络请求到CA部门的服务器来拿一种生活证书。到底是我理解能力难题,还是。。

我我觉得,难题应该是CA要怎样颁发给大伙儿的网站管理员,而大伙儿的管理员又要怎样将一种生活数字证书插进大伙儿的服务器上。

大伙儿要怎样向CA申请呢?每个CA机构都大同小异,我在网上找了一4个多:

拿到证书后,大伙儿就还还还后能 将证书配置到所大家 的服务器上了。太难 要怎样配置?这是具体细节了,留给大伙儿Google了。

他说大伙儿前要挂接一下思路

大伙儿通过推算的土办法 尝试还原HTTPS的设计过程。原先,大伙儿也就明白了为哪此HTTPS比HTTP多太难 多次的交互,为哪此HTTPS的性能会差,以及找到HTTPS的性能优化点。

而中间一大堆工作都有为了让客户端与服务器端安全地协商出一4个多对称加密算法。这好多好多 我HTTPS中的SSL/TLS协议主要干的活。剩下的好多好多 我通信时双方使用一种生活对称加密算法进行加密解密。

以下是一张HTTPS协议的真实交互图(从网上copy的,忘了从哪了,愿因侵权麻烦告知):

还还还后能 用话语总结HTTPS?

答案是还还还后能 了,愿因HTTPS一种生活我我觉得太繁杂。我希望 我还是尝试使用话语来总结HTTPS:

HTTPS要使客户端与服务器端的通信过程得到安全保证,前要使用的对称加密算法,我希望 协商对称加密算法的过程,前要使用非对称加密算法来保证安全,然而直接使用非对称加密的过程一种生活好多好多 我安全,会有中间人篡改公钥的愿因性,好多好多 客户端与服务器不直接使用公钥,好多好多 我使用数字证书签发机构颁发的证书来保证非对称加密过程一种生活的安全。原先通过哪此机制协商出一4个多对称加密算法,就此双方使用该算法进行加密解密。从而正确处理了客户端与服务器端之间的通信安全难题。

好长的话语。

后记

以上是所大家 为理解HTTPS而编伟大的伟大的发明来的自圆其说的看法。顶多还还还后能 了与非 HTTPS的科普文章。如有错误,请指出,万分感谢。

太难 ,我为哪此会我我觉得以一种生活土办法 理解HTTPS会更容易呢?所大家 给出的答案是:当你所大家 为一家人做一次菜时,你就会理解妈妈天天回家吃饭的不易了。

【编辑推荐】

【责任编辑:

武晓燕

TEL:(010)684764006】



点赞 0