HTTPS握手过程

Posted 2023-05-02

我很早之前写过一篇关于 HTTP 和 HTTPS 的文章，但对于 HTTPS 介绍还不够详细，只讲了比较基础的部分，所以这次我们再来深入一下 HTTPS，用 实战抓包 的方式，带大家再来窥探一次 HTTPS。

对于还不知道对称加密和非对称加密的同学，你先复习我以前的这篇文章 「硬核！30 张图解 HTTP 常见的面试题」， 本篇文章默认大家已经具备了这些知识。

HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。

所以安全上存在以下三个风险：

HTTP S 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。

[图片上传失败...(image-93bbca-1618813708342)]

TLS 协议是如何解决 HTTP 的风险的呢？

可见，有了 TLS 协议，能保证 HTTP 通信是安全的了，那么在进行 HTTP 通信前，需要先进行 TLS 握手。TLS 的握手过程，如下图：

上图简要概述来 TLS 的握手过程，其中每一个「框」都是一个记录（ record ），记录是 TLS 收发数据的基本单位，类似于 TCP 里的 segment。多个记录可以组合成一个 TCP 包发送，所以 通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延 ，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。

所以可以发现，HTTPS 是应用层协议，需要先完成 TCP 连接建立，然后走 TLS 握手过程后，才能建立通信安全的连接。

事实上，不同的密钥交换算法，TLS 的握手过程可能会有一些区别。

这里先简单介绍下密钥交换算法，因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。

接下来，我们就以最简单的 RSA 密钥交换算法，来看看它的 TLS 握手过程。

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件中包含一对公私钥，其中公钥会在 TLS 握手阶段传递给客户端，私钥则一直留在服务端，一定要确保私钥不能被窃取。

在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息。

我用 Wireshark 工具抓了用 RSA 密钥交换的 TLS 握手过程，你可以从下面看到，一共经历来四次握手：

对应 Wireshark 的抓包，我也画了一幅图，你可以从下图很清晰地看到该过程：

那么，接下来针对每一个 TLS 握手做进一步的介绍。

客户端首先会发一个「 Client Hello 」消息，字面意思我们也能理解到，这是跟服务器「打招呼」。

消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的 随机数（ Client Random）**，这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成 随机数（ Server Random）**。

接着，返回「 Server Hello 」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

可以看到，服务端选择的密码套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

这个密码套件看起来真让人头晕，好一大串，但是其实它是有固定格式和规范的。基本的形式是「 密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法 」， 一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法，第二个单词是约定证书的验证算法。比如刚才的密码套件的意思就是：

就前面这两个客户端和服务端相互「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和使用的密码套件，而且你可能发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。

那这个随机数有啥用呢？其实这两个随机数是后续作为生成「会话密钥」的条件，所谓的会话密钥就是数据传输时，所使用的对称加密密钥。

然后，服务端为了证明自己的身份，会发送「 Server Certificate 」给客户端，这个消息里含有数字证书。

随后，服务端发了「 Server Hello Done 」消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

在这里刹个车，客户端拿到了服务端的数字证书后，要怎么校验该数字证书是真实有效的呢？

在说校验数字证书是否可信的过程前，我们先来看看数字证书是什么，一个数字证书通常包含了：

那数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。

我们用证书来认证公钥持有者的身份（服务端的身份），那证书又是怎么来的？又该怎么认证证书呢？

为了让服务端的公钥被大家信任，服务端的证书都是由 CA （ Certificate Authority ，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

之所以要签名，是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改。

如下图图所示，为数字证书签发和验证流程：

CA 签发证书的过程，如上图左边部分：

客户端校验服务端的数字证书的过程，如上图右边部分：

但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：

对于这种三级层级关系的证书的验证过程如下：

在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书，于是客户端也信任 baidu.com 证书。

总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。

操作系统里一般都会内置一些根证书，比如我的 MAC 电脑里内置的根证书有这么多：

这样的一层层地验证就构成了一条信任链路，整个证书信任链验证流程如下图所示：

最后一个问题，为什么需要证书链这么麻烦的流程？Root CA 为什么不直接颁发证书，而是要搞那么多中间层级呢？

这是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。

客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的 随机数 ( pre-master) ，用服务器的 RSA 公钥加密该随机数，通过「 Change Cipher Key Exchange**」消息传给服务端。

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此， 客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master 。

于是，双方根据已经得到的三个随机数，生成 会话密钥（Master Secret） ，它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

生成完会话密钥后，然后客户端发一个「 Change Cipher Spec 」，告诉服务端开始使用加密方式发送消息。

然后，客户端再发一个「 Encrypted Handshake Message（Finishd） 」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

可以发现，「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

服务器也是同样的操作，发「 Change Cipher Spec 」和「 Encrypted Handshake Message 」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，就用「会话密钥」加解密 HTTP 请求和响应了。

使用 RSA 密钥协商算法的最大问题是不支持前向保密 。因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。

为了解决这一问题，于是就有了 DH 密钥协商算法，这里简单介绍它的工作流程。

客户端和服务端各自会生成随机数，并以此作为私钥，然后根据公开的 DH 计算公示算出各自的公钥，通过 TLS 握手双方交换各自的公钥，这样双方都有自己的私钥和对方的公钥，然后双方根据各自持有的材料算出一个随机数，这个随机数的值双方都是一样的，这就可以作为后续对称加密时使用的密钥。

DH 密钥交换过程中， 即使第三方截获了 TLS 握手阶段传递的公钥，在不知道的私钥的情况下，也是无法计算出密钥的，而且每一次对称加密密钥都是实时生成的，实现前向保密 。

但因为 DH 算法的计算效率问题，后面出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法，关于 ECDHE 握手的过程，将在下一篇揭晓，尽情期待哦。

参考技术A 第一步：客户端会发起一个hello client请求，请求中会携带TLS版本信息、加密套件候选列表、压缩算法候选列表以及一个随机数。
第二步：服务端收到请求以后也会给客户端发一个server hello请求，请求中会告诉客户端它选择的协议版本、加密套件、压缩算法以及一个随机数。
第三步：服务端会给客户端发一个server certificate请求，里面包含服务端的数字证书，用于客户端进行校验。
第四步：服务端会给客户端发一个server hello done告诉客户端信息已发送完毕。
第五步：客户端收到证书以后进行校验获取到服务端的公钥。
第六步：客户端会将自己的数字证书发给服务端用于校验。
第七步：客户端计算出一个随机数pre-master,然后用公钥进行加密发送给服务器端。
第八步：服务端和客户端都根据自己的随机数+对端的随机数+pre-master算出对称密钥，然后再根据对称密钥进行通信。

HTTPS加密(握手)过程

👇👇关注后回复 “进群” ，拉你进程序员交流群👇👇

作者：Marshall3572
链接：https://www.jianshu.com/p/713917b59c17

引言

HTTP是不安全的，只需要设定相应的DNS，做一个中间人攻击，再将修改后的数据返回，就可以达到篡改数据的目的(加入未经许可的广告)。
当我们切换HTTPS时候，运营商的这些小九九就施展不开了，服务端认证不通过，浏览器不会展示相应的页面数据；运营商实施搞的这一套东东也就不能在用户不知情的情况下搞起来了，解决办法是去除相应的受污染的DNS。

安全需求

• 加密（客户端和服务器的对话是私密的，无须担心被窃听）

• 服务端认证（客户端知道它们是在与真正的而不是伪造的服务器通信）

• 客户端认证（服务器知道它们是在与真正的而不是伪造的客户端通信）

• 完整性（客户端和服务器的数据不会被修改）

• 效率（一个运行足够快的算法，一遍低端的客户端和服务器使用）

• 普适性（基本上所有的客户端和服务器都支持这些协议）

• 管理的可扩展性（在任何地方的任何人都可以立即进行安全通信）

• 适应性（能够支持当前最知名的安全方法）

• 在社会上的可行性（满足社会的政治文化需要），要有公众受信能力

在这里最重要的是前边几条

• 数据加密 传输内容进行混淆

• 身份验证 通信双方验证对方的身份真实性

• 数据完整性保护 检测传输的内容是否被篡改或伪造

HTTPS简介

HTTPS(全称：Hypertext Transfer Protocol Secure 超文本传输安全协议)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。

• HTTP：直接通过明文在浏览器和服务器之间传递信息。

• HTTPS：采用 对称加密 和 非对称加密 结合的方式来保护浏览器和服务端之间的通信安全。
  对称加密算法加密数据+非对称加密算法交换密钥+数字证书验证身份=安全

共享密钥加密也称对称密钥加密。采用的是使用相同密钥对报文进行加密解密。
缺点：无法避免被网络监听泄漏密钥的问题。同时对于众多客户端的服务器来说还需要分配和管理密钥，对于客户端来说也需要管理密钥，增加设计和实现的复杂度，同时也降低了通信的效率。
非对称加密，公钥加密只能通过对应的私钥解密，私钥加密只能通过对应的公钥解密。
缺点：公开密钥加密(非对称加密)安全性高，伴随着加密方式复杂，处理速度慢的问题。如果我们的通信都是用公开密钥的方式加密，那么通信效率会很低。
采用非对称加密因为安全性 采用对称加密是因为他加解密速度快
在交换密钥对环节使用公开密钥加密方式（防止被监听泄漏密钥）加密共享的密钥，在随后的通信过程中使用共享密钥的方式使用共享的密钥进行加解密。

认证方式实现

数字证书
数字签名是附加在报文上的特殊加密校验码，可以证明是作者编写了这条报文，前提是作者才会有私钥，才能算出这些校验码。如果传输的报文被篡改，则校验码不会匹配，因为校验码只有作者保存的私钥才能产生，所以前面可以保证报文的完整性。
数字证书认证机构（Certificate Authority CA）是客户端和服务器双方都可信赖的第三方机构。

服务器的运营人员向数字证书认证机构提出证书认证申请，数字证书认证机构在判明申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书（也叫数字证书或证书）后绑定在一起。服务器将这份有数字认证机构颁发的公钥证书发总给客户端，以进行公开密钥加密方式通信。
数据完整性
数字签名是只有信息发送者才能产生的别人无法伪造的一段文本，这段文本是对信息发送者发送信息真实性的一个有效证明，具有不可抵赖性。

报文的发送方从报文文本生成一个128位的散列值（或称为报文摘要活哈希值），发送方使用自己的私钥对这个摘要值进行加密来形成发送方的数字签名。然后这个数字签名将作为报文的附件一起发送给报文的接收方。报文的接收方首先从接收到的原始报文中计算出128位的散列值，再用发送方的公钥来对报文附加的数字签名进行解密。如果两次得到的结果是一致的那么接收方可以确认该数字签名是发送方的，同时确认信息是真实的 。

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。

1. 传统的HTTP协议通信：传统的HTTP报文是直接将报文信息传输到TCP然后TCP再通过TCP套接字发送给目的主机上。

2. HTTPS协议通信：HTTPS是HTTP报文直接将报文传输给SSL套接字进行加密，SSL加密后将加密的报文发送给TCP套接字，然后TCP套接字再将加密后的报文发送给目的主机，目的主机通过TCP套接字获取加密后的报文给SSL套接字，SSL解密后交给对应进程。

SSL

SSL工作在OSI七层模型中的表示层，TCP/IP 四层模型的应用层。
SSL 基于TCP，SSL不是简单地单个协议，而是两层协议；SSL记录协议（SSL Record Protocol）为多种高层协议（SSL握手协议，SSL修改密码参数协议，SSL报警协议）提供基本的安全服务。
HTTP是为Web客户端/服务器交互提供传输服务的，它可以在SSL的顶层运行；SSL记录协议为SSL链接提供两种服务，1. 机密性：握手协议定义了一个共享密钥，用于SSL载荷的对称加密。2. 消息完整性：握手协议还定义了一个共享密钥，它用来产生一个消息认证码（Message Authentication Code，MAC）。

SSL记录协议操作

• 分段 将每个上层消息分解成不大于2^14（16384）位，然后有选择的进行压缩

• 添加MAC 在压缩数据的基础上计算MAC

• 加密 消息加上MAC用对称加密方法加密

• 添加SSL记录头 内容类型（8位），主版本（8位），副版本（8位），压缩长度（16位）
  SSL握手过程

• 第一阶段 建立安全能力 包括协议版本 会话Id 密码构件 压缩方法和初始随机数

• 第二阶段 服务器发送证书 密钥交换数据和证书请求，最后发送请求-相应阶段的结束信号

• 第三阶段 如果有证书请求客户端发送此证书 之后客户端发送密钥交换数据 也可以发送证书验证消息

• 第四阶段 变更密码构件和结束握手协议
  SSL协议两个重要概念，SSL会话，SSL连接；SSL连接是点到点的连接，而且每个连接都是瞬态的，每一个链接都与一个会话关联。SSL会话是一个客户端和一个服务器之间的一种关联，会话由握手协议（Handshake Protocol）创建，所有会话都定义了一组密码安全参数，这些安全参数可以在多个连接之间共享，会话可以用来避免每一个链接需要进行的代价高昂的新的安全参数协商过程。

HTTPS加密请求(一次握手)过程

1. 客户端发起握手请求，以明文传输请求信息，包含版本信息，加密-套件候选列表，压缩算法候选列表，随机数，扩展字段等信息(这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。)

2. 服务端的配置, 采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

• 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 以及证书。(这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。)

• 客户端验证证书的合法性，包括可信性，是否吊销，过期时间和域名。(这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。)

• 客户端使用公匙对对称密匙加密，发送给服务端。(这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。)

• 服务器用私钥解密，拿到对称加密的密匙。(服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。)

• 传输加密后的信息，这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。

• 客户端解密信息，客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

客户端和服务端之间的加密机制

-End-

最近有一些小伙伴，让我帮忙找一些 面试题 资料，于是我翻遍了收藏的 5T 资料后，汇总整理出来，可以说是程序员面试必备！所有资料都整理到网盘了，欢迎下载！

点击👆卡片，关注后回复【面试题】即可获取

在看点这里好文分享给更多人↓↓