SSL/TLS 握手过程

引言

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

安全需求

  • 加密（客户端和服务器的对话是私密的，无须担心被窃听）
  • 服务端认证（客户端知道它们是在与真正的而不是伪造的服务器通信）
  • 客户端认证（服务器知道它们是在与真正的而不是伪造的客户端通信）
  • 完整性（客户端和服务器的数据不会被修改）
  • 效率（一个运行足够快的算法，一遍低端的客户端和服务器使用）
  • 普适性（基本上所有的客户端和服务器都支持这些协议）
  • 管理的可扩展性（在任何地方的任何人都可以立即进行安全通信）
  • 适应性（能够支持当前最知名的安全方法）
  • 在社会上的可行性（满足社会的政治文化需要），要有公众受信能力

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

  • 数据加密 传输内容进行混淆
  • 身份验证 通信双方验证对方的身份真实性
  • 数据完整性保护 检测传输的内容是否被篡改或伪造

HTTPS简介

HTTPS(全称：Hypertext Transfer Protocol Secure 超文本传输安全协议)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。
 
HTTP+加密+认证+完整性保护 = HTTPS
  • 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）。

 
HTTPS加密、解密和验证过程

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来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。)
  • 客户端使用公匙对对称密匙加密，发送给服务端。(这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。)
  • 服务器用私钥解密，拿到对称加密的密匙。(服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。)
  • 传输加密后的信息，这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。
  • 客户端解密信息，客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

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

 

 

一 TLS 握手定义和内容 --- What

握手，即 Handshake，在 TLS 的客户端（发送者）和服务端（接受者）之间进行，确保后续的流量（如 HTTP 等）能够在握手建立的安全通道上进行。文中我们使用加密解密学习中经常出现的 Bob 代表客户端，用 Alice 代表服务端。

我们把 Bob 想象成为男生，Alice 是女生。

通俗的讲，就是 Bob伸出手，Alice 也伸出手，传递和协商有效信息。Bob 给 Alice 发出爱的电流，Alice 如果感受到了，那么他们之间就有戏。如果爱的电流电压不匹配（参数不一致），那么 Alice 可能就甩手了，握手就不成功了。

握手-信息交流

TLS 的存在就是为了信息 Message 安全，怎么才能安全呢？

安全首先要求信息加密，那就需要加密算法。加密算法首选对称加密算法，因为高效而且节省资源。这就是说，Alice 和 Bob 使用一个相同的秘钥来加密和解密他们后续要交流的信息。而这个相同的秘钥就是会话秘钥 Session Secret。

这个会话秘钥 需要 Alice 和 Bob 都知道才行，这就需要非对称加密算法去传递这个秘钥。而生成这个会话秘钥 需要三个随机数。

安全还需要 Alice 和 Bob 互相认证对方。一般情景下，Bob 是上网的用户，Alice 是一个公开可访问的网站。那么，Alice 就需要向 Bob 认证自己，告诉自己是合法网站，会使用带签名的数字证书。可以理解为，Alice 需要户口本（数字证书）证明自己合法身份，最好上面标有“未婚”，Bob 才有继续追她的勇气，否则就属于欺骗了。Bob 作为用户，一般不需要向 Alice 认证自己，所以对 Bob 的认证是可选的。也就是说，一般情况下，癞蛤蟆也可以去追白天鹅。

为了更好的理解这个握手的过程，我们首先需要回顾一下 TLS 的分层结构：

SSL/TLS 分层结构

从 TLS 分层结构，我们可以看出 TLS 是由一系列协议组成的。其中，SSL Record Layer 记录层协议是每一个 TLS 报文都需要的，记录层协议头部就包含三个字段：类型、版本和长度，典型的 TLV。

TLS Record Layer head

而 Handshake 协议有很多种类：Client Hello，Server Hello，Server Certificate 等，是握手的核心，下面会重点详细讲到。

Change Cipher Spec 协议是有点独立的协议，也是握手必须的。用于告诉对方，我要使用我们商量好的会话秘钥了。

Alert 协议用于警告双方握手过程没有成功。

二 TLS 握手过程的实现 --- How

Alice 和 Bob 握手是 4 次单方向过程，就是通常所说的 4 次握手。如下图：

Bob: TLS client --- Alice: TLS Server

请注意：一次握手包含多个 Message，比如 Alice 一次握手可能包含 Server Hello、Server Certificate、Server Key Exchange 等，以此类推。

秘钥交换算法主要是 RSA 和 ECDHE ，两者相同的过程是：

  • 服务端交换 服务端随机数 和 服务端证书（包含公钥） 给客户端

两者区别如下：

  • RSA 使用私钥加密和解密，而 ECDHE 使用私钥进行签名
  • RSA 客户端生成预主秘钥，即 Pre Master Key
  • ECDHE 双方交换椭圆参数曲线 Curve

下面介绍的是使用 ECDHE 秘钥交换算法的交互过程。

  1. Bob 第一次握手，传递 Message： Client Hello

经过 Wireshark 抓包的 Client Hello 主要交互内容如下：

Client Hello
  • Version：请注意，协议版本是 TLS 1.2，但是在 Record Layer 的头部 Version 字段是 TLS 1.0 （0x0301），这是因为当 Client Hello 中的版本大于 TLS 1.0 的时候，一些 TLS Server 会失败 fail 掉这个会话。而在 Handshake 的头部，Version 字段设置为了正确的 TLS 1.2。
  • Random：客户端随机数，我们称之为随机数 1，这个随机数是为了后面生成对称的会话秘钥。32 个字节长度。
  • Session ID：可选的字段。如果是第一个新的连接，则此字段没有，仅显示 Session ID Length 为 0。
  • Cipher Suites：加密套件
  • Compression Methods：压缩算法，在加密之前数据压缩。取值 00 代表不压缩。因为会弱化加密数据的安全性，所以在未来的版本已经不推荐使用了。
  • Extension：有很多扩展，比如 SNI 等。

扩展 Extension 就有趣了，比如 Server Name Indication 扩展，简称 SNI。代表 Bob 要访问的网站，Bob 呼喊 Alice 的名字：”你是Alice吗“。

SNI

2. Alice 第一次握手开始了，第一次传递 Message： Server Hello

如现实一样，女生得回应，否则暧昧就进行不下去了。如果女生回应的消息 Message 和男生的差距很大，那么握手也就不成功了。也就是说，如果 Alice 选择的加密套件等参数男生没有提供，那后面就面谈了。

我们发现，Alice 认可了如下信息，即协商成功：

  • Version：确定了 TLS 1.2
  • Cipher Suite：选中了其中一套 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • Compression Methods：不压缩

请注意，如果 Alice 不同意 Bob 的加密套件，无法从众多的加密套件里选择一套自己相中的，那么就需要 Alert 协议来沟通。女孩子没有看到自己想要的三金，肯定不高兴了，就要警告男生。或者，两个人最基础的状态即版本都不一样，男孩好动激进，版本都 TLS 1.1 了，而女孩温婉娴静，版本只有 SSL 3.0，那么女孩也会 Alert 男孩。

如下，客户端发送的版本是 TLS 1.1，而服务端提供的版本是 SSL 3.0，所以服务端就发送了警告 Alert。

这样，两个人握手就失败了 Handshake Failure，如下：

对于上面的加密套件 Cipher Suite，简单说明如下：

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS 是双方通信的协议；
  • ECDHE 和 RSA 都是非对称加密算法，用于传递秘钥，前者 ECDHE 是秘钥交换算法，而 RSA 是签名算法；
  • WITH 是连接字符串；
  • AES-128-GCM 是对称加密算法，也就是后面双方交换应用信息时使用的算法；
  • SHA256 是消息摘要算法

在上面的信息中，Alice 主要向 Bob 传递了如下新的信息：

  • Random：随机数2，也就是前面提到的三个随机数中的 Server Random

3. Alice 第一次握手的第二个传递 Message：Certificate

证书是 Alice 传递给 Bob 自证身份的，里面有 commonName ，截图中是 *.。Alice 说，你看这是我户口本上的名字。

Certificate

服务端 Alice 的证书，颁发自 CA，可以理解为派出所。派出所是公认权威的，可信度高。

4. Alice 第一次握手的第三次传递 Message：Server Key Exchange

使用 ECDHE 算法，需要交换双方的公钥。

5. Alice 第一次握手的第四次传递 Message：Server Hello Done

Server Hello Done

实际上，在实验中，第二、三、四次传递封装在一个包中，如下：

6. Bob 第二次握手开始了，第一个信息：Client Key Exchange

Bob 也要将自己的公钥交给 Alice

7. Bob 第二次握手，传递第二个 Message：Change Cipher Spec

告诉 Alice：我要使用我们商量好的对称秘钥了。请注意，这里是独立的协议，即 Change Cipher Spec Protocol。

8. Bob 第二次握手，传递第三个 Message：

9. Alice 第二次握手，传递如下三个 Message：

New Session Ticket

Change Cipher Spec

Encrypted Handshake Message

以上，我们说的传统意义的四次握手成功。

使用 RSA 秘钥交换算法的四次握手的过程和 ECDHE 过程大体一样，如下：

  • Bob 第一次握手：Bob 请求建立 TSL 连接，发送协议版本、加密套件、一个随机数 client random 以及支持的压缩算法给 Alice；
  • Alice 第一次握手：Alice 根据 Bob 提供的加密套件和自己支持的情况，选择其中的一种加密套件，选定协议版本，加上第二个随机数 server random，和数字证书（其中有公钥），发送给 Bob；
  • Bob 第二次握手：Bob 确认这个数字证书是有效的，并且再生成第三个随机数-预秘钥，即PreMaster Secret。将这个 PreMaster Secret 用服务器发送给它的数字证书中的公钥进行加密发送给服务器；以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值。客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成会话秘钥Session Secret 。

这里，没有发送 ECDHE 算法交换中的消息 Server Key Exchange。

  • Alice 第二次握手：Alice 收到 Bob 的回复，利用自己的私钥进行解密，获得这个随机数，然后通过将前面这三个随机数以及他们协商的加密方式，计算生成一个会话密钥 session secrect。服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

 

posted @ 2022-07-02 17:00  aaron_agu  阅读(385)  评论(0)  编辑  收藏  举报