《图解HTTP》读书笔记（第七章）

确保Web安全的HTTPS

HTTP的缺点

• 通信使用明文可能会被窃听（SSL）
• 不验证通信方的身份就可能遭受伪装（数字证书）
• 无法验证报文完整性，可能已遭篡改（数字签名和加密）

下面就针对HTTP这几个缺点，提出了一系列的改进方案。

加密处理防止窃听

通信的加密

HTTP协议中没有加密机制，但可以通过和SSL(Secure Socket Layer，安全套接层）或TLS（Transpoart Layer Security，安全传输层协议）组合使用，加密HTTP的通信内容。

内容的加密

查明对手的证书

HTTP协议中的请求和响应不会对通信发进行确认，即任何人都可以发出请求，另外，服务器只要接收到请求，不管对方是谁都会返回一个响应。

虽然使用HTTP协议无法确定通信方，但如果使用SSL则可以。SSL不仅提供加密处理，而且还使用一种称为证书的手段，可用于确定方。

无法验证报文完整性，可能已遭篡改

由于HTTP协议无法证明通信的报文的完整性，因为在客户端与服务器通信的过程中，中途传送的数据有可能被截取修改过。

如何防止篡改

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？通过校验数字签名，流程见下图：

首先来了解下哈希算法，哈希算法能够将任意长度的字符串转化为固定长度的字符串，该过程不可逆，可用来作数据完整性校验。

服务器在发送报文之前做了3件的事：

• 用哈希算法对报文提取定长摘要
• 用私钥对摘要进行加密，作为数字签名
• 将数字签名附加到报文末尾发送给客户端

客户端接收到报文后：

• 用公钥对服务器的数字签名进行解密
• 用同样的算法重新计算出报文的数字签名
• 比较解密后的签名与自己计算的签名是否一致，如果不一致，说明数据被篡改过。

同样，客户端发送数据时，通过公钥加密报文摘要，服务器用私钥解密，用同样的方法校验数据的完整性。

加密方法

数据要保密，就需要对数据进行加密。加密算法可以分为2类，一类是对称加密算法，另一类是非对称加密算法。

对称加密算法：加密和解密使用相同的密钥，优点是加密速度快，缺点是如果密钥泄露的话就无法做到保密了。常见的对称加密算法有DES、AES等。

非对称加密算法：又叫公开密钥加密。需要有2个密钥，公钥和私钥，公钥向所有人公开，私钥不公开。用公钥加密的数据只有私钥才能解密；反之，用私钥加密的数据只有公钥才能解密。因为这种特性，非对称加密算法可以用来校验数字签名。

以共享密钥方式（对称加密算法）加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

HTTPS采用混合加密机制

HTTPS 采用混合加密机制 HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。

若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。

所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥（非对称）加密方式，之后的建立通信交换报文阶段则使用共享密钥（对称）加密方式。

简单来说就是：
用非对称算法随机加密出一个对称密钥，然后双方用对称密钥进行通信。

具体来说，就是客户端生成一个随机密钥，用服务器的公钥对这个密钥进行非对称加密，服务器用私钥进行解密，然后双方就用这个对称密钥来进行数据加密了。

数字证书认证过程

没有数字证书的通信过程

消息发送者A：
使用摘要算法计算出消息的摘要（长度固定），然后使用私钥对摘要进行加密，就得到了数字签名。

消息接收者B：
先使用发送者的公钥对数字签名进行解密，得到消息摘要1，消息摘要1的长度需符合约定的算法该有的长度，否则认为消息已泄密。

然后使用同样的摘要算法计算消息的摘要2，再比较摘要1和摘要2，如果相同，则证明消息内容未被篡改过，并且消息的确是A发送的。

以上通信为安全的前提是，B确定自己手中拿到的是A的公钥。

然而，公钥是存在被伪造的可能的，C(黑客）有可能通过手段将A的公钥替换成自己的，然后发送给B，这时候B会误以为自己拿到的是A的公钥。

这时候C就可以在A、B之间进行中间人攻击。

所以，必须有一个权威机构D来证明，A的公钥是真实有效的。

该权威机构D会颁发证书，所谓证书就是包含了服务器声明的公钥以及组织名称等信息，这里我们只考虑最关键的公钥信息。

该权威机构会对申请证书的组织进行审核，确保其身份合法，然后将服务器公钥信息发布给客户端，客户端可利用该公钥与对应的服务器进行通信。整个过程可归纳为以下几步：
1、服务器生成一对密钥，私钥自己留着，公钥交给数字证书认证机构（CA）

2、CA进行审核，并用CA自己的私钥对服务器提供的公钥进行签名（参照上文RSA签名）

3、客户端从CA获取证书（即服务器端公钥），用CA的公钥对签名的证书进行验证，比对一致，说明该服务器公钥确实是CA颁发的（得此结论有一个前提就是：客户端的CA公钥确实是CA的公钥，即该CA的公钥与CA对证书进行签名的私钥确实是一对。参照上文RSA签名中所论述的情况），而CA又作为权威机构保证该公钥的确是服务器端提供的，从而可以确认该证书中的公钥确实是合法服务器端提供的。

注：为保证第3步中提到的前提条件，CA的公钥必须要安全地转交给客户端，因此，CA的公钥一般来说由浏览器开发商内置在浏览器的内部。于是，该前提条件在各种信任机制上，基本保证成立。

使用HTTPS进行通讯

HTTPS的加密过程，先看下图。

1. 客户端发起HTTPS请求
   这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。

2. 服务端的配置
   采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书
   这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书
   这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息
   这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务端解密信息
   服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息
   这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。

8. 客户端解密信息
   客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

总结

HTTP+加密+认证+完整性保护 = HTTPS