一篇比较全的HTTP协议详解（3）

1. HTTP与HTTPS

相信我们会经常在URL中看到HTTPS，很少会看到HTTP。HTTP协议传输的是明文，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
简单的来说：HTTPS = HTTP + SSL

2. SSL/TLS协议

TLS是SSL的一个新版本。TLS于1999年作为SSL 3.0的后续升级版首次引入。TLS基本上于SSL大致相同，只是在一些细节方面做了改动，使其更加安全。

2.1 对称加密、非对称加密

对称加密：指的就是加、解密使用的同是一串密钥，所以被称做对称加密。对称加密只有一个密钥作为私钥。常见的对称加密算
法：DES，AES等。
非对称加密：指的是加、解密使用不同的密钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。反之，
私钥加密的信息，只有公钥才能解密。最常用的非对称加密算法：RSA

例如：Bob想给Alice发消息。Bob和Alice都有属于自己的公钥和私钥。公钥是公开的，私钥是只有自己知道。Bob使用Alice发给他的公钥将消息加密发给Alice，Alice再用自己的私钥去解密。这就是一个非对称加密的典型例子。
PS：这里要明确一点，公钥是由私钥产生的。公钥无法推出私钥。也就是说，私钥是绝对保密的。而且，就像锁一样，只有Bob的私钥才能解密Bob公钥加密数据，其他人的不行。

对称加密我们从定义中应该就可以明白，它是信息的发送方和接收方都用同一个秘钥去加密和解密数据。这样做它的最大优势是加/解密速度快，适合于对大数据量进行密，但密钥管理困难（如何对密钥进行管理，不让通信双方之外的人知道密钥）。
非对称加密，它需要使用“一对”密钥来分别完成加密和解密操作，一个公开发布，即公钥，另一个由用户自己秘密保存，即私钥。信息发送者用公钥加密，而信息接收者则用私钥去解密。非对称加密更加灵活，但加密和解密速度却比对称加密慢得多。

2.2 数字证书、签名

非对称加密计算量很大，效率不如对称加密，我们打开网页最注重的是啥？是速度！是速度！是速度！???
这点SSL就玩的很巧妙了��，通信双方通过对称加密来加密密文，然后使用非对称加密的方式来传递对称加密所使用的密钥（敲黑板！敲黑板！这点很重！！）。这样效率和安全就都能保证了（仔细想想，有点意思~）。
想一个问题，Bob想给Alice发消息，利用非对称加密就真的万无一失了么？
想象这样一个场景，Alice想将自己的公钥发给Bob，这样，Bob才能用Alice的公钥去加密数据。可是，如果有个坏蛋，在Alice公钥传输的途中，将Alice的公钥截取下来，再将自己（坏蛋）的公钥填进去，这样Bob再用收到的公钥将消息加密后，就只有坏蛋能用私钥解密了。那么如何确定消息是Bob发来的呢？这么一想，仅有非对称加密算法无法做到万无一失。于是就有了数字证书的概念：

数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，而是身份认证机构盖在数字身份证上的一个章或印（或者说加在数字身份证上的一个签名）。

数字证书内容大体如下：

签发证书的机构
Bob的加密算法
Bob所使用的Hash算法
Bob的公钥
证书到期时间
等等

随意打开一个网站，然后点击URL前面的那个小锁锁，里面会有数字证书的详细信息。

数字证书是由权威机构——CA机构统一来进行发行，我们绝对信任这个机构，至于CA机构的安全性…反正99.99%之下都是安全的。?
为了防止中间有人对证书内容进行更改，有了一个数字签名的概念，所谓的数字签名就是把以上所有的内容做一个Hash操作，得到一个固定长度然的摘要，然后再传给Bob。然而如果别人截取了这个证书然后更改内容，同时生成了新的Hash值那怎么办？处于这个考虑，CA机构在颁发这个证书的时候会用自己的私钥将Hash值加密，从而防止了数字证书被篡改。
PS：所谓的数字签名，就是为了证明这个数字证书是由CA机构签发的，保证绝对的安全性。服务端用CA颁发的私钥将Hash值加密，若Hash值被篡改，那么，另一端的浏览器用CA颁发的公钥就无法解密。这样就验证了消息的身份。

好，我们来梳理下整个过程：

第一步：首先，当Alice开启一个新的浏览器第一次去访问Bob的时候，会先让Alice安装一个数字证书，这个数字证书里包含的主要信息就是CA机构的公钥（由CA机构来保证公钥、私钥的安全性）。
第二步：Bob发送来了CA机构颁发给自己的数字证书，Alice通过第一步中已经得到的公钥解密CA用私钥加密的Hash-a，然后再用传递过来的内容，用HASH算法生成一个Hash-b，如果Hash-a=== Hash-b就说明认证通过，确实是Bob发过来的，没有被篡改过。

2.3 SSL四次握手

SSL中最复杂的协议就是握手协议。该协议允许服务器和客户机相互验证，协商加密和MAC算法以及保密密钥（也就是对称加密的密钥），用来保护在SSL记录中发送的数据。握手协议是在应用程序的数据传输之前使用的。
下面来详细整理一下握手的过程：

第一次握手：客户端发送Client Hello报文给服务端，主要内容包括：

客户端可以支持的SSL最高版本号
一个32字节的随机数 ：Random1。（等会介绍随机数有什么用）
一个确定会话的会话ID（Session会用到）。
一个客户端可以支持的密码套件列表
一个客户端可以支持的压缩算法列表。

第二次握手：收到客户端问候之后，服务器发送回应信息。服务器会检查指定诸如SSL版本和算法的客户端问候的条件，如果服务器接受并支持所有条件，它将发送其数字证书、Server Hello报文以及其他详细信息（含有服务端的公钥），否则，服务器将发送握手失败消息。
Server Hello报文主要内容：

一个SSL版本号。取客户端支持的最高版本号和服务端支持的最高版本号中的较低者。
一个32字节的随机数 ：Random2。
会话ID
从客户端的密码套件列表中选择的一个密码套件
从客户端的压缩方法的列表中选择的压缩方法

第三次握手：客户端确认证书的有效性（通过上边讲的数字签名来验证）。生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 Pre-Master-Key。

第四次握手：将服务端公钥加密的Pre-Master-Key传给服务端，服务端再用自己的私钥解出这个 Pre-Master-Key 得到客户端生成的Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份密钥（这个密钥就是对称加密的密钥），握手结束后的应用层数据都是使用这个密钥进行对称加密。

2.4 握手过程的优化

如果每次重连都要重新握手还是比较耗时的，所以可以对握手过程进行优化。 Client Hello 消息里还附带了上一次的 Session ID，服务端接收到这个 Session ID 后如果能复用就不再进行后续的握手过程。

3.数据的完整性

窃听者可以对传输中的加密数据进行两种可能的攻击：尝试解密数据或尝试修改数据。只要密钥安全，我们就可以认为解密基本上是不可能的，但如果是修改数据呢？客户端和服务器是怎么知道攻击者没有修改过数据呢？如上所述，SSL不仅仅是加密数据，还可以检查数据的完整性。让我们看看它是怎么做到的。

PS：S就是对称加密的密钥。MAC=Hash(message+s)

服务器或客户端使用对称加密的密钥加密数据时，它还会计算明文数据的校验和（哈希值），这个校验和称为消息认证代码（MAC）。然后在发送之前将MAC包含在加密数据中。密钥用于从数据中生成MAC，以确保传输过程中攻击者无法从数据中生成相同的MAC，故而MAC被称为HMAC（哈希消息认证码）。另一方面，在接收到消息时，解密器将MAC与明文分开，然后用它的密钥计算MAC，并将其与接收到的MAC进行比较，如果匹配，那我们就可以得出结论：数据在传输过程中没有被篡改。