原文作者：UC 国际研发 泽原
写在最前：欢迎你来到“UC国际技术”公众号，我们将为大家提供与客户端、服务端、算法、测试、数据、前端等相关的高质量技术文章，不限于原创与翻译。
一、HTTPS 简介
>> 1.1 什么是 HTTPS <<
HTTPS 称为安全的超文本传输协议，在 HTTP 与 TCP 之间增加了一层安全链路 (SSL/TLS)。(SSL 是 TLS 的前身，在 IETF 将 SSL 标准化后就改名叫 TLS，SSL 的最高版本为 3.0，之后版本为 TLS1.0，TLS1.1，TLS1.2…..)
>> 1.2 为什么要用 HTTPS <<
HTTPS 的诞生是为了解决 HTTP 存在的问题，想知道为什么要用 HTTPS，就要知道 HTTP 存在哪些问题。HTTP 技术的应用非常的广泛，是一个很伟大的技术，但是由于它是明文传输的，所以存在着各种安全性问题：
窃听风险。由于是明文传输，如果网络传输的某个节点被动了手脚，那么传输的内容就可被窃听。
篡改风险。由于是明文传输，在内容被窃听的同时，攻击者可以很容易的篡改传输内容，而 HTTP 本身没有校验报文完整性的能力。
冒充风险。无法验证通讯方的真实身份。
为了解决这些问题就诞生了 HTTPS，通过加密传输来解决窃听风险，再通过摘要校验确保报文没被篡改，另外为每个站点配备证书以确定身份，当然证书还包含了秘钥，摘要算法等信息。
>> 1.3 HTTPS 如何确保传输的安全性 <<
加密算法有非对称加密算法，对称加密算法，摘要算法。由于摘要算法是不可逆算法，无法用于数据传输，非对称加密算法有很高的安全性也是可逆的，但是由于计算非常的耗时 ，如果作为数据传输的加密算法，代价将会非常的高。
而对称加密算法既能满足可逆条件，而且耗时相对非对称加密算法小很多，适合于数据传输。所以 HTTPS 是使用对称加密算法进行数据传输。
为了能将对称加密的秘钥安全的给到客户端，HTTPS 是通过非对称加密算法加密秘钥传输给客户端的。然而，非对称加密的的公钥是明文方式给到客户端的，所以会存在中间人攻击 (介绍) 的情况，为了解决中间人攻击，HTTPS 引入了数字证书。
上面一段介绍看下来，我们发现要进行 HTTPS 传输，需要很多的信息，非对称加密算法用哪种算法？对称加密又用哪种算法？服务端的证书又是什么？客户端跟服务端之间是怎么去协商这些数据的？于是就有了我们经常听到的 TLS 握手，TLS 握手就是为了确定这些变量，从而建立所谓的安全链路。如下是 TLS 握手的一个大概过程：
下面我们通过访问 https://www.baidu.com 的握手过程，讲解一下几个关键环节。
Client Hello
Client Hello 是 TLS 握手的第一步，由客户端发起，主要包含几个信息：
1、客户端支持的最高的 TLS 版本号
2、一个随机数，用于后面对称秘钥导出算法
3、客户支持的加密套件列表
4、拓展信息
Server Hello
1、根据客户端支持的最高协议版本，确定使用的 TLS 版本
2、根据客户端支持的加密套件列表，选择使用的加密套件，也就是确定了秘钥交换算法，数据传输用的对称加密算法等
3、生成一个随机数，用于后面对称秘钥导出算法
Server Certificate
返回服务端的证书，这里是一个证书链，包含了中间证书。
Server Key Exchange
TLS 的握手过程会根据确定加密套件，步骤上会有所区别。
如果加密套件选择的是 DH（或者 ECDHE）作为对称秘钥交换算法，那么对称秘钥是由客户端跟服务端自己导出的，这个时候需要客户端与服务端交互各自生成的公钥，就会有 Server Key Exchange 这一步。
如果选择的是 RSA 算法，那么对称秘钥是由客户端生成一个叫 pre-master key 后加密传输给服务端导出秘钥的，那么就没有 Server Key Exchange 这一步。
Client Key Exchange
如上面所讲，如果交换算法选择的是 DH(或者 ECDHE)，那么这里传输的将是一个公钥，用于服务端生成对称秘钥。
如果交换算法是 RSA，那么这里传输的则是使用服务端公钥加密的 pre-master key。
这一步过后，客户端跟服务端就能导出传输过程中需要的的对称加密秘钥了。
Change Cipher Spec
从上图可以看到，在 Client Key Exchange 后，客户端跟服务端都有一次 Change Cipher Spec 请求。这个步是算法各自根据自己生成的对称秘钥对刚才握手的所有数据的摘要进行加密后传输给对面。一是确保对称算法秘钥的正确性，二是校验握手过程数据是否遭到篡改。
二、证书管理
>> 2.1 什么是证书 <<
上面我们多次提到证书这个词，那么什么是证书呢？证书就是网络通讯中的一种标识身份的文件，主要包含使用者、非对称加密的公钥、颁发者、颁发者的签名、有效期等信息。
>> 2.2 哪些证书是可信任的 <<
证书是标识身份的文件，那么我们怎么确定这个文件是可信任的呢？首先我们来看一下证书是如何生成与验证的：
如上图，生成一个证书的时候，颁发者(图中的签名者)会先用摘要算法计算出摘要值，然后使用自己的私钥对摘要进行签名即加密，然后一并写入证书中。使用者拿到证书后，使用证书中的摘要算法计算出摘要值，然后使用证书中的公钥对签名信息进行解密得到明文(颁发者计算的摘要)，然后对比这两个值，如果这两个值是一样的，则说明该证书内容是没被篡改的。
从上面的内容我们知道了一个证书的生成与验证过程，然而即使我们知道了证书的内容是没有被篡改的，我们也还不能说这个证书就是可信任的，因为有可能这个证书是一个攻击者自己使用自己的秘钥对生成后给到你的。所以我们必须知道这个颁发者 是否是可信任的，为了验证颁发者是可信任的，这里就引入了证书链的概念，如下图：
我们在 1.3 章节的 TLS 握手中提过，服务端下发证书的时候是下发了一个证书链，就是会包含 中间证书，所以我们要确认一个站点证书的颁发者是否是可信任的，就要往上验证颁发者的证书，一层层往上验证。
我们在验证证书链的时候，要验证到哪一层结束呢？
相信很多人都听过 CA，CA 就是数字证书认证机构，是被所有人认可的，系统跟浏览器会默认安装这个证书以及该证书颁发的二级证书等，这些都是可信任的证书，当然，除了这些，用户还可以手工添加自己认为可信任的证书到信任列表，我们在验证证书链的时候，如果验证的证书已经在信任列表里面了，那么我们就认为这个站点证书是可信任的（即使是这样，一些过期的或者算法安全等级不够的，浏览器依然会认为是不安全大的，而发出警告信息）。
如下就是 Chrome 浏览器的信任列表：
>> 2.3 如何撤销证书 <<
出于某些原因，比如秘钥泄密，或者证书的算法已经不安全等等，这个时候需要对证书进行撤销。通信双方都可以根据证书中指定的校验地址对证书链中的每个证书的状态进行校验。目前撤销证书大的方式有两种：
证书吊销列表（CRL），CRL 会定期发布，或每次更新时发布，或通过 HTTP 的方式提供访问，是一个包含了所有撤销证书的名单。这种方式有两个缺点，一是文件会越来越大，二是客户端可能会缓存 CRL 文件而导致没办法立即更新刚撤销的证书。
在线证书状态协议（OCSP），一种可实时检查证书状态的机制。
三、加密套件
>> 3.1 什么是加密套件 <<
在介绍 TLS 握手过程的时候，我们除了说到证书以外，还有一个没解释的名词，就是加密套件。什么是加密套件？如下图：
如上图每一行就是一个加密套件，第一部分为加密套件的名字，后面是对该加密套件内容的介绍。加密套件是确保 HTTPS 安全的基础，主要包含了秘钥交换算法，签名认证算法，对称加密算法，摘要校验算法。
Kx 是密钥交换算法，用于握手中交换对称秘钥时加密秘钥。Au 是签名认证算法，握手过程中需要对握手内容进行签名验证 。Enc 是对称加密算法，握手成功后数据传输所使用的加密算法。Mac 是摘要校验算法，用于确保报文的完整性。图中有些加密套件 Mac=AEAD，这部分加密套件代表对称加密算法本身能确保报文的完整性，不需要摘要算法。
>> 3.2 如何选择加密套件 <<
选择加密套件，主要从安全性跟性能两个方面去考虑，目前主流的秘钥交换算法是 ECDHE，ECDHE 是在 DH 算法上加上了椭圆曲线算法，在性能跟安全性上都有很大的提升。而对称加密算法主流的是 AES 算法的 GCM 模式，GCM 模式支持加解密并行计算，而且在 intel 处理器上有特殊的优化。
好文推荐：
“UC国际技术”致力于与你共享高质量的技术文章
欢迎关注我们的公众号、将文章分享给你的好友
