https原理分析之数字证书和TLS协议内容

 HTTPS加密原理：

• 地址为绿色, 表示使用了加密传输，安全且可信任;
• 地址为红色, 则表示虽然开启了加密, 但网站身份未验证, 不保证中间不会被人篡改。

从我们在地址栏敲下 https:// 网站那一刹那, 到内容显示到我们面前, 中间经过了哪些过程了?  浏览器根据什么来判断, 当前网站网址是安全的还是未验证的?   

互联网外交安全策略SSL/TLS协议运行机制。

一.Https背景介绍：SSL/TLS协议的由来

最早期的通信是不使用SSL/TLS的HTTP通信，也就是没有加密的通信。信息传递过程中存在很多的问题：被第三方窃听，被第三方修改通信内容，被第三方冒充他人身份参与通信。 大家都希望能有一种加密的信息传输，能够保证信息安全，SSL/TLS协议诞生。

历史发展

互联网加密通信协议的历史，几乎与互联网一样长：

1994年，NetScape公司（网景公司）设计了SSL 1.0版，但是未发布；

1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞；

1996年，SSL 3.0版问世，得到大规模应用；

1999年，互联网工程任务组（IETF）标准化了一种名为 TLS 1.0 的新协议，这是SSL的升级版本；

2006年和2008年，TLS两次升级，分别更新至TLS 1.1和TLS 1.2(修复了1.1中的漏洞)。紧接着2011年发布了TLS 1.2的修订版；

然而直到2013年大部分的浏览器才开始支持TLS 1.2。

2018.8 ，TLS 1.3的最终版本发布，包含许多安全性和性能改进。

由此可见，SSL和TLS简单地可以理解为是同一种协议的不同版本，故它们总是成对出现。

TLS 1.3于2018.3月发布，你的浏览器应该已经支持它了。
TLS 1.3进一步改进了安全性，移除了一些不安全的特性。

• 实际上现代的浏览器已经基本不使用SSL，使用的都是TLS， SSL 3.0于2015年已经寿终正寝 —— 各大浏览器也不支持了。但是由于SSL这个术语存在的时间太长，很多地方还是广泛的使用它，但是要清楚其实它说的是TLS。
• 有调查显示现在绝大部分浏览器（> 99.5%)都使用TLS 1.2或者TLS 1.3。只有不足1%的浏览器仍然使用TLS 1.0或者TLS 1.1。
• TLS 1.2仍然是主流协议（本文写于2020年初），相信将来逐渐TLS 1.3将会作为主流协议。
• 很多浏览器将会开始不支持TLS 1.0和1.1:

• Google将在Chrome 72中不推荐使用TLS 1.0和1.1，而Chrome 81之后将会完全不支持。
• Mozilla的Firefox，微软的Edge和IE以及苹果的Safari 都会分别于2020年逐渐移除对TLS 1.0和1.1的支持。
• 那么一些还在使用TLS 1.0和1.1的网站就得被迫升级到TLS 1.2或者TLS 1.3。
• 要关闭浏览器对TLS 1.0和1.1的支持，可以在Internet选项中修改：

SSL/TLS在TCP/IP参考模型中的位置

SSL/TLS其实是一个协议族 而非单个协议，由SSL/TLS握手协议、修改密文协议、报警协议以及记录协议四部分组成。

SSL/TLS协议自身可分为两层：主要的有SSL记录协议和SSL握手协议。

SSL记录协议建立在可靠的传输协议，如TCP之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

SSL握手协议建立在SSL记录协议之上，用于在实际的数据传输开始前，通信双方进行身份认证、协商交换密钥等。

SSL/TLS如何实现安全保障呢

使用SSL/TLS协议，能够使我们在互联网上的通信做到“看不懂、改不掉、仿不了”，这组安全协议真的很复杂！分别对信息安全的机密性、完整性和可认证性做了确认。

机密性：当通信双方确信没有人能够理解他们的对话内容时，通信被认为是保密的。使用对称加密可以实现通信的机密性。

完整性：SSL/TLS具有校验机制，握手协议中定义了MAC，一旦信息被篡改，通信双方会立即发现并采取措施。

可认证性：为防止恶意攻击者冒充合法网站，网站需要通过证书和公钥加密来向Web浏览器证明自己的身份，在此过程中，浏览器需要两件事情来信任证书：证明另一方是证书的持有者，并证明证书是可信的。

在互联网通信中，通过建立共享密钥和证明证书的所有权的过程来实现机密性和可认证性，SSL/TLS协议则是通过“握手”流程来实现这两点，当中的完整性是由握手协议定义的MAC来实现。那么，如此至关重要的“握手”流程是怎么样的呢？

详解“握手”流程

"握手阶段"涉及四次通信 ，  我们一个个来看。  需要注意的是，"握手阶段"的所有通信都是明文的。

 

客户端发出请求（ClientHello）:

客户端向服务器发出请求，会带上以下信息：

1. 一个客户端生成的随机数
2. 支持的加密方式，即图中的Cipher Suite
3. 支持SSL/TLS协议的版本号
4. Session ID，如果是之前断开的会话，会带上Session ID用来恢复会话。
5. 签名使用的哈希算法

服务器回应（SeverHello）:

服务器响应客户端的请求，如果上一步带上了Session ID，则直接恢复会话，否则带上以下信息给客户端：

1. 选择SSL/TLS协议版本号
2. 选择加密方式
3. 一个服务器生成的随机数
4. 服务器证书

客户端会在这里校验服务器证书的合法性，包括检测证书有效时间，以及证书中域名与当前会话域名是否匹配，并沿着信任链查找顶层证书颁发者是否是操作系统信任的CA机构。

客户端回应:

客户端校验服务器证书的合法性，生成premaster secret，向服务器发送以下信息：

1. 用服务器证书取出的公钥加密后的premaster secret，这里的premaster secret其实是另一个随机数
2. 加密约定改变通知，通知服务器，以后的通信都适用协商好的加密方法和密钥进行加密
3. 客户端握手结束通知。这个报文也是验证消息，是前面发送的所有内容的哈希值，用来供服务器校验。

 

服务器最后确认:

这是握手过程的最后一步，服务器会把以下信息发送给客户端：

1. 加密约定改变通知，通知客户端，以后的通信都适用协商好的加密方法和密钥进行加密
2. 服务器握手结束通知，该报文也作为校验消息，供客户端验证。

到这个时候，客户端和服务器同时拥有了3个随机数，使用这三个随机数生成的密钥，将被用于后续通信的对称加密。

二、证书（Digital certificate）

理解 HTTPS 的工作原理：

HTTPS，也称作HTTP over TLS。 TLS的前身是SSL，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。 本文着重描述TLS协议的1.2版本。

下图描述了在TCP/IP协议栈中TLS(各子协议）和HTTP的关系

 

Credit:  Kaushal Kumar Panday From:  SSL Handshake and HTTPS Bindings on IIS

其中 SSL Handshaking Protocols 包括   Handshake protocol，Change Ciper Spec protocol 和Alert protocol组成了。

HTTPS和HTTP协议相比提供了

1. 数据完整性：内容传输经过完整性校验
2. 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
3. 身份认证：第三方无法伪造 服务端（客户端）身份

其中， 数据完整性和隐私性由  TLS Record Protocol保证， 身份认证由TLS Handshaking Protocols实现。

总览：使用RSA算法的SSL握手过程是这样的：

Source:  Keyless SSL: The Nitty Gritty Technical Details

1. [明文] 客户端发送随机数client_random和支持的加密方式列表
2. [明文] 服务器返回随机数server_random，选择的加密方式和服务器证书链
3. [RSA] 客户端验证服务器证书，使用证书中的公钥加密premaster secret发送给服务端
4. 服务端使用私钥解密premaster secret
5. 两端分别通过client_random，server_random和premaster secret生成master secret，用于对称加密后续通信内容 

那么什么是证书呢？

证书中包含什么信息：

• 证书信息： 过期时间和序列号
• 所有者信息：姓名等
• 所有者公钥

2.1、为什么服务端要发送证书给客户端？

     互联网有太多的服务需要使用证书来验证身份，以至于客户端（操作系统或浏览器等）无法内置所有证书，需要通过服务端将证书发送给客户端。

2.2、客户端为什么要验证接收到的证书？

    中间人攻击

客户端<------------攻击者<------------服务端
 伪造证书 拦截请求

2.3、客户端如何验证接收到的证书？

    为了回答这个问题，需要引入数字签名（Digital Signature）。

+---------------------+
| A digital signature |
|(not to be confused |
|with a digital |
|certificate) | +---------+ +--------+
| is a mathematical |----哈希--->| 消息摘要 |---私钥加密--->| 数字签名 |
|technique used | +---------+ +--------+
|to validate the |
|authenticity and |
|integrity of a |
|message, software |
|or digital document. |
+---------------------+

将一段文本通过哈希（hash）和私钥加密处理后生成数字签名。

假设消息传递在Bob，Susan和Pat三人之间发生。Susan将消息连同数字签名一起发送给Bob，Bob接收到消息后，可以这样验证接收到的消息就是Susan发送的

+---------------------+
| A digital signature |
|(not to be confused |
|with a digital |
|certificate) | +---------+
| is a mathematical |----哈希--->| 消息摘要 |
|technique used | +---------+
|to validate the | |
|authenticity and | |
|integrity of a | |
|message, software | 对
|or digital document. | 比
+---------------------+ |
 |
 |
 +--------+ +---------+ 
 | 数字签名 |---公钥解密--->| 消息摘要 | 
 +--------+ +---------+

当然，这个前提是Bob知道Susan的公钥。更重要的是，和消息本身一样，公钥不能在不安全的网络中直接发送给Bob。

此时就引入了证书颁发机构（Certificate Authority，CA），CA数量并不多，Bob客户端内置了所有受信任CA的证书。CA对Susan的公钥（和其他信息）数字签名后生成证书。

Susan将证书发送给Bob后，Bob通过CA证书的公钥验证证书签名。

Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任链（Chain Of Trust）就是这样形成的。

事实上，Bob客户端内置的是CA的根证书（Root Certificate），HTTPS协议中服务器会发送 证书链（Certificate Chain）给客户端。

TLS协议：

TLS协议包括  TLS Record Protocol 和 TLS Handshake Protocol。总览中的流程图仅涉及到TLS Handshake Protocol。

TLS Record Protocol：

在TLS协议中，有四种子协议运行于Record protocol之上

• Handshake protocol
• Alert protocol
• Change cipher spec protocol
• Application data protocol

Record protocol起到了这样的作用

• 在发送端：将数据（Record）分段，压缩，增加MAC(Message Authentication Code)和加密
• 在接收端：将数据（Record）解密，验证MAC，解压并重组

值得一提的是，Record protocol提供了数据完整性和隐私性保证，但Record类型（type）和长度（length）是公开传输的。

Record Protocol有三个连接状态（Connection State），连接状态定义了压缩，加密和MAC算法。所有的Record都是被当前状态（Current State）确定的算法处理的。

TLS Handshake Protocol和Change Ciper Spec Protocol会导致Record Protocol状态切换。

empty state -------------------> pending state ------------------> current state
 Handshake Protocol Change Cipher Spec

初始当前状态（Current State）没有指定加密，压缩和MAC算法，因而在完成TLS Handshaking Protocols一系列动作之前，客户端和服务端的数据都是明文传输的；当TLS完成握手过程后，客户端和服务端确定了加密，压缩和MAC算法及其参数，数据（Record）会通过指定算法处理。

其中，Record首先被加密，然后添加MAC（message authentication code）以保证数据完整性。

TLS Handshaking Protocols：

Handshakeing protocols  包括Alert Protocol，Change Ciper Spec Protocol和Handshake protocol。本文不会详细介绍Alert Protocol和Change Ciper Spec Protocol。

使用 RSA算法的握手过程是这样的（已在总览中提到）

Source: Keyless SSL: The Nitty Gritty Technical Details

客户端和服务端在握手hello消息中明文交换了client_random和server_random，使用RSA公钥加密传输premaster secret，最后通过算法，客户端和服务端分别计算master secret。 其中，不直接使用premaster secret的原因是：保证secret的随机性不受任意一方的影响。

Diffie–Hellman算法的原理：  除了使用RSA算法在公共信道交换密钥，还可以  通过Diffie–Hellman算法。 Diffie–Hellman算法的原理是这样的：

 

By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons

使用Diffie–Hellman算法 交换premaster secret的流程

Source: Keyless SSL: The Nitty Gritty Technical Details 

小结：

TLS Handshaking Protocols 协商了TLS Record Protocol使用的算法和所需参数，并验证了服务端身份；TLS Record Protocol在协商后保证应用层数据的完整性和隐私性。

TLS Handshaking Protocol的核心是在公开信道上传递premaster secret。

Q&A

1.为什么传输内容不直接使用非对称加密？

性能

2.HTTPS能保证正常连接？

no

There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.

攻击者甚至可以直接丢弃双方的数据包。

3.服务端如何验证客户端身份？

通过Client Certificate

This message conveys the client’s certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating thepremaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.

4.Alert protocol有什么作用？

Closure Alerts：防止Truncation Attack

In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Error Alerts：错误处理

master secret是如何计算的

 master_secret = PRF(pre_master_secret, "master secret",
 ClientHello.random + ServerHello.random)
 [0..47];

加密，压缩和MAC算法参数是如何计算的

Handshaking Protocols使得客户端和服务端交换了三个参数：client_random，server_random和master_secret，通过以下算法生成算法所需要的参数

To generate the key material, compute
 key_block = PRF(SecurityParameters.master_secret,
 "key expansion",
 SecurityParameters.`server_random ` +
 SecurityParameters.`client_random`);
until enough output has been generated. Then, the key_block is
partitioned as follows:
 client_write_MAC_key[SecurityParameters.mac_key_length]
 server_write_MAC_key[SecurityParameters.mac_key_length]
 client_write_key[SecurityParameters.enc_key_length]
 server_write_key[SecurityParameters.enc_key_length]
 client_write_IV[SecurityParameters.fixed_iv_length]
 server_write_IV[SecurityParameters.fixed_iv_length]

The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key

使用Diffie-Hellman算法的TLS握手细节

十、题外话

1.如何保证公钥属于被访问的合法网站？

将公钥放在数字证书中，签发证书的CA是被信任的，故公钥是被信任的。

2.为什么要这么复杂地产生会话密钥，何不直接传输商定好的密钥更方便？

随着攻击手段的不断发展，任何传输过程都不受信任，即使将会话密钥进行加密传输，都有被窃取的危险。因此采用Diffle-Hellman密钥协商算法，在传输过程中能够始终不出现会话密钥本身，会话密钥仅在握手结束时在客户端和服务器本地各自生成。

3.既然产生对称的会话密钥很复杂，为什么不采用可避免密钥泄露问题的公钥加密？

因为公钥加密相比于对称加密，计算速度很慢，不适用于通信时的大量数据加密。

4.在握手过程中如何确认服务器是私钥持有者？

客户端无法看见服务器的私钥，那就让服务器证明它可以使用私钥即可，服务器使用私钥对客户端已知的信息进行数字签名，若客户端能够用服务器的公钥认证该数字签名，则可确定对方持有相应私钥。