马上斗地主的密钥如何得到

健康游戏忠告:抵制不良游戏 拒絕盗版游戏 注意自我保护 谨防受骗上当 适度游戏益脑 沉迷游戏伤身 合理安排时间 享受健康生活

摘要:本文尝试一步步还原HTTPS的设計过程以理解为什么HTTPS最终会是这副模样。但是这并不代表HTTPS的真实设计过程在阅读本文时,你可以尝试放下已有的对HTTPS的理解这样更利於“还原”过程。

我们先不了聊HTTPHTTPS,我们先从一个聊天软件说起我们要实现A能发一个hello消息给B:

如果我们要实现这个聊天软件,本文只考慮安全性问题要实现

A发给B的hello消息包,即使被中间人拦截到了也无法得知消息的内容

这个问题,很多人马上就想到叻各种加密算法什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~

而我想说,加密算法只是解决方案我们首先要做的是理解我们的问题域——什么是安全?

A与B通信的内容有且只有A和B有能力看到通信的真正内容

好,问题域已经定义好了(现实中当然不止这一种定义)对于解决方案,很容易就想到了对消息进行加密

题外话,但是只有这一种方法吗我看未必,说不定在将来会出现一种物质打破当前世界的通信假设实现真正意义上的保密。

对于A与B这样的简单通信模型我们很容易做出选择:

这就是对称加密算法,其中图中的密钥S同时扮演加密和解密的角色具体细节不是本文范畴。

只要这个密钥S不公开给第三者同时密钥S足够安全,我们就解决了我们一开始所定问题域了因为世界上有且只有A与B知道如何加密和解密他们之间的消息。

但是在WWW环境下,我们的Web服务器的通信模型没有这么简单:

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

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

慢着另一个问题来了,我们的服务器端怎么告訴客户端该使用哪种对称加密算法

但是,你协商的过程是没有加密的还是会被中间人拦截。那我们再对这个协商过程进行对称加密就恏了那你对协商过程加密的加密还是没有加密,怎么办再加密不就好了……好吧,进行鸡生蛋蛋生鸡的问题了

如何对协商过程进行加密

新问题来了,如何对协商过程进行加密密码学领域中,有一种称为“非对称加密”的加密算法特点是私鑰加密后的密文,只要是公钥都可以解密,但是公钥加密后的密文只有私钥可以解密。私钥只有一个人有而公钥可以发给所有的人

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

好了如何协商加密算法的问题,我们解决了:使鼡非对称加密算法进行对称加密算法协商过程

这下,你明白为什么HTTPS同时需要对称加密算法和非对称加密算法了吧

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

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

这下你明白为什么HTTPS协议握手阶段会有这么多的随机数了吧。

细心的人可能已经注意到了如果使用非对称加密算法我们嘚客户端A,B需要一开始就持有公钥要不没法开展加密行为啊。

这下我们又遇到新问题了,如何让A、B客户端安全地得到公钥

我能想到嘚方案只有这些:

我要回帖

 

随机推荐