图解http（04）-https

https由来

我们在之前讲述了http强大的功能，然而事情总是有缺憾的，http也存在巨大的缺点，它的缺点根本就在于http相对来讲是个比较简单地协议，它在安全性方面漏洞很大。主要体现在三个方面：

• http报文是明文传送的，所以它存在着被监听的风险；
• 我们在进行http通信的时候无法确认通信双方的身份，很有可能通信双方有一方甚至双方都是带有敌意的伪装角色；
• 我们在http报文进行传输时，无法确保报文的完整性以及真实性，报文是存在被篡改的风险的。

当安全性问题越来越突显时，https油然而生了，https的优点在于：

• 建立通信双方的管道，保证报文的私密性；
• 通信双方建立验证机制，可以明确通信双方的身份；
• 对报文的有完整性保护。

这样来看，https是不是刚好解决了http的根本缺点，当然是了，下面我们来了解一下什么是https。

---

https简介

我们知道http协议是tcp/ip协议族中应用在应用层的协议，是超文本传输协议，https并不是一个新的协议，从它的名字可以看到http secure它就是安全的http，所以https的特征就在于安全。

我们通过SSL协议来实现安全这个初衷，所以说https就是身披SSL外衣的http。

我们在阐述https是怎样实现安全之前，先来了解一下这些概念。

---

加密

加密的方式分为两种：对称加密、非对称加密。

对称加密

对称加密又称共享密钥加密，就是通信一方利用密钥将数据加密，然后将自己持有的密钥交给通信的另一方，通信的另一方利用得到密钥可以解密数据，即通信双方加解密共用一个密钥，这样最大的弊端就在于我们在传输密钥给另外一方时如果密钥落入攻击者之手，那么加密将毫无意义。

非对称加密

非对称加密又称公开密钥加密，是指通信一方拥有一个私有密钥和一个公开密钥，顾名思义私钥只有本人知道，公钥所有人都可知道。通信另一方利用得到的公钥将数据加密，通信一方得到密文后利用和公钥相对的私钥进行解密，这种方式之所以能保证数据的安全性主要取决于这两个因素：

• 密文和公开密钥有可能同时落入攻击者之手，但是按照目前的技术很难通过这两个东西对密文进行解密，英文解密的过程是对离散对数进行求值，这并非易事。
• 用来直接解密的私钥在通信过程中没有被传输过，所以可以保证私钥的安全性，从而来确保不让除私钥拥有者以外的其它人具有解密的能力。

https的加密方式

由此可见，非对称加密的方式安全性远远大于对称加密的方式，那么是不是https是否就直接使用非对称加密的方式了呢？其实我们知道凡事都有两面性，非对称加密在提升安全性的同时其加解密的速率远远不如对称加密的方式，https采用了混合加密的方式。

其实在对称加密的环节，唯一的安全漏洞就在于我们无法保证密钥传输的安全性，所以我们利用非对称加密的方式来保证对称加密中的密钥的安全性，然后再利用对称加密的高速度加解密报文。

就是说，我们利用非对称加密方式的安全性来传输对称加密方式所需要的共享密钥，然后利用对称加密方式的速度来加解密报文，很巧妙的综合了两者的优点同时也避开了各自的短板。

然而，非对称加密是不是就是万无一失的呢？显然不是，非对称加密的有可能出现问题的环节在于我们如何保证通信一方收到的公钥就是通信另一方发送的公钥，这个期间它可能被攻击者替换了，这样利用非法的公钥加密的密文我们无法用私钥解密。于是，验证公钥正确性的证书就出现了。

---

数字摘要

数字摘要是采用单项Hash函数将需要加密的明文”摘要”成一串固定长度(128位)的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文摘要必定一定。“数字摘要”是https能确保数据完整性和防篡改的根本原因。常用的摘要主要有MD5、SHA1、SHA256等。

---

数字签名

数字签名技术就是对”非对称密钥加解密”和”数字摘要”两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接受者。接受者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原因产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输的过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

数字签名的过程：

明文——>hash运算——>摘要——>私钥加密——>数字签名

---

数字证书

对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机哪里发送的，
而且没有被篡改过呢?亦或者请求的目标主机本身就是从事窃取用户信息的不正当行为呢？这时候，我们需要一个权威的值得信赖的第三方机构(一般是由政府机构审核并授权的机构)来统一对外发送主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题

1. 数字证书的颁发过程

用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心通信一系列的验证之后将发送给用户一个数字证书，该证书内包含用户的人信息和他的公钥信息，同时还附有认证中心的签名信息(根证书私钥)签名。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布，数字证书各不相同，每种证书可提供不同级别的可信度。

2. 证书包含哪些内容

• 证书颁发机构的名称
• 证书本身的数字签名
• 证书持有者的公钥
• 证书签名用到的Hash算法

3. 验证证书的有效性

• 浏览器默认都是会内置CA跟证书，其中根证书包含了CA的公钥；
• 防伪造证书1:如果证书颁发机构是伪造的，浏览器不认识，直接认为是危险证书；
• 防伪造证书2:证书颁发机构是的确存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解密不了，认为是危险证书；
• 防篡改:对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A，然后再根据签名的Hash算法计算出证书的摘要B，对比A与B，若相等则正常，若不相等则是被篡改过的。

---

https的八次握手

https的八次握手，大体上分为这几个步骤：

1. 验证证书的有效性(是否被更改，是否合法)；
2. 握手生成会话密钥；
3. 利用会话密钥进行内容传输。

1. 客户端首次发出请求

由于客户端和服务器对加解密支持的程序不同，所以客户端首先要告诉服务器自己支持哪些类型的加密，然后客户端产生一个随机数N1。客户端向服务器发送的内容：

1. 支持的协议版本，比如TLS 1.0版本；
2. 客户端生成的随机数N1，稍后用于生成”对话密钥”；
3. 支持的加密方法、压缩方法。

2. 服务器的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以是自己制作或者CA证书。区别就是自己办法的证书需要客户端验证通过，才可以继续访问，而使用CA证书则不会弹出提示页面。这套证书其实就是一堆公钥和私钥。公钥给别人加密使用，私钥给自己解密使用。服务器在接收到客户端的请求后，服务器需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数N2。

3. 服务器首次回应

把上个阶段生成的加密协议的版本，加密的算法，随机数以及自己的证书一起发送给客户端。这个随机数是整个过程的第二个随机数N2，返回的信息包含：

1. 协议的版本，比如TLS1.0版本；
2. 加密的算法；
3. 随机数N2；
4. 服务器证书。

4. 客户端验证证书

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信任机构颁布、或者证书中的域名和实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

5. 客户端传送加密信息

验证证书通过后，客户端再次产生一个随机数(第三个随机数)，然后使用证书中的公钥进行加密，以及放一个ChangCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新密钥加密一段数据一并发送到服务器，确保正式通信前无误。
客户端使用前面的两个随机数以及刚刚新生成的新随机数(又称”pre-master key”)。
简单的说下ChangeCipherSpec:
ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务器，客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态，准备使用之前协商好的加密套件加密数据并传输了。
这部分传送的是用证书加密后的随机值，目的就是让服务器得到这个随机值，以后客户端和服务其的通信就可以通过这个随机值来进行加密解密了。服务器与客户端之前的数据传输过程中是庸才对称加密方式加密的。

6. 生成会话密钥

上面产生的随机数，是整个握手阶段的出现的第三个随机数，又称”pre-master key”。有了它之后，客户端和服务器同时有了三个随机数，接着双方就用事先协商的加密方法，各自生成本地会话所用的同一把”会话密钥”。

7. 服务器最后的回应

服务器生成”会话密钥”后，向客户端最后发送下面信息：

1. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送；
2. 服务器握手结束通知，表示服务器握手阶段已经结束。这一项同时也是前面所有内容的hash值，用来供客户端校验。

8. 客户端解密

客户端用之前生成的私钥解密服务器传过来的信息，于是获取了解密后的内容。至此，整个握手阶段全部结束了。接下来，客户端与服务器进入加密通信，就完全是使用普通HTTP协议，只不过用”会话密钥”加密内容。

---