【云安全】传输层安全性（TLS）大汇总

什么是TLS

TLS协议

传输层安全性（Transport Layer Security，TLS）是一种广泛采用的安全性协议，旨在促进互联网通信的私密性和数据安全性。TLS 的主要用例是对 web 应用程序和服务器之间的通信（例如，web 浏览器加载网站）进行加密。

TLS 由互联网工程任务组（Internet Engineering Task Force, IETF）提出，协议的第一个版本于 1999 年发布。最新版本是 TLS 1.3，发布于 2018 年。

TLS / SSL

Netscape 开发了名为安全套接字层（Secure Socket Layer，SSL）的上一代加密协议，TLS 由此演变而来。TLS 1.0 版实际上最初作为 SSL 3.1 版开发，但在发布前更改了名称，以表明它不再与 Netscape 关联。由于这个历史原因，TLS 和 SSL 这两个术语有时会互换使用。

SSL/TLS是一个安全通信框架，上面可以承载HTTP协议或者SMTP/POP3协议等。

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS在SSL v3.0的基础上，提供了以下增加内容：

• 1）更安全的MAC算法
• 2）更严密的警报
• 3）“灰色区域”规范的更明确的定义

TLS对于安全性的改进

• 1）对于消息认证使用密钥散列法：TLS使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用（消息认证代码）MAC功能更安全。
• 2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
• 3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
• 4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
• 5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

TLS/HTTPS

HTTPS 是在 HTTP 协议基础上实施 TLS 加密，所有网站以及其他部分 web 服务都使用该协议。因此，任何使用 HTTPS 的网站都使用 TLS 加密。

TLS 加密可以帮助保护 Web 应用程序免受数据泄露和其他攻击。如今，受 TLS 保护的 HTTPS 是网站的标准做法。Google Chrome 浏览器逐渐对非 HTTPS 网站进行打击，其他浏览器也纷纷效仿。

TLS作用

实现的功能有三个主要组成部分：加密、认证和完整性。

• 加密：隐藏从第三方传输的数据。
• 身份验证：确保交换信息的各方是他们所声称的身份。
• 完整性：验证数据未被伪造或篡改。

TLS 如何工作

TLS 连接是通过一个称为 TLS 握手的流程启动的。当用户导航到一个使用 TLS 的网站时，用户设备（也称为客户端设备）和 web 服务器之间开始 TLS 握手。
在 TLS 过程中，用户设备和 web 服务器：

• 指定将要使用的 TLS 版本（TLS 1.0、1.2、1.3 等）
• 决定将要使用哪些密码套件（见下文）
• 使用服务器的 TLS 证书验证服务器的身份
• 握手完成后，生成会话密钥用于加密两者之间的消息
  TLS 握手为每个通信会话建立一个密码套件密码套件是一组算法，其中指定了一些细节，例如哪些共享加密密钥（即会话密钥）将用于该特定会话。TLS 也能在一个未加密的通道上设置匹配的会话密钥，这要归功于一种称为公钥加密的技术。

握手还处理身份验证，其中通常包括服务器向客户端证明其身份。这是通过使用公钥来完成的。公钥是使用单向加密的加密密钥，即任何拥有公钥的人都可以解读使用服务器私钥加密的数据，以确保其真实性，但只有源发送方才可以使用私钥加密数据。服务器的公钥是其 TLS 证书的一部分。

数据完成加密和验明身份后，使用消息身份验证码（MAC）进行签名。接收方然后可以验证 MAC 来确保数据的完整性。这有点像阿司匹林药瓶上的防篡改铝箔；消费者知道没人篡改过他们的药品，因为购买时铝箔完好无损。

TLS 如何影响 Web 应用程序性能

建立TLS链接需要加载时间和计算能力；传输数据之前需要来回通信；占用内存和宝贵的加载时间。
现有的缓解TLS握手延迟的技术：

• TLS 虚假启动（False Start），让服务器和客户端在 TLS 握手完成前开始传输数据；
• 加速 TLS 的技术是 TLS 会话恢复，允许之前通信过的客户端和服务器简化握手过程。

这些改良加速TLS，可以忽略延迟开销。2018发布的TLS 1.3 中的 TLS 握手仅需要一次往返（即来回通信），而不是以前的两次，将握手过程所需时间缩短了几毫秒。如果用户以前已连接过网站，TLS 握手的往返次数为零，从而进一步加快了速度。

什么是SSL

Cloudflare 向所有用户提供免费的 TLS/SSL 证书。任何没有使用 Cloudflare 的用户将必须向一家证书机构获取 SSL 证书，而且往往需要付费，然后在其源服务器上安装证书。

SSL证书和SSL

SSL（通常称为 TLS）是用于加密互联网流量和验证服务器身份的协议。任何具有 HTTPS 网址的网站都使用 SSL/TLS。

SSL 证书使网站能够使用比 HTTP 更加安全的 HTTPS。SSL 证书是托管在网站源服务器中的数据文件。SSL 证书促成了 SSL/TLS 加密，它们含有网站的公钥和网站标识以及相关信息。尝试与源服务器通信的设备将引用此文件，以获取公钥并验证服务器的身份。私钥应保密并妥善保管。

SSL证书如何工作

SSL证书在一个数据文件中包括以下信息：

• 针对其颁发证书的域名
• 证书颁发给哪一个人、组织或设备
• 证书由哪一证书颁发机构颁发
• 证书颁发机构的数字签名
• 关联的子域
• 证书的颁发日期
• 证书的到期日期
• 公钥（私钥为保密状态）
  用于 SSL 的公钥和私钥本质上是用于加密和签署数据的长字符串。使用公钥加密的数据只能用私钥解密。

该证书托管在一个网站的源服务器上，并被发送到任何请求加载该网站的设备上。 大多数浏览器都允许用户查看 SSL 证书：在 Chrome 浏览器中，可以通过点击 URL 栏左侧的挂锁图标来实现。

为什么需要 SSL 证书？

网站需要 SSL 证书，以确保用户数据的安全，验证网站的所有权，防止攻击者创建站点的虚假版本，并且获得用户信任。

加密：SSL/TLS 加密之所以可行，是因为 SSL 证书促成了公钥私钥配对。客户端（例如 Web 浏览器）从服务器的 SSL 证书获取打开 TLS 连接所需的公钥。

身份验证：SSL 证书可验证客户端正在与实际拥有该域的正确服务器进行通信。这有助于防止域欺骗和其他类型的攻击。

HTTPS：对企业而言，HTTPS 网址必须使用 SSL证书，这一点最为重要。HTTPS 是 HTTP 的安全形式，HTTPS 网站是通过 SSL/TLS 加密流量的网站。

除了在传输过程中保护用户数据外，HTTPS 还使站点更值得用户信赖。许多用户不会注意到以 http:// 和 https:// 开头的网址的区别，但大多数浏览器都使用醒目的方式将 HTTP 站点标记为“不安全”，并且尝试为切换到 HTTPS 和增强安全性提供奖励。

SSL协议提供的服务主要有：

• 1）认证用户和服务器，确保数据发送到正确的客户机和服务器；
• 2）加密数据以防止数据中途被窃取；
• 3）维护数据的完整性，确保数据在传输过程中不被改变。

HTTP 与 HTTPS

HTTPS 是支持加密和验证的 HTTP。两种协议的唯一区别是HTTPS 使用 TLS (SSL) 来加密普通的 HTTP 请求和响应，并对这些请求和响应进行数字签名。因此，HTTPS 比 HTTP 安全得多。HTTP 消息主要有两种：请求和响应。在 OSI 模型中（请参阅什么是 OSI 模型？），HTTP 是第 7 层协议。

用户与浏览器交互时，用户浏览器会生成 HTTP 请求。这些 HTTP 请求全部传送到源站服务器或代理缓存服务器，并且服务器将生成 HTTP 响应。HTTP 响应是对 HTTP 请求的回答。

HTTPS 中的 S 代表“安全”。HTTPS 使用 TLS（或 SSL）来加密HTTP 请求和响应，因此在上例中，攻击者看到的不是其文本，而是一堆看似随机的字符。

TLS/SSL 如何加密 HTTP 请求和响应

TLS 使用一种称为公钥加密的技术：密钥有两个，即公钥和私钥，其中公钥通过服务器的 SSL 证书与客户端设备共享。当客户端打开与服务器的连接时，这两个设备使用公钥和私钥商定新的密钥（称为会话密钥），以加密它们之间的后续通信。

然后，所有 HTTP 请求和响应都使用这些会话密钥进行加密），使任何截获通信的人都只能看到随机字符串，而不是明文。

当客户端打开与源站服务器的连接通道时（例如，当用户导航到网站时），拥有与网站 SSL 证书中公钥匹配的私钥可证明此服务器确实是该网站的合法主机。这可以防止或帮助阻止在没有身份验证时可能发生的多种攻击，例如：

• 在途攻击
• DNS 劫持
• BGP 劫持
• 域欺骗
  此外，SSL 证书由签发它的证书颁发机构进行数字签名。这可以确认服务器就是它声称的身份。

如何加密

两种主要的加密是对称加密和非对称加密。非对称加密也称为公钥加密。

在对称加密中，只有一个密钥，所有通信方都使用相同的（秘密）密钥进行加密和解密。在非对称或公钥加密中，有两个密钥：一个用于加密，另一个用于解密。解密密钥是保密的（因此称为“私钥”），而加密密钥是公开的，供任何人使用（因此称为“公钥”）。非对称加密是 TLS（通常称为 SSL）的基础技术。

常用的对称加密算法包括：

• AES
• 3-DES
• SNOW
  常用的非对称加密算法包括：
• RSA
• 椭圆曲线加密

暴力破解攻击是指不知道解密密钥的攻击者试图通过数百万次或数十亿次的猜测来确定密钥。使用现代计算机的暴力破解攻击要快得多，这就是为什么加密必须极其强大和复杂的原因。大多数现代的加密方法，加上高质量的密码，都能抵抗暴力破解攻击，尽管随着计算机的功能越来越强大，它们在未来会变得越来越容易遭受此类攻击。弱密码仍然容易受到暴力破解攻击。

SSL3–TLS1.3的区别

自SSL3以来，协议核心并没有大幅改变。TLS1.0为了迎合使用另一个名称进行了有限的改变，发布TLS1.1的首要目标是为了解决几个安全性问题。TLS1.2引了已验证加密，清理了散列，另外去掉了协议中的硬编码基元。TLS1.3是目前最新协议，有望成为有史以来最安全版本。

SSL3

SSL3于1995年末发布，为了弥补先前协议版本的诸多弱点，SSL3从头开始设计了一套协议，并一直沿用到了最新版本的TLS。

TLS 1.0

TLS1.0于1999年1月发布，与SSL3相比，它有以下的区别：

• 1）这是定义基于标准HMAC的PRF的第一个版本。它将PRF以HMAC-MD5和HMAC-SHA的结合(XOR)实现；
• 2）生成主密钥使用PRF，而不是定制的构造方法；
• 3）verify_data的值基于PRF，而不是定制的构造方法；
• 4）使用官方HMAC作为完整性验证(MAC)。SSL3使用的是更早的、已被废弃的HMAC版本；
• 5）修改填充格式，使其更为可靠。2014年10月，被称为POODLE的攻击暴露了SSL3的填充机制不安全。
• 6）去掉了 FORTEZZA套件。
  协议清理的结果是TS1.0得到了FPS的批准，允许其用于美国政府机构，这是现实中一个非常重要的事件。

TLS1.1

TLS1.1于2006年4月发布。与TLS1.0相比，它有以下的区别：

• 1）CBC加密使用包含在每个TLS记录中的显式Ⅳ。这弥补了Ⅳ可预测的弱点，不然这个弱点后面会被BEAST攻击所利用；
• 2）为了抵抗填充攻击，要求实现使用bad_record_mac警报作为填充问题的响应。不再赞成使用decryption_failed警报。
• 3）这个版本引用包含了TLS扩展(RFC3546)。

TLS1.2

TLS1.2于2008年8月发布。与TLS1.1相比，它有以下的区别：

• 1）添加已验证加密支持；
• 2）添加对HMAC-SHA256密码套件的支持；
• 3）删除IDEA和DES密码套件；
• 4）虽然大部分扩展的实际文档还是在其他地方，但TLS将扩展和协议的主规格说明书进行了集成；
• 5）客户端可以使用一种新的扩展( signature_algorithms)来通报它愿意接受的散列和签名算法。
• 6）当使用TLS1.2套件或者以协商协议是TLS1.2为条件使用之前的套件时，在PRF中使用SHA256代替MD5/SHA1组合。
• 7）允许密码套件定义其自身的PRF；
• 8）使用单一散列代替用于数字签名的MD5/SHA1组合。默认使用SHA256，并且密码套件可以指定其自身使用的散列。签名散列算法以往是由协议强制指定，现在是散列函数式签名结构中的一部分，而且在实施启用中可以选择最佳算法。
• 9）密码套件可以显式指定Finished消息中的verify_data成员的长度。

TLS1.3

TLS 1.3 与之前的协议有较大差异，主要在于：

• 1）相比过去的的版本，引入了新的密钥协商机制 — PSK；
• 2）支持0-RTT数据传输，在建立连接时节省了往返时间；
• 3）废弃了3DES、RC4、AES-CBC等加密组件，废弃了SHA1、MD5等哈希算法；
• 4）ServerHello之后的所有握手消息采取了加密操作，可见明文大大减少；
• 5）不再允许对加密报文进行压缩、不再允许双方发起重协商；
• 6）DSA证书不再允许在TLS 1.3中使用。
  对比旧协议中的不足，TLS1.3确实可以称得上是向前迈了一大步。既避免之前版本出现的缺陷，也减少了TLS握手的时间。
  

总结

来总结下TLS 1.3引入的一些重要改进。

1. 对原有的对称算法列表进行调整，只支持使用带有关联数据的认证加密（AEAD）算法；—增强安全性

2. 以牺牲某些安全属性为代价添加了零RTT（0-RTT）模式，节省了特定场景下应用程序数据的连接建立的往返时间；—减少延迟，提升性能

3. 静态RSA和Diffie-Hellman密码套件已被删除；所有基于公钥的密钥交换机制现在都提供前向保密性；—增强安全性

4. ServerHello之后的所有握手消息都进行加密；—增强安全性

5. 重新设计密钥派生函数，用基于HMAC的密钥提取和密钥扩展函数（HKDF）作原语；—规范密钥生成算法

6. 重组握手状态机使其更加前后一致，并移除了多余的消息；—提升性能

7. 压缩，自定义DHE组和DSA已被删除。—压缩可能带来安全风险已被删除，增强安全性

TLS 的架构

TLS主要分为两层，底层的是TLS记录协议，主要负责使用对称密码对消息进行加密。
上层的是TLS握手协议，主要分为握手协议，密码规格变更协议和应用数据协议4个部分。

• 握手协议负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证，是4个协议中最最复杂的部分。
• 密码规格变更协议负责向通信对象传达变更密码方式的信号
• 警告协议负责在发生错误的时候将错误传达给对方
• 应用数据协议负责将TLS承载的应用数据传达给通信对象的协议。

握手协议（解释1）

握手协议是TLS协议中非常重要的协议，通过客户端和服务器端的交互，和共享一些必要信息，从而生成共享密钥和交互证书。

1. client hello客户端向服务器端发送一个client hello的消息，包含下面内容：
• 可用版本号
• 当前时间
• 客户端随机数
• 会话ID
• 可用的密码套件清单
• 可用的压缩方式清单
可用版本号，可用的密码套件清单，可用的压缩方式清单就是向服务器询问对方支持哪些服务。

2. server hello服务器端收到client hello消息后，会向客户端返回一个server hello消息，包含如下内容：
• 使用的版本号
• 当前时间
• 服务器随机数
• 会话ID
• 使用的密码套件
• 使用的压缩方式
使用的版本号，使用的密码套件，使用的压缩方式是对步骤1的回答。
服务器随机数是一个由服务器端生成的随机数，用来生成对称密钥。

3. 可选步骤:certificate
服务器端发送自己的证书清单，因为证书可能是层级结构的，所以处理服务器自己的证书之外，还需要发送为服务器签名的证书。客户端将会对服务器端的证书进行验证。如果是以匿名的方式通信则不需要证书。

4. 可选步骤:ServerKeyExchange。如果第三步的证书信息不足，则可以发送ServerKeyExchange用来构建加密通道。ServerKeyExchange的内容可能包含两种形式：
• 如果选择的是RSA协议，那么传递的就是RSA构建公钥密码的参数（E，N）。我们回想一下RSA中构建公钥的公式：密文=明文E mod N密文=明文E mod N， 只要知道了E和N，那么就知道了RSA的公钥，这里传递的就是E，N两个数字。具体内容可以参考RSA算法详解
• 如果选择的是Diff-Hellman密钥交换协议，那么传递的就是密钥交换的参数，具体内容可以参考更加安全的密钥生成方法Diffie-Hellman

6. 可选步骤:CertificateRequest。
如果是在一个受限访问的环境，比如fabric中，服务器端也需要向客户端索要证书。
如果并不需要客户端认证，则不需要此步骤。

7. server hello done
服务器端发送server hello done的消息告诉客户端自己的消息结束了。

8. 可选步骤:Certificate
对步骤5的回应，客户端发送客户端证书给服务器

9. ClientKeyExchange还是分两种情况：
• 如果是公钥或者RSA模式情况下，客户端将根据客户端生成的随机数和服务器端生成的随机数，生成预备主密码，通过该公钥进行加密，返送给服务器端。
• 如果使用的是Diff-Hellman密钥交换协议，则客户端会发送自己这一方要生成Diff-Hellman密钥而需要公开的值。具体内容可以参考更加安全的密钥生成方法Diffie-Hellman，这样服务器端可以根据这个公开值计算出预备主密码。

10. 可选步骤:CertificateVerify。
客户端向服务器端证明自己是客户端证书的持有者。

11. ChangeCipherSpec(准备切换密码)。
ChangeCipherSpec是密码规格变更协议的消息，表示后面的消息将会以前面协商过的密钥进行加密。

12. finished(握手协议结束)
    客户端告诉服务器端握手协议结束了。

13. ChangeCipherSpec(准备切换密码)
    服务器端告诉客户端自己要切换密码了。

14. finished(握手协议结束)
    服务器端告诉客户端，握手协议结束了。

15. 切换到应用数据协议
    这之后服务器和客户端就是以加密的方式进行沟通了。

握手协议（解释2）

握手协议如字面所言，是在加密通信之前，对于加密使用的算法套件及加密密钥进行协商，这和在两个陌生人开始聊天前，通常都需要礼节性的握手类似。这个握手协议凝聚了整个密码学的精华，其中的每一步都是经过了密码学严格论证，有很多实现上容易出错的“坑”。为了便于理解，按照先前的比喻，我们先模仿两个陌生人对话的逻辑（这里这两个陌生人可能交流一些 “学习.hub”等私密的话题）来梳理下整个交互过程，同时用黑体字注明了对应的握手协议消息类型。

(1) C（Client）：你好呀，怕别人偷听，我准备用只有我俩能听懂的语言来聊天，你看我会这几种类型语言，你愿意用那种呢？

—ClientHello

(2) S（Server）：你好呀，我波西米亚语比较6，要不我们就用这种？

—ServerHello

(3) S：你谁呀？我就和你讲这么秘密的事情，把你的身份证给我看看？

—CertificateRequest

(4) S：对了，这是我的身份证。

—Certificate

(1) S：为了证明我是我，我把咱两这句话之前的聊天记录签了个名，一并发给你。

—CertificateVerify

(2) S：我这边准备好了，我用波西米亚语把咱两这句话之前的聊天又重说了下，你能听懂吧？

—Finish

(3) C：这是我的身份证。

—Certificate

(4) C：同样为了证明我是我，我也把咱两这句话之前的对话也签了个名，发给你了。

—CertificateVerify

(5) C：我也准备好了，我用波西米亚语把咱两这句话之前的所有聊天对话又重说了下，你能听懂吧？

—Finish

最后，两个人终于商量好了，可以做一些有趣的事了。

又有人问了，那你之前说的0-RTT是啥呢？这里面也没提到啊？这里RTT(Round-Trip Time)是通信往返距离，而0-RTT就是指在客户端通过ClientHello通信时就可以附带传送一些数据。这就像你俩已经聊过天了，在上次聊天中，约定好了以后聊天时使用的方式。在下次聊天时就能直接用商量好的方式来直接聊天，不用再麻烦交换身份证之类的繁文缛节了。

上面的例子可能看起来没啥，大家可能会觉得风轻云淡，但其实这里面暗藏玄机，正所谓静水流深；这个过程中，几乎用全了密码学工具箱的内容，一点微小的错误就可能使安全传输土崩瓦解，我们试着总结梳理如下：

1、 通过ClientHello及ServerHello完成了随机数、加密算法包及证书格式的协商，重点完成了密钥参数的传输

2、 通过Certificate及CertificateVerify应用证书体系及数字签名完成身份认证

3、 通过AEAD对称加密算法，完成握手消息中数据加密

再把水搅浑点，事实上，握手阶段中的一些消息也都是经过加密的，而且在握手阶段使用的加密密钥同应用数据传输时使用的加密密钥是不同的。俗话说，一图胜千言，话不多说，直接看图：

握手阶段中，在ClientHello及ServerHello后，通信的双方已经就加密算法包及参数达成了一致，在这之后的消息TLS 1.3协议也规定需对其进行加密。这也是TLS 1.3协议加强其安全性的一大举措。TLS 1.3协议中设计有专门的密钥计算算法，针对如何生成不同阶段密钥进行了规定。

主密码和预备主密码

步骤8生成了预备主密码，主密码是根据密码套件中定义的单向散列函数实现的伪随机数生成器+预备主密码+客户端随机数+服务器端随机数生成的。
主密码主要用来生成称密码的密钥，消息认证码的密钥和对称密码的CBC模式所使用的初始化向量。

报警协议Alert Protocol

报警协议也如字面含义所示，是用来指示关闭信息和错误信息的，相应的主要包含两大类：关闭警报和错误警报。

记录协议

TLS记录协议主要负责消息的压缩，加密及数据的认证：

消息首先将会被分段，然后压缩，再计算其消息验证码，然后使用对称密码进行加密，加密使用的是CBC模式，CBC模式的初始向量是通过主密码来生成的。
得到密文之后会附加类型，版本和长度等其他信息，最终组成最后的报文数据。

记录协议2

记录层位于TLS内部下层，主要负责验证、分片/重组、加密/解密的任务。大家可能对其中一些概念不熟悉，让我们来解释下各个作用的含义：

a) 加密/解密：这个就比较显而易见了，不做过多解释；

b) 分片/重组：这里的分片不是由于下层协议的帧长度限制的，而是因为解密方需要收完整个record，才能解密。长度过长会导致解密方需要等待更多的RTT，增大延迟，破坏用户体验，因此TLS协议规定length必须小于 2^14字节；

c) 验证：这部分内容涉及比较多，包括报文时序是否满足协议规定，AEAD中的消息认证是否正确，填充是否正确等内容。

身份验证、机密性和完整性

对于服务器身份验证，客户端使用服务器的公钥来加密用于计算密钥的数据。只有当服务器可以使用正确的私钥解密该数据时，它才能生成密钥。
对于客户端身份验证，服务器使用客户端证书中的公钥解密客户端在第5步握手期间发送的数据。使用密钥加密的已完成消息的交换（概述中的步骤7和8 ）确认身份验证已完成。
如果任何身份验证步骤失败，则握手失败并且会话终止。
SSL 或 TLS 握手期间的SSL证书交换是身份验证过程的一部分。SSL证书需由全球信任的CA机构颁发，受浏览器、操作系统和移动端信任。所需证书如下，其中CAx向客户端颁发证书，CAy向SSL 或 TLS 服务器颁发证书：
仅对于服务器身份验证，SSL 或 TLS 服务器需要：
• CA颁发给服务器证书Y
• 服务器的私钥
SSL 或 TLS 客户端需要：
• CA 的 CA 证书Y

如果 SSL 或 TLS 服务器需要客户端身份验证，则服务器通过使用向客户端颁发个人证书的 CA（在本例中为 CA ）的公钥验证客户端的数字证书来验证客户端的身份X。对于服务器和客户端身份验证，服务器需要：
• CA颁发给服务器的个人证书Y
• 服务器的私钥
• CA 的 CA 证书X
和客户端需要：
• CA颁发给客户的个人证书X
• 客户的私钥
• CA 的 CA 证书Y
SSL 或 TLS 服务器和客户端都可能需要其他 CA 证书来形成根 CA 证书的证书链。详情请参阅如何补全SSL证书链

SSL 和 TLS 结合使用对称和非对称加密来确保消息隐私。在 SSL 或 TLS 握手期间，SSL 或 TLS 客户端和服务器同意仅用于一个会话的加密算法和共享密钥。SSL 或 TLS 客户端和服务器之间传输的所有消息都使用该算法和密钥进行加密，确保消息即使被截获也保持私密。SSL 支持范围广泛的加密算法。因为 SSL 和 TLS 在传输共享密钥时使用非对称加密，所以不存在密钥分配问题。

SSL 和 TLS 通过计算消息摘要来提供数据完整性。使用 SSL 或 TLS 确实可以确保数据完整性，前提是您的通道定义中的 CipherSpec 使用指定 CipherSpecs中的表中描述的哈希算法。

密码学基础

1.密码学常用技术

2.对称加密技术

对称密码算法的特点如下：计算速度快。这是对称密码算法最重要的特点。需要解决密钥配送问题。密钥配送问题，在番外篇2中进行了简单介绍多点通讯时需要维护诸多密钥，维护成本比较高无法抵御中间人攻击实际上无论对称密码系统还是非对称密码系统，都无法解决中间人攻击问题。解决此问题需要使用认证技术。

DES
DES算法是1977年美国机构采用的对称加密标准，后被世界各国广泛使用。但是随着计算机计算能力的提供，在1999年DES算法在24小时内便可以被破译，因此目前为了安全起见，DES算法已经不再被用于新的用途。DES算法是一种将64bit的明文加密成64bit密文的对称加密算法。它的密钥长度是64比特，实际上由于每个7比特都设置1位校验比特，因此64比特长的密钥中实际只有56比特。

3DES
由于DES算法已经可以在极短的时间内被暴力破解，为了替代DES算法，3DES算法被开发出来。3DES是为了增加DES算法的强度，将DES重复3次所得到的一种密码算法。

DES算法的实质密钥长度是56比特，因此3DES的密钥长度就是56x3=168比特，分组长度保持不变，依然位64比特。3DES的处理流程并不是进行3次DES加密，而是按照：加密->解密->加密的过程进行处理的。之所以采用这种方式，是为了将3DES兼容DES算法。因为当3DES的三把密钥完全相同时，经过加密->解密->加密流程，实际上相当于经过一次加密，与DES的效果是相同的。也就是说3DES向下兼容DES算法。尽管3DES算法还被银行等机构使用，但是其处理速度比较低，除了特别注重向下兼容性外，已经很少用于新的用途。

AES
AES算法分组长度和密钥长度可以分别以32比特为单位在128比特至256比特的范围内进行选择。不过经常使用的规格是：分组长度位128比特；密钥长度有128比特、192比特、256比特三种。

3.非对称加密技术、公钥密码算法

在对称密码中，由于加密和解密的密钥必须是相同的，因此必须向接收者配送密钥。但是这样会产生密钥配送问题，在密钥配送问题解决方案中，我提到了公钥密钥的方式，那么它又是如何实现的呢？

下面便来介绍密码学中最伟大的发明：公钥密码。用称之为非对称密码算法

• 在对称密码中，加密和解密使用相同的密钥。
• 在公钥密码中，加密和解密使用不同的密钥。只要拥有加密密钥，任何人都可以加密，但是只有拥有解密密钥的人才能解密。

两个人在通讯之前，接收者事先将加密密钥发送给发送者，此加密密钥即使被Eve窃取也无所谓；然后发送者使用接收者的加密密钥对报文进行加密，然后将加密后的密文发送给接收者，此密文即使也被Eve窃取，但是由于此人没有解密密钥，因此仍然无法进行解密。接收者在收到加密报文后，使用解密密钥对报文进行解密。因此我们可以通过公钥密码来解决对称密码中的密钥配送问题。

什么是公钥密码？公钥密码中，密钥分为加密密钥和解密密钥两种。发送者使用加密密钥对报文进行加密，接收者使用解密密钥对报文进行解密，这两把密钥时理解公钥密码的关键。加密密钥和解密密钥的区别如下：发送者只需要加密密钥接收者只需要解密密钥解密密钥不可以被窃听者窃取加密密钥可以被窃听者窃取。

在公钥密码中，加密密钥是可以公开的，因此又被称为公钥(public key)。解密密钥不能公开，只能有自己保管，因此被称为私钥(private key)。一对公钥和私钥是一一对应的，在数学上关系密切，公钥和私钥统称为密钥对。

公钥通信流程

4.密钥配送

在加密通讯过程中，为了提高加解密的速度，绝大多数采用对称加密的方式进行。因为对称加密算法主要是加减异或位运算，而非对称密码算法(公钥密码算法)是指数运算，计算量相比对称密码算法大的惊人。因此在正常通讯流程中都采用对称密码算法。

在对称密码中，加密和解密使用相同的密钥，因此发送者必须把密钥发送给接收者。但是当前安全连接尚未建立，直接发送密钥又无法保证安全，那该怎么办呢？这就是典型的：“密钥配送问题：密钥必须发送但又不同发送”解决密钥配送问题，经常有如下3种方式：
1️⃣ 通过事先共享密钥来确定
2️⃣ 通过Diffie-Hellman密钥交换来解决
3️⃣ 通过公钥密码来解决

5.DH算法

iffie-Hellman密钥交换算法是在1976年由这两个人发明的算法。它可以在不安全的网络中，通过交换一些公开的信息协商出共享密钥，使用此共享密钥建立安全通讯。它实际上并没有直接交换密钥，而是通过数学计算，得出共享密钥。有限域的离散对数问题的复杂度正是支撑DH密钥交换算法的基础。

参考文献

[1] https://www.cloudflare-cn.com/learning/ssl/transport-layer-security-tls/
[2] https://blog.csdn.net/enweitech/article/details/81781405
[3] https://blog.csdn.net/WoTrusCA/article/details/109839209
[4] https://developer.aliyun.com/article/898020
[5] https://zhuanlan.zhihu.com/p/395907216
[6] https://www.zhihu.com/question/399317260