饭后磨牙第一期——《HTTPS权威指南》

第一期——《HTTPS权威指南》"/>

饭后磨牙第一期——《HTTPS权威指南》

对于后端程序员而言，有些书不得不读 ，这些书都在细读经典系列里

有些书可以不精通的，但是用的时候一定知道去哪查，并且查得到，这些书不是我们职业生涯的主要矛盾，因为各种企业早已经帮你实现好了这些基础服务，甚至有专门负责的同时，但是这些知识的涉猎体现着你的软实力，比如我们今天要去过一遍的《HTTPS权威指南》。

这是一本很硬核的书，因为太硬核，甚至有点难啃

因为不知道读者所处的水平，所以这期我打算在讲解https的基础上，摘出本书种比较关键的一些小节，更多的把这本书作为一个引子，这也是我想做饭后塞牙系列的初衷。

那就让我们走起！

一、密码学基础

不论是使用怎样的方式，我们都希望在客户端和服务端之间进行安全的通信，这是网络通信中引入密码学的目的。

1.1对称加密

对称加密又叫私钥加密，整个传输过程种的加密解密都是同一套密钥。

密钥（secret key）存储在服务端，客户端可以通过请求服务端得到该密钥（虽然加密了，但其实没加密，因为每个人都一样）

缺点：密钥的获取方式，如果所有人都用同一套密钥，那么黑客就可以用这套密，钥截取并篡改你的通讯信息

1.2非对称加密

非对称加密又叫公钥加密，公钥（public key）加密的数据，只有对应的私钥（private key）能够解开，私钥加密的数据，只有对应的公钥能够解开消息。

公钥和私钥都存储在服务端。客户端在第一次请求服务端时，会请求公钥，服务端返回给客户端公钥，之后客户端可以利用公交进行文件加密，在此过程中，黑客虽然同样可以获取公钥，也可以截取客户端的请求，但是由于没有私钥，是无法对密文进行篡改的。

缺点：解决了传输安全性的问题，但考虑以下场景：如果进行服务端和客户端的通信呢？客户端有公钥，服务端有私钥，客户端可以使用公钥加密，服务端私钥解密的方式进行通信，但客户端无法通过私钥加密，公钥解密的方式向客户端进行传输，因为在此过程中，任何人都可以用公钥进行解密。所以非对称加密也存在无法满足双方安全通信的需求。

最典型的引用就是U盾（你甚至可能接触过需要刮卡的密码卡（叫什么我忘了）），最初的U盾就可以简单理解为，银行用硬件的方式，向你下发了U盾这个密钥（公钥+私钥），银行掌握有对应的（私钥+公钥），你和银行之间利用非对称加密的方式，进行安全通信。你会发现，以这样的方式维护公钥私钥，在网银刚刚兴起的年代或许可以应对当时的使用人数，然而当网银普及，针对所有的用户，都必须维护密钥，也是非常大的工程

 1.3 对称+非对称

聪明的网络人，使用了非常巧妙的方式，解决了两者单独的问题：利用非对称加密协商密钥，再利用对称加密进行传输，下图：

 这种方法可以让每个客户端和服务端协商自己的secret key并维持会话过程中的安全性。

但这种方式也有一个问题，就是中间人攻击。

如果黑客截取了你的所有请求，并模拟你与服务端建立连接，相当于你的任何操作都被黑客代理，黑客自然可以为所欲为的对你的请求进行篡改，如果不好理解的话，看下图

 1.4 对称+非对称+CA

对称+非对称通信过程无法保证中间人的合法性，那么就引入一个权威的合法机构去做中间人，通过权威的中间人完成第一步PK的传递。

权威机构提前向你下发certificate public key（CPK）（这玩意其实写死在了客户端），当客户端向服务端请求public key时，服务端将public key给CA服务器，CA服务器通过自己的certificate private Key 对public key进行加密，得到license，服务端得到license并将license发给客户端，客户端用本地写死的CPK对license解密得到public key。之后， 客户端就可以用本地生成的动态字符串作为SK，并利用public key进行加密，传给服务端请求进行对称加密通信，当服务端收到public key加密后的SK后，用本地的private key对密文进行解密，得到SK，双方都拿到了SK，就可以开始对称加密通信了。

这其中黑客同样可以在第一阶段和第二阶段进行主动攻击截取通信信息，如果在第一阶段，也就是说黑客向服务端下发了自己的lincense，由于CPK是直接存在本地的，那么客户端会根据本地的CPK发现license有问题，会提醒用户证书有风险（如果你上过部分不健康网站，没有错，就是男生都会去的那种，就偶尔会看到这种提示）；在第二阶段，黑客就算拿到了字符串通过PK加密后的密文，但是由于没有服务端的public key，也无法拿到对称加密的密钥SK，也就无法干扰对称加密。

那么CA的license到底是什么东西呢？是如何制作的呢？CA的license又是如何验证的呢？CA包含有网站的域名，IP等信息。我们以浏览器访问一次服务端为例进行说明，客户端发起通信请求申请服务端的license（也可以理解为客户端需要服务端提供证书证明自己是一个被CA认证过的合法网站），服务端将license传给浏览器，浏览器根据自己存储的CPK情况判断该license的合法性，如果合法则继续接下来的通信过程。

在实际生产上，license是由数字签名和CA证书明文组成，数字签名的生成过程如下图左所示，通过对CA证书明文进行HASH，再通过私钥加密得到数字签名，浏览器拿到license之后，利用CA颁发给浏览器的CPK直接对数字签名进行解密，之后比较解密明文和浏览器传过来的CA证书明文是否一致，判断网站是否合法，是否进行之后对称加密通信等等。至于为什么HASH，还是为了通过HASH得到固定长度的值，加快加密解密过程，当连接建立之后，就可以通过Session维持会话，不用每一次都重新生成SK了。

还没完，我们再举几个例子，比如我们12306网站，和一些商业银行的网站，都需要你在第一次使用的时候，去安装受信任的证书，这就是因为当前浏览器内，并没有存储他们被CA认证之后的CPK，那么你就会问了，我怎么知道我第一次连接的时候是不是被黑客拐跑了啊？对的，你没法知道，解决一个问题的最好办法，就是不去解决它，我们之所以敢在第一次就对12306添加信任，是因为我们通过各种渠道对12306这个网站的ip形成了安全的共识，我们基于这份共识，在我们的浏览器中添加了这份CPK，之后就可以不用再添加证书了，域名又是唯一的，这样我们就能保证，自己再访问的过程中，进入的是安全的网站了。

1.5 https和http状态码

如果原来网站是http的，现在改为https了，请求原网站就请求不通了么？当然不能这样做，所以几乎所有的大型网站都会冲过重定向将原有的http请求重定向为https请求，将原访问80端口重定向到443端口。这是我访问

 这是直接访问

最开始，百度的重定向是302，到底这些状态有什么区别呢？

这块我摘抄了一些网络上对于这几种状态的描述，不再多费口舌：

1. 对于301、302的location中包含的重定向url，如果请求method不是GET或者HEAD，那么浏览器是禁止自动重定向的，除非得到用户的确认，因为POST、PUT等请求是非幂等的（也就是再次请求时服务器的资源可能已经发生了变化）。
2. 虽然rfc明确了上述的规定，但是很多的浏览器不遵守这条规定，无论原来的请求方法是什么都会自动用GET方法重定向到location指定的url。就是说现存的很多浏览器在遇到POST请求返回301、302状态码的时候自动用GET请求location中的url，无需用户确认。
3. HTTP 1.1中新增了303、307状态码，用来明确服务器期待客户端进行何种反应。
4. 303状态码其实就是上面301、302状态码的地不合法地动作，指示客户端可以自动用GET方法重定向请求location中的url，无需用户确认。也就是把前面301、302状态码的处理动作地合法化地了。  把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）
6. 303、307其实就是把原来301、302不地合法地的处理动作给地合法化地，因为发现大家都不太遵守，所以干脆就增加一条规定。

以上，这一节东西比较多，对于不熟悉的同学，还是需要花点时间，下一节我们再正式进入饭后磨牙部分