HTTPS从入门到弃疗（1）

最近在看HTTPS，觉得有一些东西需要系统化一下，这个博客系列打算分成以下几部分：
1. 常识：对称加密和非对称加密
2. HTTPS的细节
3. RSA算法的细节、证明、实例

这一篇谈谈基础的一些加密通信的常识。

对称加密

在通信中，双方的加密规则是相同的，即用同一种加密方法和同一个密钥来解析数据。
这样的做法存在的很大的问题是：怎么让对方知道自己的加密规则？

走路过去跟对方说悄悄话？（那不用干活了……）
给密钥加密，再发送过去？（那你要用什么可靠的方法来给密钥加密？）
如果郁于对称加密，就会陷入了“鸡生蛋，蛋生鸡”的循环论证了……
此路不通。

如何解决“分发密钥给接收数据的一方的”这个问题呢？
其实解决问题最好的方法就是——不要这样做。
如果双方可以拥有不同的密钥，然后有一份是公开的，大家都知道，那接收数据的一方自然也知道，就不存在“分发密钥”的问题了！

不对称加密

秘钥分为公私两份，公钥是公开的，私钥只被自己拥有（当然，自己泄露了，那就是自己的锅了）。

不对称加密方法的基本约束（个人总结）为：

1. 私钥和公钥是数学相关的，但是只知道公钥，是几乎不可能推导出私钥的；
2. 一份数据经过公钥加密，只能用私钥解密；
3. 一份数据经过私钥加密，可以用公钥解密。

顺便提一下，第二点可以用来加密传输数据，因为用一个大家都知道的密钥加密，但只有私钥拥有者才能解密，所以是安全的。

第三点可以用来做数字签名，大家都知道，签名代表了经过某个人的保证，顾名思义，数字签名就是这份被加密过的数据可以被认为是属于私钥拥有者发出来的，因为大家可以用公钥来检验。怎么检验呢？

数字签名一般是这样生成的：数据使用哈希算法生成一个固定长度的概要（比如MD5的长度是128位（二进制）的），然后用自己的私钥对这个哈希值进行加密，就得到了数字签名。

当然啦，你在给别人的时候，肯定要告诉对方，自己用的是哪一种哈希算法，比如一个最简单的数字签名可以是这样的：

<Hash Method>MD5</Hash Method>
<Signature>ED076287532E86365E841E92BFC50D8C</Signature>
<Data>Hello World!</Data>

然后当Alice发给Bob这样的一份东西时，Bob怎么检验到底是不是真正的Alice发过来的呢？

Bob先把数据按照指定的哈希算法给哈希一下，然后再用Alice的公钥解密签名中的Signature项，将解密出来的东西跟前面哈希的内容比较一下，一致则代表这内容是Alice 本人发出来的，没有被伪造、篡改。

中间人攻击

其实非对称加密不是无解的，比如来自维基百科的这个经典的例子：

造成这种问题的关键在于：没法验证公钥到底是不是属于对方的！

假设我有一种魔法，可以准确判断一个公钥是不是属于指定的人的，那么Alice在收到Mallory的公钥时就可以对他说，“哈哈，你不是Bob，对吧？中（死）间（变）人（态），哼！”

这种魔法就是——PKI（Public Key Infrastructure，公钥基础设施），可以简单认为它是一套管理公钥的系统，大家都把自己的公钥交给它来统一管理，相当于一个大家都认可的公证人，自然就可以通过它提供的信息来抵抗中间人攻击了。

PKI的核心是CA（Certificate Authority，数字证书认证机构），CA是证书的签发机构，它为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。
它怎么证明呢？
这里就用到了上面说到的“数字签名”了！！！
这里的数字证书其实就是CA对某个公钥的数字签名。

但是，问题又来了，我怎么确认CA的公钥的合法性？
还是通过网上通信吗？
那万一在这个通信过程受到了中间人攻击……是吧？
难道又要陷入“鸡生蛋，蛋生鸡”的无限循环中？

这里还是简单粗暴的解决方法，不做这件事，就完美解决了！
实际上浏览器都是在自己发布的软件中内嵌了各大CA机构的合法公钥，这样就OK了。

这个过程是这样的：
1. Alice（通过某种可靠的方式，比如当面）把自己的公钥给CA机构；
2. CA机构用自己的私钥给Alice的公钥进行加密，生成一份证书给Alice；
3. Bob要和Alice通信，Alice把那个证书发给Bob；
4. Bob根据证书的指引（比如哪个CA机构，使用什么哈希算法等），用内嵌的CA机构的公钥对证书进行验证，合法则相信服务器是自己想要通信的那个真正的服务器，而非任何中间人；
5. Bob用Alice的证书里的公钥加密自己要发送的内容，发给Alice；
6. Alice用自己的私钥解密Bob发过来的内容，得到了真正的内容。

这个过程是可靠的吗？一起来分析一下！

能被监听的数据就是Alice和Bob之间互相发送的东西：
1. Alice的证书是公开的，被人知道也没事；
2. Bob发给Alice的内容是经过可靠加密的，被别人拿到也没事，因为他们没有Alice的私钥，没法解密。
3. OK。

能被篡改的东西也是Alice和Bob之间互相发送的东西：
1. Alice的证书被篡改，Bob肯定能够马上发现（因为数字签名保证了这一点）；
2. Bob发送的东西被篡改，Alice可以通过Bob的证书来验证，这也没问题。

但是，最后一点其实还有个问题，因为C/S模式（即client/server）占据互联网的很大部分江山，而不可能要求每个个体用户都花（很多的）钱去买一个CA证书才能通信，所以万一真的有人那么无聊，伪装成某些用户发送请求发送给服务器，怎么办？

我觉得这里还是要按照请求的类型分成两个方面来说：
1. 不需要登录的请求，伪造的请求就相当于DDOS了，现在已经有很多工业级的解决方法，就不赘述了；
2. 需要登录的请求，这个也更没问题了，登录成功就认为对方是真正的用户，如果是用户自己的账户、密码被盗了，这真没办法，自己控制好对授信用户的权限即可。