HTTPS是互联网 web 大势所趋。各大网站都已陆续部署了 HTTPS，这篇文章我们来探讨什么是HTTPS以及为什么要部署HTTPS。

读完本文，你能明白

• 什么是HTTPS，TLS(SSL)，TLS和HTTPS是什么关系

• 什么是证书和数字签名，它们是如何传递信任的

• 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的关系

HTTP

当你在浏览器输入一个网址 (例如 http://365jz.com)的时候，浏览器发起一个 HTTP 请求，带着请求信息 (参见 HTTP Headers)，连接到服务器，把请求信息递给服务器，服务器收到信息之后，解析相关的信息，然后进行处理，再返回浏览器请求的数据。

简单来说是这么一个流程：

1. 小明 跟 浏览器爸爸 说我想要去中关村某个店家拿一些东西 (发起请求)

2. 浏览器爸爸 就把 小明 要的东西记在一张清单上 (生成HTTP协议)

3. 然后 浏览器爸爸 派出一个 线程小弟，噌噌噌跑到中关村的店里，把清单递给 店家，说小明要这些东西 (进行传输)

4. 店家 让 线程小弟 稍等，然后去屋子里面拿小明的这些东西 (服务器收到请求)

5. 店家 把东西拿出来后，并且也打印了一份清单，让 线程小弟 带着清单和东西一起拿回去 (服务器处理请求完毕)

6. 然后 线程小弟 回到 浏览器爸爸 那边，把服务器给的清单和物品交给浏览器爸爸，浏览器爸爸根据清单核对物品 (浏览器处理响应)

7. 然后把物品打包交给了 小明 (浏览器渲染并呈现界面)

这其中有个问题，浏览器爸爸和服务器都没有验证清单信息的有效性和对方的身份。万一有人在中间把线程小哥拦下来，暴揍一顿，然后把物品清单给换了怎么办？或者有人把线程小哥在半路上暴揍一顿，拿了清单换了另外一个小哥怎么办？

这是个很严肃的问题：假如服务器要把一些东西锁在柜子里，需要小明给密码才可以打开柜子。然后小明把密码写在清单上让浏览器爸爸交给服务器。这时候，如果这张清单被人拦截下来，不就得到了小明的密码？

简单来说，传输的信息中包含用户密码，被拦截了怎么办？

HTTPS

正因为HTTP请求有这些安全性的问题，所以HTTPS诞生了，致力于解决了这些安全性问题，我们进行一下对比：

那么HTTPS是如何做到更安全的呢？

简单来说，HTTPS 即是在 HTTP 下加入了一层 SSL 加密，所以被称为HTTPS。具体的加密过程则是 公匙加密法：

• 客户端向服务器索要公匙，然后使用公匙加密信息

• 服务器收到加密后的信息，用自己的私匙解密

公匙密码和算法都是公开的，而私匙则是保密的。加密使用的公匙和解码使用的密匙都是不相同的，因此这是一个 非对称加密 算法。

数字证书

提及 HTTPS ，就会听到大家说需要证书才能部署，那么什么是证书呢？

因为互联网不安全，公匙也是信息的一部分，也是会有被篡改的风险的。所以引入了互联网权威机构 - CA 机构，又称为证书授权 (Certificate Authority) 机构，浏览器会内置这些"受信任的根证书颁发机构" (即 CA)。

服务端向权威的身份鉴定 CA 机构申请数字证书，CA 机构验证了网站之后，会把网站录入到内部列表，采用 Hash 把服务端的一些相关信息生成摘要，然后 CA 机构用自己的私匙，把服务端的公匙和相关信息一起加密，然后给申请证书的服务端颁发数字证书，用于其他客户端 (比如浏览器) 认证这个网站的公匙。

客户端通过服务端下发的证书，找到对应的 CA，然后向 CA 验证这个证书是否有效，CA 验证通过之后，下发服务端的公匙。

因为 CA 是权威并且可信的，所以客户端 (浏览器) 信任 CA，而 CA 又信任经过认证的服务端 ，所以客户端 (浏览器) 也信任这个服务端，这就是信任链 (Chain Of Trust)。

而 CA 颁发的数字证书，一般包含这些信息：

简单来说：为了保证公匙是安全的，所以通过数字证书验证公匙。

加密通信

一条完整的HTTPS请求应该是这样的：

1. 客户端 (浏览器) 发起 HTTP 请求，请求连接服务端，发送支持的加密通信协议 (和版本)，并且生成一个随机数，后续用于生成"对话密钥"。

2. 服务端确认加密通信协议 (和版本)，同时也生成一个随机数，后续用于生成"对话密匙"，并且将 CA 颁发的数字证书，一起发送给客户端。

3. 客户端收到数字证书后，检测内置的"受信任的根证书颁发机构"，查看解开数字证书的公匙是否在。

4. 如果解开数字证书的公匙存在，则使用它解开数字证书，得到正确的服务器公匙，同时再次生成一个随机数，用于服务器公匙加密，并发送给服务器。

5. 此时本地和服务器同时将三个随机数，根据约定的加密方法进行加密，各自生成本次会话的所使用的同一把 "会话密匙" 。

6. 到这里，认证阶段已经完毕，数据传输从 非对称加密 换成了 对称加密 (因为考虑到性能)，接下来所有的数据传输都是使用HTTP协议进行传输，只不过使用了 "会话密匙" 来加密内容。

见下图：

证书（Digital certificate）

那么什么是证书呢？

证书中包含什么信息

• 证书信息：过期时间和序列号

• 所有者信息：姓名等

• 所有者公钥

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

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

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

中间人攻击

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

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

为了回答这个问题，需要引入数字签名(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的随机性不受任意一方的影响。

除了使用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

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

性能

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.

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

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

通过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 the premaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.

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 ispartitioned 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握手细节

Source: https://cipherstuff.wordpress.com/

• HTTPS
• http
• 证书