HTTPS的前世今生和原理详解

HTTPS百科：

超文本传输安全协议（常称为HTTP over TLS或HTTP over SSL）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。

HTTP是明文传输的协议，数据很容易被窃听和篡改，并且攻击者很容易冒充客户端和服务端，HTTPS可以解决这两个的安全问题。HTTS仍是HTTP协议，只是在HTTP与TCP之间添加了用于加密数据的TSL/SSL协议。很多其它应用层的协议也采用在传输层之上添加TSL/SSL协议来保证安全，如FTPS、IMAPS。

image

一、加密基础概念

1.1、 对称加密

加密和解密使用的是同一个密钥。加密和解密的双发都需要持有同一个密钥。常见对称加密算法：AES、DES、3DES。

image

1.2、 非对称加密

加密和解密使用的是不同的密钥，加密时使用的密钥称为公钥匙，解密是使用的密钥称为私钥。使用公钥加密的密文只能用私钥解开。公钥可以发布出去使用，但私钥一定不能泄漏。常见的非对称加密算法：RSA、背包算法、ECC。

image

1.3 数字签名

数字签名用于校验数据是否被篡改，即数据是否和原数据是否一致。
数字签名包含签名和验证两个运算。数字签名具有不可抵赖性，签名验证正确后就不能否认。
数字签名一般包含一个自己知道的私钥和一个公开的公钥，与传统的加密不同的是签名时使用私钥，验证签名是使用公钥。

image

二、SSL/TSL的历史

2.1、 SSL 1.0

1994年Netscape提出了SSL协议并制订了SSL协议的原始规范，即SSL1.0。但由于SSL1.0使用的是弱加密算法而受到密码学界的质疑，所以SSL1.0并没有公共发布。

2.2、 SSL 2.0

SSL1.0之后Netscape对SLL协议规范进行了重大改近，并在1995年发布SSL2.0协议。虽然SSL2.0版本被认为是一个相当强大且健壮的协议，但仍存在一些易受攻击的漏洞，所以并没有得到广泛的使用。

2.3、 SSL 3.0

由于SSL2.0的安全问题，Netscape联合哈佛的Paul Kocher等人重新设计了SSL协议，并在1996年发布，即SSL3.0版本，该版本较2.0版本有较大的差别。SSL 3.0协议获得了互联网广泛认可和支持。

2.4、 TSL 1.0

随着互联网的飞速发展，网络安全越来越重要，业界非常迫切的需要一个标准的安全协议，于是IETE接手了SSL协议，并将其更名为TSL（Transport Layer Security Protocol，安全传输层协议，并在1999年发布了TSL1.0版本。
不过TSL1.0于SSL3.0差别并不大（TLS 1.0 内部的协议版本号其实是3.1）。
虽然TSL是SSL的升级，但一些称呼上还存在混淆，所以大家通常将二者统称为SSL/TLS协议。

2.4、 TSL 1.1

TSL1.1于2006年发布，主要是修复了一些漏洞。

2.5、 TSL 1.2

TSL1.2于2008年发布，1.2版本主要移除了一些老旧的加密套件，并引入了 AEAD 加密模式。1.2版本是目前应用最广泛的版本。

2.6、 TSL 1.3

TSL1.3于2018年发布。1.3版本在2014年提出，经4年的反复修改直到第28个草案才于2018年正式纳入标准。
1.3版本相较1.2版本有很大的改动，即增强了安全性也也大大提升了访问速度。主要有以下改动：

1. 完善了 SNI，SNI-多域名扩展
2. 强制使用PFS（完美正向加密），不支持 PFS 的密钥协商算法在 TLS 1.3 规范中被移除了如：RSA、静态 DH、静态 ECDH等
3. 原有的对称加密算法只保留 AES（3DES、RC4 废弃）
4. 增加 CHACHA20 流加密算法
5. 完善初次握手过程

三、密钥协商

在公网通讯时想要保证通信信道的安全，目前来看只有将通信的数据进行加密后可防止窃听、冒充和篡改。

防止窃听：
数据加密后传输的就是加密后的密文，这些密文即使被窃听了但在没有解密的密钥的情况下是得不到真正的内容的。

防冒充和篡改：
通讯的数据加密后传输，在没有加密用的秘钥的情况下时无法构造出合法的数据包的，也就无法冒充或篡改数据。

将通信数据加密后传输可以解决很多的安全问题，但要实现通信的加密最为关键的点在于通信的双发用于加密的密钥怎么协商才能保证密钥不被泄漏和篡改那？密钥协商是HTTPS中最大的难点。

3.1、 使用对称加密

通信时使用对称加密，并且在客户端请求时直接将对称加密的密钥返回给客户端。
但在安全的信道建立起来之前任何传输仍是明文的，使用明文风发密钥毫无安全性可言，并且由对称加密使用同一个密钥，所以第三方在窃听到密钥后即可以窃听和篡改数据也可以冒充客户端和服务端。 所以直接分发对称加密的密钥显然行不通。

3.2、 使用非对称加密

为方便说明这里只看客户端单向向服务端发送数据的情况，服务端向客户端发送数据与其类似。
通信时使用非对称加密，在客户端请求时将公钥放回给客户端。
但返回公钥时仍然是明文传输的，所以公钥还是很容易就会被泄漏，泄漏了公钥后，虽然第三方无在没有密钥的情况下是没法窃听数据或直接冒充服务端，但由于泄漏了公钥第三方还是可以冒充客户端或者进行‘中间人’攻击。
所以单纯使用非对称加密也是行不通的。

'中间人’攻击：

1. 攻击者将服务端返回给客户端的公钥pub_key拦截，然后自己生成一对秘钥公钥pub_key_m和私钥pri_key_m。
2. 攻击者将自己生成的公钥pub_key_m返回给客户端。客户端收到pub_key_m后并不知道已经被拦截，会使用pub_key_m加密后数据后返回给到服务端。
3. 攻击者继续拦截客服端发送给服务端的请求，由于客户端发出的数据是使用pub_key_m进行加密的，也就可以pri_key_m将数据解密，进而窃听到数据。
4. 由于客户端已经拦截到了pub_key，攻击者也可以拦截服务端发送给客户端的请求，冒充为客户端。攻击者就在真实的客户端和服务端之间冒充两者。

3.3、 对称加密与非对称加密结合

只要通信时使用的密钥不泄漏，那么在通信时完全没必要使用非对称加密，毕竟对称加密的效率更高。所以可以在通信正式开始前使用非对称加密来协商出通信时使用的对称加密的密钥，步骤如下：

1. 服务端生成非对称加密的公钥pub_key和私钥pri_key
2. 将pub_key发送给客户端
3. 客户端随机生成一个对称加密的密钥key
4. 客户端使用pub_key对key进行加密生成key'并送给服务端
5. 服务端收到key'后使用私钥pri_key解密得到key
6. 经过上述步骤客户端和服务端就得到协商出来一个用于通信加密的key

虽然对称加密与非对称加密结合可以使我们或得两种的优点，但这样还是无法避免‘中间人’攻击。

3.4、 DH密钥协商

DH密钥协商算法不会直接交互密钥，而是交互用于生产密钥的参数，DH算法基于当前‘无法’对大数进行质数分解来保证即使参数泄漏了，第三方也无法通过参数推导出密钥。
DH算法密钥协商步骤：

1. 客户端发起请求。
2. 服务端收到客户端的请求后生产一个随机数a，并选择一个素数p和整数模n乘法群中的原根g，计算A = g^a mod p，并将A返回给客户端，如：a=6, p=23, g=5有A=5^6 mod 23 = 8。
3. 客户端收到A后，生产一个随机数b，通过A和随机数就可以生产密钥s=A^b mod p，并计算计算B=g^b mod p，然后将B放回给服务端。如：b=15，有s = 8^15 mod 23 = 2，B = 5^15 mod 23 = 19。
4. 服务端收到B后，就可以计算出s = B ^ a mod p。如：s = 19^6 mod 23 = 2。

通过以上步骤客户端和服务端就协商出了密钥s，并且整个过程中没有传输过s。为了防止被破解a和b通常非常大，p 是一个至少 300 位的质数，g一般很小通常是3或者5.
但DH算法的缺点也很明显，DH无法防止冒充，还是会受到中间人攻击。

四、证书

数字证书（digital certificate），又称公开密钥认证（Public key certificate）或身份证书（identity certificate），用来下发公钥匙和证明公钥拥有者的身份。

证书由第三机构颁发用来验证服务提供方的合法性，使用时服务提供方将证书给到客户端，客户端通过特定的机制验证书的合法性，从而信任提供证书的服务端和证书中的公钥。

数字证书以文件的形式存在，证书文件中包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对数字证书自身的数字签名，证书的数字签名用来保证证书没有被篡改。

一般我们向CA申请证书时不用我们我们提供公钥和私钥，CA会给我们分配一个密钥对，并将公钥写到证书中，然后将证书和私钥给我们。

证书有统一的标准，其合法性（证书是否过期、数字签名是否有效、颁发的机构是否可信）通过一定的程序按标准来进行验证，如浏览器会保证HTTPS证书是否是合法的，Linux下openSSL库提供了证书验证功能。

核对证书后若证书可信，就可以使用证书中的公钥对数据进行加密与证书的拥有者进行通信。

HTTPS的证书在扩展字段中包含了域名相关的信息，所以HTTPS的证书在申请的时候CA会严格的校验申请的机构或个人是否真的拥有这个域名。

image

4.1、数字证书认证机构

数字证书认证机构（英语：Certificate Authority，缩写为CA）。证书标准是公开的任何人都可以去制作证书，但自己制作的证书是不受信任的，只有权威的CA机构颁发的证书才被信任。

权威的CA证书审核和部署流程严苛而繁杂，所以权威的根证书的有效期一般在几十年内。
也只有权威的CA的根证书会被各大操作系统支持，将其预制与操作系统内。

4.2、 证书内容

证书一般遵循X.509规范，主要包含以下内容：

• 版本：现在证书基本上都使用V3版本
• 序号：证书的唯一id，在证书吊销时用到，不通的CA颁发的证书序号规则是不相同的
• 主体：拥有证书的机构或人的信息，包括国家、省、城市、组织名称、证书的通用名称等
• 发行者：签发此证书的数字认证机构
• 有效期开始时间：证书开始生效的时间，在这之前证书是无效的
• 有效期结束时间：书有效期结束的时间，有效其过后此后证书不在有效
• 公钥的用途：指定证书上公钥的用途，例如数字签名、服务器验证、客户端验证等
• 公开密钥算法：证书中的公开密钥的算法
• 公开密钥：如果是DH算法那么公钥就是 g^b mod p
• 数字签名：对整个证书的数字签名
• 数字签名算法：包含两个部分，散列算法和签名算法
• 证书指纹：CA使用自己的私钥对证书的签名，用于证书合法性校验
• 证书指纹算法：生成证书指纹签名使用的算法
• 扩展字段：V3版本开始引入，证书特定场景下的扩展信息，如证书的域名就是在扩展字段中

CA生成的证书包含以上内容和一些扩展字段外，还包含CA使用自己的私钥对这些内容进行加密后的密文。在验证证书时使用CA的根证书对秘文进行验证，从而判断证书是否是合法的。

4.3、证书信任链

权威结构使用根证书来签发二级CA证书，二级CA证书可以给其它服务签发证书。但不是所有证书都可以继续签发新的证书，证书使用基础约束扩展来限制证书的签发，我们普通申请到证书基础约束扩展都是False的。查看根证书的基本约束可以看到证书颁发机构为‘是’。

image

根证书并不直接签发服务的证书，只要基于以下两点：

1. CA一个根证书没有那么多精力去签发所有服务证书，试想我们都向一个CA申请证书但不同的国家不通的场景不通的语言一个CA机构是无法搞定的，所以CA使用自己根证书签发二级CA证书将二级证书给到某个机构，由他去代理某个地区的证书签发。
2. 二级证书可以直接自己做升级。比如原来证书只支持RSA签名算法，现在可以支持EDSA算法，那么二级证书可以直接进行升级，而不必等根证书升级，预至与系统的中的根证书升级是非常麻烦的。

上一级证书对下一级证书进行签名，签名值包含在证书中，可以使用上一级证书中的公钥来验证下一级证书的签名值。根证书的签名是自己签的，并且验证签名的公钥包含在根证书中。

image

完整的证书连的关系应该有服务器放回，但有的并没有返回，对于没有放回完整证书连的证书，证书中的扩展字段CA 密钥标识符( Authority Key Identifier)记录了证书的上一个证书，通过该字段获取到上一级中间证书，再从中间证书的该字段中继续向上查找，直到根证书。
服务端最好可以返回证书连，这样可以避免浏览器自己去查找，提示握手速度。服务器返回的证书链并不包含根证书，根证书预至与操作系统内部。

在linux中openssl库会集成根证书。openssl的根证书的存放路径通过‘openssl version -a’查看。

image

校验证书时先根据证书链逐级校验证书的签名，签名校验的最关键的在根证书。根证书预至于操作系统中，CA要将自己的证书预至与各个系统中是非常困难的，所以预支与系统中的根证书是可信的。

回顾一下对于HTTPS的证书来说申请的时候CA会严苛的验证，保证这个域名是属于申请这个证书的机构的。这样攻击者或许可以伪造一个改域名的证书，但伪造的证书的根证书在系统中并不会存在，所以伪造的证书是不会被信任的。这样通过证书链的校验就可以有效的防止服务端被‘冒充’。

经过上面证书数字签名验证只是验证了证书确实是合法的证书，后还要验证证书的有效性，有效性验证主要包括以下字段：

1. 验证证书使用在有效期内
2. 验证证书的扩展
3. 如果是用于https的证书还会验证证书当前的访问的域名与扩展中的域名是否一致
4. 对于一般服务的证书证书中还包含一个公钥，那么还要验证公钥用法扩展、公钥的数字签名和密钥协商。

4.4、证书吊销

验证合法的证书也可能由于种种原因被吊销，如证书的私钥泄漏了、证书错发了等，为了验证证书是否有效引入了证书吊销机制。

4.4.1 OCSP

OSCP是证书提供方提供的证书验证接口，用户通过调用OSCP接口验证证书是否被吊销了。
但OCSP服务可能因为策略或服务故障导致无法访问，这时一般浏览器会选择信任证书，毕竟证书被吊销的情况只是极少数。也有部分CA将OCSP失败后的策略写到证书的扩展字段中，用用户根据扩展字段去做处理。
OSCP方式有自己明显的缺陷，为了验证证书而请求OSCP的同时也将自己在什么时候访问了什么服务也告诉了CA，CA利用我们的访问数据作恶咋办，还有OCSP的接口很慢的话不就拖慢了我们服务的相应数独。为了解决这两个问题各大CA厂商联手推出了CRL方案。

4.4.2 CRL

CRL方案是将被吊销的证书列表定期拉去到本机，一般是几天拉取一次。在校验证书时去本机列表中查找。
CA会在证书的扩展字段中写入CRL更新的地址：

image

CRL也有自己明显的确定，首先CRL是定期拉取的不能保证实时生效，然后CRL的列表一般很大可能达到数M。

4.4.3 CRLSet

CRLSet是chrome自建自用的解决方案。google觉得CRL更新太慢了，每个CA都有自己的CRL并且CRL内容也太多了。于是自己搞了一个CRLSet，将各大CA被吊销的高风险证书添加到CRLSet中，chrome在校验证书时可以去自己CRLSet中校验。
CRLSet只有各个CA吊销的证书的部分，大概包含所有吊销证书的2%。
CRLSet的更新相对快一些，最慢几个小时就会从各个CA中更新一次，CRLSet可以用在需要紧急吊销证书的情况下让吊销快速生效。

CRLSet提供了https://github.com/agl/crlset-tools工具来拉取和校验证书是否在CRLSet中。

可以在chrome://components/中更新chrome的CRLSet

image

五、SSL/TSL握手过程

5.1、 Client Hello

客户端向服务端发送hello请求，里面包含了客户端SSL/TSL的版本、支持的加密套件和一个随机数Random1

image

5.2、 Server Hello

服务端收到客户端的hello后，根据客服端支持的加密套件和自己支持的加密套件选择出后面使用的加密和散列套件并返回给客户端，同时返回的还有服务端生产的一个随机数 Random2

image

5.3、 Certificate

服务端向客户端返回自己的证书，客户端收到证书后通过校验证书来信任服务端，并从证书中获取到证书中的公钥。

image

5.4、 Server Key Exchange

服务端在返回证书后会立即向客户端发送该请求。不过该请求不是必须的，只有选择的加密套件需要额外的参数是才会发送该请求交互参数。
如果密钥协议商算法是DH算法，那么DH的参数就在该请求中返回给客户端，DH算法有以下几种：DHE_DSS、DHE_RSA、ECDHE_ECDSAECDHE_RSA
dh算法会返回dh的参数p、g、dh的公钥和公钥的签名，公钥即g^b mod p，b为服务端的随机数

image

这里g就是0X03，p就是0X0017。

5.5、Server Hello Done

服务端在发送完上述信息后，就会立马发送Server Hello Done，来告知客户端服务端的相关信息已经发送完毕，就等客户端开始做密钥协商了。
客户端在收到该消息后就开始验证证书，协商密钥等工作。

image

5.6、Client Key Exchange

在接受到服务器的Server Hello Done信息之后，客户端会计数出预备主密钥，并将其返回给服务端。

如果使用的是RSA/ECDSA算法，那么发送的就是预备主密钥。
如果使用的是DH算法，那么发送的就是通过之前的参数计数出来的公钥匙，即B（ g^b mod p）服务端在收到B后通过 B ^ a mod p得到第三个随机数。而客户端已经通过s = A b mod 得到了s。

image

到了这里服务端和客户端已经得到了三个随机数，通过之前协商好的加密算法使用这个三个随机数就得到一个对称加密的密钥，后面通信时就使用该密钥。

5.7、 Change Cipher Spec

该请求用于通知对方已经计数出通信用的密钥，接下来的通信都使用该密钥进行。服务端和客户端都会发出该请求，一般是服务端先发出。

5.8、 Finished

在完成上述步骤以后，双发都会发送一个Finished请求给对方，Finished的数据是通过协商好的密钥加密的，以此来验证之前协商好的密钥、协议版本是否是有效的。

image

参考资料：

• SSL/TLS发展历史： http://www.bewindoweb.com/271.html
• SSL与TLS差异：https://www.globalsign.com/en/blog/ssl-vs-tls-difference
• HTTP协议几个版本的比较：https://zhuanlan.zhihu.com/p/37387316
• 对称加密与非对称加密： https://zhuanlan.zhihu.com/p/30573146
• 扫盲 HTTPS 和 SSL/TLS 协议： https://program-think.blogspot.com/2016/09/https-ssl-tls-3.html
• 密钥协商机制： https://www.jianshu.com/p/b1d6996d2f51
• 完全吃透 TLS/SSL： https://juejin.im/post/5b305758e51d4558ce5ea0d9
• 细说 CA 和证书： https://www.barretlee.com/blog/2016/04/24/detail-about-ca-and-certs/