【HTTP】HTTPS TLS 1.2

阿东 • 2023-01-02 • 云技术社区 • 277 阅读

【HTTP】HTTPS TLS 1.2

HTTPS 概念

在个人过去的读书笔记中已经介绍过一次，在这一篇文章中介绍了HTTP1.1的缺点，以及SSL、TLS的历史，之后介绍了有关SSL加密的主要加密方案：公开密钥加密 和 共享密钥加密，最后简单介绍了HTTPS的交互过程，但是书中的过程比较粗，这节我们讲细一点点。

相关文章：[《图解HTTP》 - HTTPS]

本部分会简化介绍重复的部分，补充笔记中没有完善的细节。

这些内容比较八股又干又硬，建议仔细阅读消化。

如何定义“安全”

定义安全靠的是下面几点：

完整性：也叫做数据一致性，指的是传输过程自出发到接受的信息是一致的。机密内容可以被黑客替换或者删除添加，一旦被接受并且核验通过，会带来大问题。
机密性：对于数据保密之后，只有信任的对象可以访问，其他人哪怕拿到保密信息，也无法识别出里面的内容。
身份认证：身份认证需要明确的证实对方身份，比如报警的时候要求警察出示身份证据，并且看到盖章许可文件才允许进入，不然黑客冒充的，不管怎么防都没有用。
不可否认：指的是发生的事情不能进行诋毁，某一项操作必要在通信完成之后产生一定影响。否则就是类似访问一个看起来极其逼真的网站但是却是一个空壳，空壳后面直接把你的个人信息套走。

HTTPS 解决的问题

HTTPS 解决了什么问题？我们介绍HTTP的主要问题，以及如何解决这些问题的。

HTTP的主要问题：

信息加密：保证敏感信息不会被窃取。
身份校验：数据完整性保证，数据无法篡改，篡改之后无法正常使用。
身份证书：证明服务端是真实具备公信力的。

如何解决这些问题：

信息加密：使用双层加密机制，连接使用非对称加密，同时在连接之后使用对称加密，双保险的混合加密保证安全。
摘要算法：保证数据的完整性，TLS协议主要推荐使用SHA-2“集合”下面的加密算法，相当于给数据生成一个解锁指纹。
身份证书：服务器公钥放入数字证书，自己再使用私钥再加密一遍进行传输，防止被人冒充。

除了上面三点之外，还有一点“不可否认“，但是严格意义上并不是HTTPS本身的“功劳”：

不可否认：CA证书颁发机构本身具备权威及公信力，一旦服务端被声明存在，那就是一定存在。

HTTP和HTTPS的区别

HTTP是明文传输，在传输一些敏感信息的时候可能存在窃取信息的情况。
HTTP连接相对效率更高，因为它只需要三次握手就是完成连接操作，而TLS/SSL需要多加入四次握手才能完成连接。HTTPS 整体需要耗费更多的连接时间。
HTTP的端口默认是80，SSL默认端口为443。
HTTPS客户端发送公钥需要向CA申请数字证书签名，保证公钥安全传输到客户端。

SSL/TLS 历史

关联：[《图解HTTP》 - HTTPS] #SSL/TLS历史

可以直接阅读笔记的“SSL/TLS历史”部分，个人在笔记中对于SSL/TLS之间的关系，以及SSL/TLS进化历史做了一个概述，当然这些内容也可以直接去“维基百科”看相关介绍，里面有更加专业和权威的解释。

TLS含义

TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

浏览器建立SSL协议连接，实际上就是使用多个子加密协议组合，最终选择合适的加密算法进行数据安全传输，这种算法组合本身被叫做“密码套件”。

此外TLS 的密码套件命名看起来很长，但是实际上非常规范，格式很固定。基本的形式是“密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”。

比如：ECDHE-RSA-AES256-GCM-SHA384 所表示的含义为：

“握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。

数字加密历史

数字加密的是在计算机出现以及专业的密码机出现之后诞生，但是实际上密码学有了上千年历史，下面我们依照《HTTP权威指南》中14.2节的介绍大致回顾数字加密历史。

本部分为了解数字加密的技术和术语，如果已经了解了或者不感兴趣可以直接跳过。

数字加密的发展大致经历了下面的过程：

浏览器的Security的CA证书中，也可以看到类似结构：最上层Root是根证书，GlobaSync 属于中间证书，最底层是具体服务器的证书。

这个层层信任是咋个信任法？其实也挺简单的，那就是上级持有下一级认证的公钥，先验根证书，然后从根证书拿到下一级证书的公钥，往下找中间证书层层认证。

我们以B站的校验过程为例：

首先待验证的网站是 bilibili.com，首先找到上级证书GlobaSIgn RSA SSL CA 2018，再找GlobaSIgn RSA SSL CA 2018它的上级证书 GlobaSign Root CA - R1，这个证书是没有上级的，所以可以认为是根证书。
既然GlobaSign Root CA - R1是根证书，那么一般情况下浏览器或者操作系统会内置证书，如果发现内置证书，比如下面就会取出GlobaSign Root CA - R1的公钥，验证GlobaSIgn RSA SSL CA 2018是否可信，如果验证通过，说明GlobaSIgn RSA SSL CA 2018这个中间CA是可以信任的。
既然GlobaSIgn RSA SSL CA 2018是可以信任的，那么也同样取出公钥认证bilibili.com是否合规。

可以看到B站的认证体系有不少年头了。

整个CA认证体系最终形成一条信任链条，可以证明网站是合法的了。

从上面的图可以看出，为了验证CA的合法性，会从上级一路向下去验证合法性。另外，如果我们自己捏造自证证书注册到操作系统内（Linux利用OpenSSL命令），用浏览器打开会发现这个证书是不会受到Google浏览器信任的（因为浏览器不承认），并且会提示“此网站不受信任”。

证书具体认证过程

证书认证包含两种情况，一种是客户端认证CA证书的流程，另一种是CA证书自证流程。

客户端认证CA证书的流程这里直接放一张小林做的图，非常直观的展示了CA如何配合信息加密完成整个HTTPS加密传输。个人为了方便记忆，抽象的步骤如下：

服务器注册公钥到CA。
CA私钥加密对于服务器公钥数字签名颁发数字证书。
客户端收到数字证书，使用CA公钥（浏览器内置）解密。然后使用数字签名验证是否存在篡改。
通过数字证书取到服务器公钥，使用服务器公钥进行非对称加密。

然后是服务器自证过程，前面提到CA 证书是多层嵌套的自认证体现，为了保证CA证书的安全，根证书是CA认证的起点也是最核心的一环，以B站的证书为例，整个认证的体系如下：

操作系统或者浏览器认证顺序：内置证书 -> GlobalSign Root CA -> GlobalSign RSA OV SSL CA 2018 -> *.blibli.com

为什么非对称加密之后，还需要使用摘要算法计算出一个哈希值？

其实非对称加密足以保证安全了，加上CA证书基本可以万无一失，而使用摘要算法计算哈希值，实际上是考虑导效率问题，因为内容长度的匹配比较耗费性能，而哈希可以是固定长度的唯一值，哈希值匹配的效率要高出很多。

此外非对称加密可以加密的消息体长度有上限（public key length in bits / 8 - 11），否则会报错，所以必须先hash保证定长结果。

CA证书的格式以及标准

CA证书当然并不是直接给服务器私钥上套个签名就完事了，CA的证书格式有着极其严格的规范和要求，下面是CA证书主要包含的信息：

• 对象的名称（人、服务器、组织等）；

• 过期时间；

• 证书发布者（由谁为证书担保）；

• 来自证书发布者的数字签名。

虽然CA证书在刚面世的时候没有严格的全球规范标准，但是随着后续的发展目前TLS1.2被公认的证书格式是X509，

X.509 v3证书

X.509证书字段包含下面的内容：

我们可以通过具备HTTPS安全连接的网站，通过F12的方式查看证书，比如B站的证书信息如下：

证书的弱点

世界上没有绝对安全的事情，CA证书也不例外。CA证书的弱点在于自身的可靠性，比如给不受信任网站颁发受信任的证书，或者给CA证书本身被伪造，那么所有的防护都是一层纸，所有信任链也就不存在了。

这些事情都是过去真实发生过的，感兴趣可以上网查找相关资料。比如很多年前MCS集团用CNNIC签发的中级证书，发行了多个冒充成Google的假证书。于是在2015年4月份，chrome、firefox都宣布不再信任CNNIC的证书，这件事情的影响十分恶劣，后续证书已经被CNNIC整顿并且被替换为合法的网站https://xfcnnic.net.cn/。

那么CA机构是如何解决这签错网站和本身受到污染这两个问题的？

“签错”网站：利用CRL（证书吊销列表，Certificate revocation list）和 OCSP（在线证书状态协议，Online Certificate Status Protocol），及时废止有问题的证书。
CA本身被污染：所有CA全部停止工作，浏览器把被攻克CA拉入黑名单。CA本身被入侵的可能性很低。

传输过程中CA证书被篡改或者被替换，如何进行加密传输认证？

被替换和被篡改CA证书是经常被提到的两个问题，我们来一一解答：

篡改证书

假设证书在传输过程被黑客篡改，黑客是没有CA的公钥的,，因为CA公钥一般再客户端的浏览器内置，自然无法破解签名，如果把数字签名改掉，浏览器收到请求通过验签手段对比解密之后的签名，发现原文不一致，也就自然发现了问题。

证书替换

证书替换还要分为两种情况，一种是自己伪造的证书，另一种是真的骗过CA搞了一份真的证书。

伪造证书这个事情，黑客能干，其实用户自己也能随时干。但是毫无疑问在浏览器以及操作系统，自证的证书的是不受到认可，所以通常情况下客户端收到这些伪造证书都会立马判断出证书被人篡改过的事实。

那如果黑客煞费苦心，真的用合法的另一个网站拿到一份CA认可的证书，直接把证书替换了怎么办？

这时候客户端收到的证书确实是真的证书，也确实会拿到错误的公钥，但是不要忘了数字证书还有被颁发者的其他信息，比如域名是造不了假的，比对一下就出现问题了。

这里可能又会问，CA自己“黑吃黑”，本身被污染了怎么办？不能怎么办，这时候浏览器会把CA拉黑，CA所有的服务也会停止。在国内这么干是找死，而在国外.....你得有本拉登的逃命实力。

CA证书被黑客入侵本身就是互联网地震，这种时候坐着吃瓜就好了、

证书内容

在RFC的TLS1.2的原文当中，有这么一句话：

The certificate type MUST be X.509v3, unless explicitly negotiated

这个X.509 v3 证书是啥？X509V3 是用于TLS1.2 加密的公认标准，它提供了一种标准的方式，将证书信息规范至一些可解析字段中。虽然有的证书机构会有个别字段不一样，但是整体上还是使用X509V3格式。

这里引用一段维基百科的介绍：

X.509 - 维基百科，自由的百科全书 (wikipedia.org)

X.509是密码学里公钥证书的格式标准。X.509证书已应用在包括TLS/SSL在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构CA的签名，也可以是自签名）

HTTPS的主要改进

关于HTTPS的改进我们再次简单回顾之前的内容：

编解码的过程时在 SSL层完成的，HTTP层不需要做出过多的改变，就可以完美兼容HTTPS。
传输由原来的直接通过HTTP传输给TCP，到建立安全连接之后，从HTTP先传输到SSL层进行编码，然后传输到TCP层。
使用双重加密：对称加密算法、非对称加密算法以及通过数字证书保证，防止中间人攻击。
摘要算法：使用SHA-256等长密钥的加密方式，对于数据的完整性保护，一旦被篡改，数据无法通过校验。

HTTPS 简单来说就是在不改动TCP/IP模型的情况下，在应用层和安全层中间加入了一层安全层。

下面时针对HTTP和HTTPS的传输过程对比图：

Application Data 协议

除开上面四个主要协议之外，还有Application Data 协议。

Application Data 协议用在通信阶段，封装了应用层的数据，通过 Record 协议封装之后，再通过 TCP 协议转发出去。

此协议用于握手连接完成之后的数据传输规范，实际上可以看作是SSL和TCP的协议的对接。

TLS1.2 协议握手流程

#HTTPS通信步骤

这里有必要强调是TLS1.2协议握手流程，因为TLS1.3协议对于很多细节和内容进行了简化，这些内容将在后续内容继续介绍。

这里我们填一下在[《图解HTTP》 - HTTPS]的读书笔记中埋下的坑，在这本书中仅仅对于HTTPS传输做了大致的介绍，并没有深入到各个步骤的细节内容，下面就根据每一步来解释更加详细的传输步骤。

首先我们应该明白，HTTPS需要四次握手，一共需要在客户端和服务端之间来回两次，才能确定一个HTTPS的连接是安全的。

这部分内容建议结合WireShark 介绍TLS1.2加密的实验，目前网络上大部分的资料介绍的都是TLS1.2的加密过程。

之前从数字加密的历史以及HTTP到HTTPS的历史以及SSL/TLS的历史梳理了大概。现在我们从RFC协议的规范层面，来看看HTTPS连接是如何定义的。

首先给出RFC中的流程定义，官方给了两个版本，第一个版本包含完整的请求，而第二个版本则是交互步骤中必须经过的过程。

补充：截图完发现 4-START 第四次握手这里是开始，不是结束 =-=。

整个流程还是有点点复杂的，但是拆分成四次握手，记住一些核心步骤并不难理解。

TCP三次握手

TCP三次握手的流程图这里还是用的之前已经画过的：

第一步：客户端主动打开TCB端口，服务器被动打开TCB端口。客户端作为发起方携带一个SYN标志，并且携带一个ISN序号Seq=x，但是需要注意的是第一步的过程这个ISN序号是隐藏传递的（因为没有传递数据），因为如果请求不存在数据的交换则不会被显示。客户端发送SYN命令之后进入设置SYN=1，并且设置自己的状态为SYN-SENT（同步-已发送状态）。
第二步：服务器收到客户端TCP报文之后，也将SYN=1，并且回送一个新的ISN序号ack=x+1，并且将ACK=1表示自己收到了，然后在返回参数回送自己新的序列号表示自己的确认请求Seq=y，将状态设置为SYN-RCVD（同步收到）状态，（表示希望收到的序号为xxxx1522），最后也是指定MSS。
第三步：客户端收到服务器的确认报文之后，还需要向服务端返回确认报文，确认报文的ACK=1，并且回传服务器传递的ISN序号+1（ack = y+1），以及自己的ISN序号+1（Seq = x+1），此时TCP连接进入已连接状态。注意ACK是可以携带数据的，但是如果不携带数据则不消耗序列号。
最后一步：当服务器收到客户端的确认，也进入已连接状态。

经过TCP三次握手连接建立，直到断开连接之前都可以传递数据，TCP 构建之后，则开始进行SSL握手。

HTTPS 第一次握手

有了证书之后，接着是是对上面的数字证书内容做摘要算法生成一个数字签名，然后CA再用自己的私钥给数字证书的摘要套一层私钥加密，最后再交个客户端。

下面是整个数字证书和签名认证的图例：

证书校验过程签名实际前文提到过了，这里简单概括几个关键步骤：

根证书自上到下验证，进一步加强CA证书的可靠性和安全性。
使用CA的公钥解密出证书，然后按照通用的签名算法，对于数字证书做加签比对，任意一方不对等都可以认为请求是否问题的，此时客户端可以拒绝HTTPS通信。
证书信任链，信任链从根证书取出公钥验证下一级证书，直到拿到服务器证书为止。
浏览器内置CA公钥，不经过网路传输，会导致黑客没法做数字证书的手脚。
数字证书认证分为两层，第一层是CA非对称加解密认证，第二层是数字签名形成的“指纹”验证，如果证书有任何改动，指纹都是匹配不上的，如果私钥加密信息被篡改，解开的信息会是客户端无法识别的乱码。

证书验证没问题的情况下，如果服务端上要求Certificate*，客户端也要按照基本要求发送客户端证书+数字签名+客户端公钥，但是这里可以发现有个漏洞，客户端无法证明自己就是自己，为什么会这么说，先别急，我们先看看单向认证如何处理。

我们接着说ECDHE这个复杂的要死的算法，拿数字证书里面的服务端Certificate，取出服务端的随机公钥，注意这里拿到的是非对称加密的公钥，不是密钥交换算法的公钥。

公钥、公钥，非对称加密公钥，椭圆函数曲线公钥，数字证书公钥，客户端证书公钥，哪来那么多公钥！

服务器接着也按照服务端（实际上是ECDHE）的要求，也自己生成一套椭圆曲线的公钥（Client Params），然后用非对称加密的公钥给他加密一遍确保安全，同样发送 ClientKeyExchange传给服务端。

到这一步，客户端此时把两个“半片”钥匙都拿到了，接着就看看服务器能不能知道自己的“暗号”了。

CertificateVerify* （客户端认证）

还记得签名说的服务端的客户端认证么，发送完ClientKeyExchange之后，如果有客户端证书校验，还需要加一步CertificateVerify操作，里面包含了之前交互的所有报文+签名。

这里可能会有疑问，客户端不是有证书么？为啥还要自己再发个指令证明一遍自己是自己，为什么不能像服务器一样放到 ClientKeyExchange里面发给服务器减少交互步骤？

这个问题老外很多年前就提到过，具体看看下面的帖子。这里我把下面的文章回答内容大概看了下，然后按照自己的思路理解一遍：

https://security.stackexchange.com/questions/110087/why-is-certificateverify-message-necessary-why-isnt-client-authentication-don

第一个问题：能够给材料做私钥加密不能证明客户端有对应的证书的私钥。

这里个人举个例子解释一下，比如你在大学上选修课，你上课上到一半想要逃课回寝室打游戏，但是又不能让位置空着，于是你从别的班花钱请了个小弟帮你顶包骗过老师。

这时候老师要怎么证明这个学生看上去是不是不对劲呢？最简单的办法是把这个同学叫起来，问一问他这节课之前讲了哪些内容呀，这种被顶包上去的，一问心里慌了把你供出来了，老师很生气直接说“我的课你也敢逃，那你以后都不用来了，期末成绩直接不及格！”，你心里后悔，要是把之前讲过的课和顶包同学解释一遍，就不会出问题了。

大概就是这么个道理，应该比较形象了吧，嗯。

第二个问题：客户端认证是可选的，和单向认证的相关内容放到一起实际上不太合适，万一哪一天客户端认证火起来就更难办了。

为了不要有过多的双向认证干扰，客户端认证就介绍到这，更多内容可以自行上网搜索。

Change Cipher Spec

做完ECDHE传输之后，我们可以看到目前的情况是这样的，客户端和服务端各自持有 （Client Params） 以及 （Server Params） 这两个公钥，于是它们会开始计算真实的会话密钥。

计算会话密钥之前，有一步随机数生成操作，因为TLS 设计者不信任客户端和服务端任意一方，所以他会要求双方拿着 （Client Params） 以及 （Server Params） 这两个公钥+一顿复杂算法生成出一个随机数，叫做 PreMaster 。

PreMaster实际上依然不是会话密钥，这时候还需要拿到第一次握手传递的 Client Random和 Server Random 在加上PreMaster做PRF（伪随机数函数） 运算，生成最终的MasterKey，也就是会话密钥。

所以会话密钥的最终计算公式如下：

master_secret = PRF(pre_master_secret, "master secret",ClientHello.random + ServerHello.random)

是不是很复杂，很复杂对了，不复杂黑客就闯进来了。这样的会话密钥黑客基本上是破不开的，因为PreMaster 不走网络传输，都是双方内部用固定算法算出来的。

这个工作方式实际上比较像我们前面介绍的密码机，也就是说哪怕拿到密码也破不开，只有密码机认识这一串密码，而生成密码机的机器在客户端和服务端两边放着。

master_secret叫做主密钥，在RFC中规定是一位固定 48 Bit 的随机数。此外，为再一次确保master_secret 安全性（有完没完！！！），master secret 还不是最终密钥（放过我=-=），还需要再次加上加密套件的 摘要算法，比如这里用的是 AES_128GCM，这样就避免了会话密钥被重复计算的隐患。

双方都有了master_secret和派生的会话密钥，客户端就可以发一个 Change Cipher Spec，告诉服务端我的会话密钥生成了，接下来用“那个”做对称加密吧。

Finished

Change Cipher Spec发送完了，然后再发一个“Finished”消息（Encrypted Handshake Message，所以数据摘要），把之前所有发送的数据做个摘要，这时候再用会话密钥加密一下，让服务器做个验证。

为啥还要在做摘要再验一遍，这里应该比较好理解了，因为按照ECDHE密钥交换算法，最后这个摘要肯定是只有服务端解得开的，中间被窃取是不可能被破解的。

同样的，这个指令也是一个“测试”，如果对方解不开，肯定也是存在猫腻的，无形中又多了层安全网。

这时候你是黑客，你一定是？？？你们咋就会话加密了？你们的算法呢？你们的交流呢？咋就开始密文传输呢？

HTTPS 第四次握手

走过万里长征，最后的交互就简单了。服务器收到客户端的回应，注意这时候传过来的已经全是外人看不懂的密文了，我们抓包看到的也是一堆乱码，这时候服务端通过自己生成的会话密钥解一下密文，然后也按照客户端的Change Cipher Spec和Finished来一套，让客户端也确认一下。

两边都核实无误，第四次握手就完成了，可以看到第四次握手是很简单的，简单的确认操作。

最终HTTPS连接构建完成，客户端开开信息上网，服务端安安心心传数据，黑客无可乘之机。

小结

我们遍历了整个HTTPS TLS1.2 的历史发展和设计，可以看到HTTPS本身虽然细节很多，但是掌握大体内容之后并不是特别难，重点部分在于理清对称密钥加密是如何计算，也就是目前主流 ECDHE密钥交换算法的一些大概流程，还有CA数字认证的这一个关键过程。

需要注意的是整个HTTPS的交互过程是非常灵活的，除非某些关键步骤之外，其他的子协议是类似“插件”一般可选的，虽然我们传统意义上认为HTTPS就该是有CA认证，就该有非对称加密和算法，实际上设计上而言这些东西都无关紧要。

从官方给的案例来看就是下的情况：

TLS1.2 简化版本

上面这张图的简化流程可以给大伙比喻成一段话：Hello，你好，请使用密文传输，Over，好的，使用密文传输，Over，哔哔哔哔哔.....，哔哔哔哔哔.......。实际上HTTPS就是通过这一段话不断扩展出来更多细节的。

之所以设置的这么灵活，个人认为是设计者不想把流程设计的那么死，另一方面是由于子协议自身模块化的思想决定了不能把所步骤当成一个整体来看待。

不过话说回来，现实情况是TLS协议本意是灵活扩展，但是TLS1.2经过长达数十年互联网膨胀，已经牵一发而动全身，TLS1.3的升级也因为历史发展问题，不得不对TLS1.2做出让步和妥协。

值得一提的是，这一节HTTPS建立连接的过程没有以RSA作为密钥交换算法介绍，而是介绍现在真正主流的ECDHE（因为RSA在TLS1.3宣布禁止使用RSA算法），这算法很复杂，要真正完全理解需要比较强的数学功底，但是我们跳过数学的部分，重点介绍了在HTTPS中的作用，个人把它形象理解为两个半片钥匙，通过魔法合成魔法门，这三个内容搭配成随机摘要算法的“根”，最后再用“根”生成出强随机和安全性的会话密钥。

还有令我感到亮眼的地方是，密钥交换算法ECDHE在双方各有“暗号”的情况下，会根据暗号生成一个新的难以破解的暗号，这进一步加强了会话密钥的安全。