HTTPS详解
文章首发于个人博客地址：HTTPS详解
如需转载，请附带说明文章出处。
HTTP
tps: HTTP协议的笔记在另外一篇笔记中详细记载，这里对与HTTP协议的发展历史等不做阐述。
什么是HTTP
HTTP为超文本传输协议，是一个基于请求与响应，无状态，应用层的协议，常基于TCP/IP协议传输数据。互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。
HTTP的特点
- 无状态：对客户端没有存储状态，对事物处理没有记忆能力。比如登录网站的反复登录操作。
- 一般可以使用cookies来记录用户的登录相关信息，设定过期时间等。
- 无连接：HTTP/1.1之前，由于无状态的特点，每次请求都需要经过TCP三次握手和四次挥手来重新建立和关闭TCP连接。如果是过多地请求，对于资源的利用和性能都有一定的影响。
- 一般可以使用Connection: keep-alive来建立持久连接，避免每次都需要重新建立TCP连接。很多浏览器采用少量并行的TCP连接，其中每一个TCP连接都是持久连接的形式。
- 但是对于存在代理服务器的，容易出现盲中继，哑巴代理的情况（代理服务器不认识Connection: keep-alive）。
- HTTP/1.1中默认连接都是持久连接，不需要显示的指定keep-alive，在不希望建立持久连接 的请款下，请求首部中添加Connection: close来表示希望接收到响应后就断开连接。
- 基于请求和响应： 有客户端发情请求，服务端响应。
- 简单快速，灵活
- 使用明文，请求和响应不会对通信放进行确认，无法保证数据的完整性。
- 针对HTTP明文传输，可以使用加密传输数据的方式。比如使用对阵密钥加密，MD5加密，base64加密等。
HTTP通信不加密的风险
- 窃听风险：第三方可以获取通信内容。
- 篡改风险：第三方可以修改通信内容。
- 冒充风险：第三方可以冒充他人身份参与通信。
HTTPS
什么是HTTPS
HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
PS:TLS是传输层加密协议，前身是SSL协议，由网景公司1995年发布，有时候两者不区分。
HTTPS特点
基于HTTP协议，通过SSL加密，实现了数据加密，验证身份，数据完整性保护。
- 内容加密：采用混合加密（SSL），无法通过抓包的形式查看明文内容。第三方无法窃听
- 验证身份：通过HTTPS证书，客户端可以认证确定访问的是目标服务器。
- 对于一些使用非对称加密的方式，很容易出现中间人攻击（伪造目标服务器，然后通过将自身的公钥发送给客户端用来加密的数据，然后使用私钥解密获取数据）。
- 保护数据的完整性：可以防止传输的内容被中间人冒充或者篡改。
SSL的混合加密
结合了对称加密和非对称加密技术。
对称加密：客户端和服务端使用同一个密钥解密加密。
非对称加密技术：分为公钥和私钥，客户端使用公钥加密数据传送给服务端，服务端使用私钥解密获取数据。
混合加密简单理解为：
1.客户端使用对称密钥加密要传输的数据。
2.客户端使用从服务端获取到的公钥加密上一步用于加密数据的对称密钥。
3.服务端接收到客户端传送过来的加密过的数据和使用公钥加密的密钥。那么服务端使用私钥解密得到之前客户端加密数据使用的密钥，然后使用该密钥去解密获取数据。
4.此时客户端和服务端都获取了用于加密数据的对称密钥，那么后面的数据传输，就直接使用该对称密钥加密传输。
注意：上述中说明的对称密钥的生成，实际上是通过了三个随机数按照约定的算法得出的密钥。具体的说明再后面握手阶段有详细的讲解。
HTTPS中证书验证
非对称加密的隐患
之前说过混合加密主要使用了一个对称密钥和一对公钥和私钥。其中公钥和私钥是在服务端生成的，由服务端发送给客户端的，那么其中就有一个问题了，如果确保客户端获取的公钥就是目标服务器发送的，而不是中间服务器（中间人攻击）发送给你的呢？
中间人攻击
image.png
如上图中所示，SSL加密中是使用公钥加密的对称密钥，同样也会被中间人截获到，所以需要确认客户端接收到的公钥是来自于目标服务器而不是其他服务器。HTTPS中使用证书验证来确认服务器的身份。
HTTPS证书
证书简介
SSL证书一般向权威的第三方CA机构去请求颁发。申请之后会提供给你一个证书和私钥，私钥直接存在服务端，证书则发送给客户端，因为证书中有公钥。（申请的方法这里不做阐述）
SSL证书中包含的内容：
- 服务器的域名，比如www.wjsummer.top
- 证书的过期时间
- 公钥
- 数字摘要生成的方法，比如MD5
- 使用CA机构公钥加密数字摘要后生成的数字签名。
image.png
证书的验证
那么当服务端将证书返回给客户端后，客户端就可以验证证书的真实性。
验证流程：
- 客户端根据证书的信息，确认域名是否为请求的域名，是否过期等确认证书的有效性。
- 客户端（比如浏览器）根据证书的颁发机构，选择对应机构的公钥去解密数字签名，获得数字摘要A。
- 浏览器和操作系统都会维护一个权威的第三方机构列表和它们的公钥，那么客户端在接收到服务端发送过来的证书后，就可以根据证书的颁发机构找到对应的机构公钥去解密证书的数字签名获取到数字摘要。
- 客户端根据证书上面的信息，和数字摘要生成的方法，计算生成数字摘要B。
- 对比解密得到的数字摘要A和自己生成的数字摘要B是否一致。
- 以上都没问题则确认了当前返回响应的服务器是目标服务器。
image.png
用于加密数据的对称密钥生成
前面说混合加密的基本含义时，特别说明了对称密钥使用了3个随机值来生成，那么具体的过程这里进行详细阐述。
握手阶段
SSL/TLS协议基本过程简化表示为:
- 客户端向服务端索要并验证公钥
- 双方协商生成”对话密钥“。
- 双方采用”对话密钥“进行加密通信。
上述基本过程中的前两步，称为握手阶段。握手阶段涉及到4次通信。（握手阶段的所有通信都是明文的！）
第一次通信：客户端发出请求
首先，客户端向服务端发出加密通信的请求，这被叫做ClientHello请求。这一步，客户端只要向服务器提供以下信息：
- 支持的协议版本，比如TLS 1.0版。
- 一个客户端生成的随机数A，稍后用于生成"对话密钥"。
- 支持的加密方法，比如RSA公钥加密。
- 支持的压缩方法。
第二次通信：服务端回应
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容：
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
- 一个服务器生成的随机数B，稍后用于生成"对话密钥"。
- 确认使用的加密方法，比如RSA公钥加密。
- 服务器证书
第三次通信：客户端回应
客户端在接受到服务器回应后，会先验证证书。如果证书不是可信机构颁发、或者证书的域名与实际域名不一致、或者证书已经过期，就会像访问者显示一个警告，可以选择是否还要继续通信。
如果证书没有问题，那么客户端就会从证书中获取到公钥。然后向服务端发送如下内容：
- 一个随机数C。该随机数用服务器公钥加密，防止被窃听。
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。此时客户端和服务端同时有了三个随机出A,B,C，那么他们就可以通过商定的加密加密方法，各自生成本次会话所用的同一把”会话密钥“。
第四次通信：服务器最后的回应
服务器在收到客户端发送的第三个随机数”pre-master key“之后，计算生成本次会话所用的”会话密钥“（对称密钥）。然后向客户端发送下面的信息：
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议了，只不过使用”会话密钥“（对称密钥）加密内容。
HTTPS整体流程梳理
image.png
- client向server发送请求htts://www.baidu.com。server监听443端口。
- server从CA机构申请了一套证书，包括证书（包含公钥）和私钥。在服务器中配置好（比如Nginx server将今天443端口配置中指定证书和私钥路径）。
- server将证书返回给client。
- 客户端根据证书的信息和证书颁发机构的公钥去验证证书的有效性和正确性。
- 验证证书的域名，过期时间，颁发机构。
- 通过CA机构公钥解密获得的数字摘要和client根据证书信息和加密方法生成的数字摘要对比。
- client和server通过握手阶段（4次通信），根据三个随机数和双方商定的加密方法生成会话密钥。
- 第三次通信，随机数被服务端公钥加密，由client发送给服务端。
- client和sever都知道了会话密钥，那么该次连接中传送的数据就使用该会话密钥进行加密和解密。
结束语
路漫漫其修远兮，吾将上下而求索。
