通讯安全与HTTPS

通讯的安全性需求是什么？

什么是通讯的安全性？考虑通讯的几个要素：对方通过一条线路发送信息。

对方：如何判断对方身份真实性（伪装）？

信息：如何保证信息不被窃听和篡改？

防窃听，防篡改，防伪装，是总的需求。

对称加密

加密算法( 明文, 密钥K ) => 密文；  解密算法( 密文, 密钥K ) => 明文

例如：余则成（老余）和上级通讯，双方约定了秘钥K。

老余加密信息：加密算法( “我是老余”, 秘钥K ) => “D%8V#1=”

老余发送信息：“D%8V#1=”

上级接收信息：“D%8V#1=”

上级解密信息：解密算法(“D%8V#1=”, 秘钥K ) => “我是老余”

敌人窃听到”我是老余”，说明秘钥K泄漏（假设加密算法不可破解）。那么秘钥是谁泄漏的呢？秘钥K老余和上级都保存着，至少有两个泄漏点（如果地下网的N的通讯站都使用秘钥K（同一个密码本）， 则泄漏点有N个可能）。排除秘钥K的泄漏原因将十分困难，每一个干系人都会极力否认自己与秘钥泄漏有关。

敌人可以伪装老余，例如发送”请求与上级接头”这样的信息

无法容忍这种事情发生，就要在技术上做改进。

非对称加密

把单一的秘钥K分裂成两个，一个公钥G，一个私钥P

加密算法( 明文, 私钥P ) => 密文； 解密算法( 密文, 公钥G ) => 明文

或者

加密算法( 明文, 公钥G ) => 密文； 解密算法( 密文, 私钥P ) => 明文

私钥P只有老余一个人保存，公钥G由上级保存。

老余加密信息：加密算法( “我是老余”, 私钥P ) => “D%8V#1=”

老余发送信息：“D%8V#1=”

上级接收信息：“D%8V#1=”

上级解密信息：解密算法(“D%8V#1=”, 公钥G ) => “我是老余”

老余无法否认”我是老余”这条信息与自己有关（要么是老余发送的，要么是老余把私钥泄露给敌人，敌人伪装发送）

上级加密信息：加密算法( “请求接头”, 公钥G ) => “D%8V#1=”

上级发送信息：“D%8V#1=”

老余接收信息：“D%8V#1=”

老余解密信息：解密算法(“D%8V#1=”, 私钥P ) => “请求接头”

这条信息只有老余才能解密，因为老余唯一持有解密用的秘钥P。如果消息被敌人窃听，只有两个泄漏点，其它持有老余公钥G的人是无法解密的。

非对称加密具有一定改进的防伪装，防窃听功能。

秘钥分发和保管仍是安全管理难题。老余需要保管自己的私钥P和上级的公钥G，至少两把秘钥。上级需要保管自己的私钥P和老余的公钥G两把秘钥。假设老余的住宅被敌人潜入后替换了上级公钥G为敌人的公钥g（对应敌人的私钥p）。

敌人加密信息：加密算法( “请求接头”, 私钥p ) => “D%8V#1=”

敌人发送信息：“D%8V#1=”

老余接收信息：“D%8V#1=”

老余解密信息：解密算法(“D%8V#1=”, 公钥g ) => “请求接头”

老余以为公钥g是上级的（实际不是），老余认为上级要接头，就出现了危险。

数字签名

用私钥加密的数据，发送方无法否认。因为只有发送方唯一拥有私钥。签名的本质是： 信息只能由唯一的实体创建，这条信息就是这个实体的签名。私钥主要用来做数字签名。私钥做数据正文加密，没有多少优势，因为有N个人持有公钥，泄露点不好排查

数字摘要

发送方的信息，通过某种算法（哈希），把大段信息生成小段信息（类似长篇论文， 前面的小段摘要信息），然后用私钥加密。看来数字摘要肯定能属于数字签名概念。区别是，接收方可以根据数字摘要判断信息是否被篡改过。

   发送方： 加密算法（明文）=> 密文

   发送方： 哈希算法（明文）=> 明文摘要1

   发送方： 加密算法（明文摘要1， 私钥P）=> 数字摘要

   发送方： 发送密文，发送数字摘要

   接收方： 获得明文

   接收方： 哈希算法（明文）=> 明文摘要2

   接收方： 解密算法（数字摘要， 公钥G）=>明文摘要1

   接收方： 如果明文摘要1 等于 明文摘要2，则无篡改。

现实网络世界的做法。

证书认证：

Browser请求与Server通讯。Browser比较关心Server是否是钓鱼网站，搜集自己的信用卡账号和密码。Server把一个证书C（内容Server的公钥，发证机构A，颁发给域名，过期日期，数字摘要……）Server告诉Brower：我是有权威机构认证的诚信网站。Brower想，你当我傻吗，说真的就是真的，我要去调查一下。Brower在本机上找到发证机构A的公钥。目的是验证数字摘要是否合法。如果合法，说明证书C未被篡改，而且是发证机构A签名的。Brower放心了证书是真的，然后根据证书检查一下：证书过期了吗？颁发给域名是否与server一致等。

发证机构A的公钥是哪里来的？全世界就那么几十号上百号权威发证机构， 浏览器或操作系统已经预先保存了所有权威发证机构的公钥。如果浏览器被黑，这个事就挂了。虽然Browser无需存储网站的公钥，要存储发证机构的公钥。

对称秘钥协商：

Brower：随机生成对称加密的秘钥P。

Brower：加密算法（”秘钥P”， Sever的公钥）=> “D%8V#1=”

               把”秘钥P”当做被加密的明文

Server： 解密算法（” D%8V#1=”， Sever的私钥）=> 秘钥P

现在，server和browser可以用秘钥P进行对称加密会话了。每次请求，可以更换一次秘钥P，这样变来变去，黑客没有时间破解。而且，对称加密算法速度快，让业务更流畅的运行。真是一举多得。

Brower不用保存一大堆网站的公钥了，安全性多了很多。

Server要保存好自己的私钥和自己的公钥（2个字符串）。这些是从权威机构认证CA获取的，需要配置在server的电脑里。而且每年要交一些服务费给权威认证机构。