总结SSL/TLS协议运行机制

文章目录

前言
一. 几个小问题
- 1.1 HTTP协议、HTTPS协议，SSL/TLS协议概述
- 1.2 对称加密与非对称加密
- 1.3 数字证书
- - 1.3.1 数字证书是什么？
  - 1.3.2 数字签名是什么？
二. SSL/TLS详解
- 2.1 为什么要使用SSL
- 2.2 TSL握手过程详解
- 2.3 疑问解答
- - 2.3.1 证书中的数字签名有什么作用？
  - 2.3.2 证书链是如何层层校验的
  - 2.3.3 为什么协商密钥的计算要用到多个随机数
  - 2.3.4 为什么握手结束之后是采用对称加密？
  - 2.3.5 使用https协议会被抓包吗？
三.fildder抓包原理
四.参考链接
写在最后

前言

测试代码时想抓个包，之前一直用charles，但是公司的新项目抓不到，charles显示unknown，手机上的app显示证书异常，查了一些资料，说是安卓7.0+版本的用户自己下载安装的证书是不被信任的，需要放在system目录下。后续过程比较繁琐，抓包的问题先告一段落，在研究这个的过程中，我了解了SSL/TSL网络协议以及它们的运行机制，特此记录一下。

一. 几个小问题

1.1 HTTP协议、HTTPS协议，SSL/TLS协议概述

HTTP协议超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，是互联网上应用最为广泛的一种网络协议，所有的WWW文件都必须遵守这个协议。设计HTTP协议的初衷是为了提供一种发布和接收HTML页面的方法。
HTTPS协议是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP协议进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换的数据的隐私和完整性。
SSL协议安全套接字层，位于可靠的面向连接的网络层协议和应用层协议之间的一种协议。SSL通过相互认证，使用数字签名确保完整性，使用加密确保隐私性，以实现客户端和服务器之间的安全通讯，该协议由两层组成：SSL记录协议和SSL握手协议。
TLS协议安全传输层协议，是在SSL3.0基础上设计的协议，实际上相当于SSL的后续版本，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。协议由两层组成：底层是TLS记录协议，主要负责使用对称密码对信息进行加密，上层是TLS握手协议，主要分为握手协议、密码规格变更协议和应用数据协议4个部分。

1.2 对称加密与非对称加密

在对称加密算法中：加密和解密用同一把密钥
加密：原文 + 密匙 = 密文
解密：密文 - 密匙 = 原文
在非对称加密算法中：加密和解密用不同的密钥，公钥和私钥，用公钥加密的密文只能用私钥解密。

1.3 数字证书

1.3.1 数字证书是什么？

数字证书又称CA证书，是CA机构颁发给服务端的，数字证书包含两个部分

服务器的公钥
持有者信息
证书认证机构（CA）的信息
CA 对这份文件的数字签名及使用的算法
证书有效期
还有一些其他额外信息

1.3.2 数字签名是什么？

数字签名实际上是加密后的服务器公钥，用来识别身份。生成过程：

首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值
然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名
最后将 Certificate Signature 添加在文件证书上，形成数字证书

二. SSL/TLS详解

2.1 为什么要使用SSL

不使用SSL/TLS的HTTP通信，可能会造成三大风险。

窃听风险：第三方可以获知通信内容
篡改风险：第三方可以修改通信内容
冒充风险：第三方可以冒充他人身份参与通信

使用SSL/TSL希望达到

所有信息都是加密传播，第三方无法窃听
具有校验机制，一旦被篡改，通信双方能立刻发现
配备身份证书，防止身份被冒充

2.2 TSL握手过程详解

客户端以明文发出加密通信的请求，向服务器提供以下信息。

支持的加密方法
客户端生成的随机数Random_C

服务器收到请求，回应以下内容

确认使用的加密方法
服务器生成的随机数Random_S
CA证书

客户端验证CA证书：首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；浏览器收到证书后可以通过数字证书中指明的颁发者，在系统或者浏览器信任的证书中找到这个颁发者证书，使用上层证书的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2；最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。
计算协商密码：根据得到的两个明文随机数Random_C 和 Random_S 与自己计算的 Pre-master，计算出协商密钥enc_key。enc_key=Fuc(random_C, random_S, Pre-Master)。
证书验证过CA证书后就向服务器发送以下信息

服务器的公钥加密后的随机数enc_pre_master
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
客户端握手结束通知（握手信息），是前面发送的所有内容的hash值，并通过协商密钥enc_key加密，供服务器进行校验

服务器的最后回应：服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"enc_key，并用协商秘钥enc_key解密握手信息，并验证HASH是否与客户端发的一样。然后向客户端发送以下信息

编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
服务器握手结束通知（握手消息），是前面发送的所有内容的hash值，通过协商密钥enc_key加密，供客户端器进行校验。

握手成功后，所有的通信数据会通过之前协商密钥enc_key和约定的算法进行加密解密

2.3 疑问解答

2.3.1 证书中的数字签名有什么作用？

数字签名主要保证了证书的没有被中间人篡改过。
这篇文章非常生动，可以帮助理解数字签名详解

2.3.2 证书链是如何层层校验的

我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，而这个验证证书合法的过程类似一个“递归”过程。
比如百度的证书有三级：根证书—>中间证书—>百度证书。
对于这种三级层级关系的证书的验证过程如下：

客户端收到百度的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证百度证书是否可信，于是，客户端根据百度证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，以下用G2代替，然后向 CA 请求该中间证书。
请求到证书后发现G2证书是由 “GlobalSign Root CA” 签发的，以下用RCA代替，由于RCA没有上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证G2 证书，如果发现验证通过，就认为该中间证书是可信的。
G2证书被信任后，可以使用G2证书中的公钥去验证百度证书的可信性，如果验证通过，就可以信任百度证书。
在这四个步骤中，最开始客户端只信任根证书RCA证书的，然后RCA证书信任G2证书，而G2证书又信任百度证书，于是客户端也信任百度证书。总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 http://baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。

2.3.3 为什么协商密钥的计算要用到多个随机数

dog250的解释
"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

另外，整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。理论上，只要服务器的公钥足够长（比如2048位），那么Premaster secret可以保证不被破解。但是为了足够安全，我们可以考虑把握手阶段的算法从默认的RSA算法，改为 Diffie-Hellman算法（简称DH算法）。
采用DH算法后，Premaster secret不需要传递，双方只要交换各自的参数，就可以算出这个随机数。
上图中，第三步和第四步由传递Premaster secret变成了传递DH算法所需的参数，然后双方各自算出Premaster secret。这样就提高了安全性。

2.3.4 为什么握手结束之后是采用对称加密？

因为非对称加密的效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。

2.3.5 使用https协议会被抓包吗？

答案是会，曾经我也很困惑这个问题，https不是号称安全吗,为什么会被抓包？实际上HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

三.fildder抓包原理

Fiddler截获客户端发送给服务器的HTTPS请求，此时还未建立握手。
Fiddler向服务器发送请求进行握手，获取到服务器的CA证书，用根证书公钥进行解密，验证服务器数据签名，获取到服务器CA证书公钥。然后Fiddler伪造自己的CA证书，冒充服务器证书传递给客户端。
客户端根据返回的数据进行证书校验、生成密码Pre_master、用Fiddler伪造的证书公钥加密，并生成HTTPS通信用的对称密钥enc_key。
客户端发送信息到服务器，被Fiddler截获。Fiddler将截获的密文用自己伪造证书的私钥解开，获得https通信用的对称密钥enc_key，然后将对称密钥用服务器证书公钥加密传递给服务器。
服务器用私钥解开后建立信任，然后再发送加密的握手消息给客户端。
Fiddler截获服务器发送的密文，用对称密钥解开，再用自己伪造证书的私钥加密传给客户端。
客户端拿到加密信息后，用公钥解开，验证HASH。握手过程正式完成，客户端与服务器建立了信任。

四.参考链接

对以下资料作者表示感谢~
fiddler抓包
SSL/TSL运行详解
https详解
浏览器如何验证HTTPS证书的合法性？

写在最后

对于网络我仅仅处于一个还未入门的阶段，对于以上内容只是也仅仅限于了解，很多都是基于对资料的理解写出自己的总结，也有一些是直接对原文的摘要，如果有不正确的地方，希望得到大神指正。