0 写在前面

这篇文章整理的比较久了，参考了很多文章(记不住链接了)，如果侵犯到大家请联系我删除，谢谢。

https://mp.weixin.qq.com/s?__biz=MjM5NTE0NTY3MQ==&mid=2247504729&idx=1&sn=fa618f216b06f738add01769fbc90658&chksm=a6fe61f19189e8e7291baff1511518ff6d94597c5ee2413201815b0c040153eb19b2b2261b9f&cur_album_id=1612237369238175753&scene=190#rd

https://mp.weixin.qq.com/s/u7eStMiCGxNyEWsYkG8UYg

1 HTTPS/SSL/TLS

1.1 安全性

通常认为，如果通信过程具备了四个特性，就可以认为是“安全”的，这四个特性是：机密性、完整性，身份认证和不可否认。

机密性（Secrecy/Confidentiality）是指对数据的“保密”，只能由可信的人访问，对其他人是不可见的“秘密”，简单来说就是不能让不相关的人看到不该看的东西。比如小明和小红私下聊天，但“隔墙有耳”，被小强在旁边的房间里全偷听到了，这就是没有机密性。我们之前一直用的 Wireshark ，实际上也是利用了 HTTP 的这个特点，捕获了传输过程中的所有数据。

完整性（Integrity，也叫一致性）是指数据在传输过程中没有被篡改，不多也不少，“完完整整”地保持着原状。机密性虽然可以让数据成为“秘密”，但不能防止黑客对数据的修改，黑客可以替换数据，调整数据的顺序，或者增加、删除部分数据，破坏通信过程。比如，小明给小红写了张纸条：“明天公园见”。小强把“公园”划掉，模仿小明的笔迹把这句话改成了“明天广场见”。小红收到后无法验证完整性，信以为真，第二天的约会就告吹了。

身份认证（Authentication）是指确认对方的真实身份，也就是“证明你真的是你”，保证消息只能发送给可信的人。如果通信时另一方是假冒的网站，那么数据再保密也没有用，黑客完全可以使用冒充的身份“套”出各种信息，加密和没加密一样。比如，小明给小红写了封情书：“我喜欢你”，但不留心发给了小强。小强将错就错，假冒小红回复了一个“白日做梦”，小明不知道这其实是小强的话，误以为是小红的，后果可想而知。

第四个特性是不可否认（Non-repudiation/Undeniable），也叫不可抵赖，意思是不能否认已经发生过的行为，不能“说话不算数”“耍赖皮”。使用前三个特性，可以解决安全通信的大部分问题，但如果缺了不可否认，那通信的事务真实性就得不到保证，有可能出现“老赖”。比如，小明借了小红一千元，没写借条，第二天矢口否认，小红也确实拿不出借钱的证据，只能认倒霉。另一种情况是小明借钱后还了小红，但没写收条，小红于是不承认小明还钱的事，说根本没还，要小明再掏出一千元。所以，只有同时具备了机密性、完整性、身份认证、不可否认这四个特性，通信双方的利益才能有保障，才能算得上是真正的安全。

1.2 HTTPS

说到这里，终于轮到今天的主角 HTTPS 出场了，它为 HTTP 增加了刚才所说的四大安全特性。HTTPS 其实是一个“非常简单”的协议，RFC 文档很小，只有短短的 7 页，里面规定了新的协议名“https”，默认端口号 443，至于其他的什么请求 - 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP，没有任何新的东西。也就是说，除了协议名“http”和端口号 80 这两点不同，HTTPS 协议在语法、语义上和 HTTP 完全一样，优缺点也“照单全收”（当然要除去“明文”和“不安全”）。

在用 HTTPS 访问实验环境时 Chrome 会有不安全提示，必须点击“高级 - 继续前往”才能顺利显示页面。而且如果用 Wireshark 抓包，也会发现与 HTTP 不一样，不再是简单可见的明文，多了“Client Hello”“Server Hello”等新的数据包。这就是 HTTPS 与 HTTP 最大的区别，它能够鉴别危险的网站，并且尽最大可能保证你的上网安全，防御黑客对信息的窃听、篡改或者“钓鱼”、伪造。

你可能要问了，既然没有新东西，HTTPS 凭什么就能做到机密性、完整性这些安全特性呢？秘密就在于 HTTPS 名字里的“S”，它把 HTTP 下层的传输协议由 TCP/IP 换成了 SSL/TLS，由“HTTP over TCP/IP”变成了“HTTP over SSL/TLS”，让 HTTP 运行在了安全的 SSL/TLS 协议上（可参考第 4 讲和第 5 讲），收发报文不再使用 Socket API，而是调用专门的安全接口。所以说，HTTPS 本身并没有什么“惊世骇俗”的本事，全是靠着后面的 SSL/TLS“撑腰”。只要学会了 SSL/TLS，HTTPS 自然就“手到擒来”。

图1.1

1.3 SSL/TLS

SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1。

到今天 TLS 已经发展出了三个版本，分别是 2006 年的 1.1、2008 年的 1.2 和2018的 1.3，每个新版本都紧跟密码学的发展和互联网的现状，持续强化安全和性能，已经成为了信息安全领域中的权威标准。

目前应用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都已经被认为是不安全的，各大浏览器即将在 2020 年左右停止支持，所以接下来的讲解都针对的是 TLS1.2。

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

浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）。你可以访问实验环境的 URI“/23-1”，对 TLS 和密码套件有个感性的认识。

图1.2

你可以看到，实验环境使用的 TLS 是 1.2，客户端和服务器都支持非常多的密码套件，而最后协商选定的是“ECDHE-RSA-AES256-GCM-SHA384”。

这么长的名字看着有点晕吧，不用怕，其实 TLS 的密码套件命名非常规范，格式很固定。基本的形式是“密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”，比如刚才的密码套件的意思就是：“握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数”。

1.4 OpenSSL

说到 TLS，就不能不谈到 OpenSSL，它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现 TLS 功能，包括常用的 Web 服务器 Apache、Nginx 等。

OpenSSL 是从另一个开源库 SSLeay 发展出来的，曾经考虑命名为“OpenTLS”，但当时（1998 年）TLS 还未正式确立，而 SSL 早已广为人知，所以最终使用了“OpenSSL”的名字。

OpenSSL 目前有三个主要的分支，1.0.2 和 1.1.0 都将在今年（2019）年底不再维护，最新的长期支持版本是 1.1.1，我们的实验环境使用的 OpenSSL 是“1.1.0j”。

由于 OpenSSL 是开源的，所以它还有一些代码分支，比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL，这些分支在 OpenSSL 的基础上删除了一些老旧代码，也增加了一些新特性，虽然背后有“大金主”，但离取代 OpenSSL 还差得很远。

1.5 小结

1因为 HTTP 是明文传输，所以不安全，容易被黑客窃听或篡改；

2通信安全必须同时具备机密性、完整性、身份认证和不可否认这四个特性；

3 HTTPS 的语法、语义仍然是 HTTP，但把下层的协议由 TCP/IP 换成了 SSL/TLS；

4 SSL/TLS 是信息安全领域中的权威标准，采用多种先进的加密技术保证通信安全；

5 OpenSSL 是著名的开源密码学工具包，是 SSL/TLS 的具体实现。

2 对称加密与非对称加密

2.1 实现机密性

实现机密性最常用的手段是“加密”（encrypt），就是把消息用某种方式转换成谁也看不懂的乱码，只有掌握特殊“钥匙”的人才能再转换出原始文本。

这里的“钥匙”就叫做“密钥”（key），加密前的消息叫“明文”（plain text/clear text），加密后的乱码叫“密文”（cipher text），使用密钥还原明文的过程叫“解密”（decrypt），是加密的反操作，加密解密的操作过程就是“加密算法”。

所有的加密算法都是公开的，任何人都可以去分析研究，而算法使用的“密钥”则必须保密。那么，这个关键的“密钥”又是什么呢？

由于 HTTPS、TLS 都运行在计算机上，所以“密钥”就是一长串的数字，但约定俗成的度量单位是“位”（bit），而不是“字节”（byte）。比如，说密钥长度是 128，就是 16 字节的二进制串，密钥长度 1024，就是 128 字节的二进制串。按照密钥的使用方式，加密可以分为两大类：对称加密和非对称加密。

2.1.1 对称加密

“对称加密”很好理解，就是指加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。

举个例子，你想要登录某网站，只要事先和它约定好使用一个对称密钥，通信过程中传输的全是用密钥加密后的密文，只有你和网站才能解密。黑客即使能够窃听，看到的也只是乱码，因为没有密钥无法解出明文，所以就实现了机密性。

图2.1

TLS 里有非常多的对称加密算法可供选择，比如 RC4、DES、3DES、AES、ChaCha20 等，但前三种算法都被认为是不安全的，通常都禁止使用，目前常用的只有 AES 和 ChaCha20。

AES 的意思是“高级加密标准”（Advanced Encryption Standard），密钥长度可以是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。

ChaCha20 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，纯软件运行性能要超过 AES，曾经在移动客户端上比较流行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错的算法。

对称算法还有一个“分组模式”的概念，它可以让算法用固定长度的密钥加密任意长度的明文，把小秘密（即密钥）转化为大秘密（即密文）。

最早有 ECB、CBC、CFB、OFB 等几种分组模式，但都陆续被发现有安全漏洞，所以现在基本都不怎么用了。最新的分组模式被称为 AEAD（Authenticated Encryption with Associated Data），在加密的同时增加了认证的功能，常用的是 GCM、CCM 和 Poly1305。

把上面这些组合起来，就可以得到 TLS 密码套件中定义的对称加密算法。比如，AES128-GCM，意思是密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM；ChaCha20-Poly1305 的意思是 ChaCha20 算法，使用的分组模式是 Poly1305。你可以用实验环境的 URI“/24-1”来测试 OpenSSL 里的 AES128-CBC，在 URI 后用参数“key”“plain”输入密钥和明文，服务器会在响应报文里输出加密解密的结果。

图2.2

对称加密的缺点之一就是发送者和接收者之间在互相对话之前，一定要有一个共享的密钥。这就会涉及到密钥的交换；与此同时，如果有N个节点，每个节点都要和其余所有N-1个节点进行安全会话，总共大约会有N^2个密钥进行交换，这对密钥管理将会是一个噩梦。

2.1.2 非对称加密

对称加密看上去好像完美地实现了机密性，但其中有一个很大的问题：如何把密钥安全地传递给对方，术语叫“密钥交换”。因为在对称加密算法中只要持有密钥就可以解密。如果你和网站约定的密钥在传递途中被黑客窃取，那他就可以在之后随意解密收发的数据，通信过程也就没有机密性可言了。这个问题该怎么解决呢？

你或许会说：“把密钥再加密一下发过去就好了”，但传输“加密密钥的密钥”又成了新问题。这就像是“鸡生蛋、蛋生鸡”，可以无限递归下去。只用对称加密算法，是绝对无法解决密钥交换的问题的。

所以，就出现了非对称加密（也叫公钥加密算法）。它有两个密钥，一个叫“公钥”（public key），一个叫“私钥”（private key）。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密。

公钥和私钥有个特别的“单向”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。

图2.3

这样非对称加密就避免了对称加密中的密钥交换以及密钥管理的问题。

非对称加密的一个例子具体如下：

图2.4

公钥主要用来加密报文然后将其发往指定的服务，所以公钥也常被称为“编码密钥”。

非对称加密算法的设计要比对称算法难得多，在 TLS 里只有很少的几种，比如 DH、DSA、RSA、ECC 等。

RSA 可能是其中最著名的一个，几乎可以说是非对称加密的代名词，它的安全性基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。

10 年前 RSA 密钥的推荐长度是 1024，但随着计算机运算能力的提高，现在 1024 已经不安全，普遍认为至少要 2048 位。

ECC（Elliptic Curve Cryptography）是非对称加密里的“后起之秀”，它基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE (实际上就是非对称密钥的交换算法，具体见4.2.2)用于密钥交换，ECDSA (本文中未出现)用于数字签名。

目前比较常用的两个曲线是 P-256（secp256r1，在 OpenSSL 称为 prime256v1）和 x25519。P-256 是 NIST（美国国家标准技术研究所）和 NSA（美国国家安全局）推荐使用的曲线，而 x25519 被认为是最安全、最快速的曲线。

ECC 名字里的“椭圆”经常会引起误解，其实它的曲线并不是椭圆形，只是因为方程很类似计算椭圆周长的公式，实际的形状更像抛物线，比如下面的图就展示了两个简单的椭圆曲线。

图2.5

两个简单的椭圆曲线：y^2=x^3+7，y^2=x^3-x

比起 RSA，ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA，而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，对于现在的移动互联网非常有吸引力。实验环境的 URI“/24-2”演示了 RSA1024，你在课后可以动手试一下。

2.1.3 混合加密

看到这里，你是不是认为可以抛弃对称加密，只用非对称加密来实现机密性呢？

很遗憾，虽然非对称加密没有“密钥交换”的问题，但因为它们都是基于复杂的数学难题，运算速度很慢，即使是 ECC 也要比 AES 差上好几个数量级。如果仅用非对称加密，虽然保证了安全，但通信速度有如乌龟、蜗牛，实用性就变成了零。

实验环境的 URI“/24-3”对比了 AES 和 RSA 这两种算法的性能，下面列出了一次测试的结果：

图2.6

可以看到，RSA 的运算速度是非常慢的，2048 位的加解密大约是 15KB/S（微秒或毫秒级），而 AES128 则是 13MB/S（纳秒级），差了几百倍。

那么，是不是能够把对称加密和非对称加密结合起来呢，两者互相取长补短，即能高效地加密解密，又能安全地密钥交换。这就是现在 TLS 里使用的混合加密方式，其实说穿了也很简单：在通信刚开始的时候使用非对称算法，比如 RSA、ECDHE，首先解决密钥交换的问题。然后用随机数产生对称算法使用的“会话密钥”（session key），再用非对称算法公钥加密。因为会话密钥很短，通常只有 16 字节或 32 字节，所以慢一点也无所谓。对方拿到密文后用非对称算法私钥解密，取出会话密钥。这样，双方就通过非对称算法实现了对称密钥的安全交换(用非对称算法保证了会话秘钥的安全)，后续就不再使用非对称加密，全都使用对称加密。

图2.7

这样混合加密就解决了对称加密算法的密钥交换问题，而且安全和性能兼顾，完美地实现了机密性。不过这只是“万里长征的第一步”，后面还有完整性、身份认证、不可否认等特性没有实现，所以现在的通信还不是绝对安全。

注意：

混合加密的关键是交换密钥，而交换密钥的方式有很多。

前面说的使用非对称算法来加密会话密钥传递是一种方式，而TLS里的交换参数再生成密钥是另一种方式，也就是说TLS中并没有使用非对称算法来加密会话密钥，而是交换了算法参数(也就是使用非对称算法加密了算法参数)，让双方各自生成相同(由算法来保证，具体见第7章)的会话密钥。

也就是说只要是通信的双方用非对称算法来安全地生成对称算法密钥，就是混合加密。

2.1.4 小结

1加密算法的核心思想是“把一个小秘密（密钥）转化为一个大秘密（密文消息）”，守住了小秘密，也就守住了大秘密；

2对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换，常用的有 AES 和 ChaCha20；

3非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢，常用的有 RSA 和 ECC；

4把对称加密和非对称加密结合起来就得到了“又好又快”的混合加密，也就是 TLS 里使用的加密方式。

3 数字签名与证书

对称加密和非对称加密，以及两者结合起来的混合加密，实现了机密性。但仅有机密性，离安全还差的很远。

黑客虽然拿不到会话密钥，无法破解密文，但可以通过窃听收集到足够多的密文，再尝试着修改、重组后发给网站。因为没有完整性保证，服务器只能“照单全收”，然后他就可以通过服务器的响应获取进一步的线索，最终就会破解出明文。

另外，黑客也可以伪造身份发布公钥。如果你拿到了假的公钥，混合加密就完全失效了。你以为自己是在和“某宝”通信，实际上网线的另一端却是黑客，银行卡号、密码等敏感信息就在“安全”的通信过程中被窃取了。

所以，在机密性的基础上还必须加上完整性、身份认证等特性，才能实现真正的安全。

3.1 摘要算法

实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。

你可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。换一个角度，也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文。

图3.1

摘要算法实际上是把数据从一个“大空间”映射到了“小空间”，所以就存在“冲突”（collision，也叫碰撞）的可能性，就如同现实中的指纹一样，可能会有两份不同的原文对应相同的摘要。好的摘要算法必须能够“抵抗冲突”，让这种可能性尽量地小。

因为摘要算法对输入具有“单向性”和“雪崩效应”，输入的微小不同会导致输出的剧烈变化，所以也被 TLS 用来生成伪随机数（PRF，pseudo random function）。你一定在日常工作中听过、或者用过 MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它们就是最常用的两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低，不够安全，在 TLS 里已经被禁止使用了。

目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2。SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有 SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要。你可以用实验环境的 URI“/25-1”来测试一下 TLS 里的各种摘要算法，包括 MD5、SHA-1 和 SHA-2。

https://www.chrono.com/25-1?algo=md5

https://www.chrono.com/25-1?algo=sha1

https://www.chrono.com/25-1?algo=sha256

3.2 完整性

摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。

比如，你发了条消息：“转账 1000 元”，然后再加上一个 SHA-2 的摘要。网站收到后也计算一下消息的摘要，把这两份“指纹”做个对比，如果一致，就说明消息是完整可信的，没有被修改。

如果黑客在中间哪怕改动了一个标点符号，摘要也会完全不同，网站计算比对就会发现消息被窜改，是不可信的。

不过摘要算法不具有机密性，如果明文传输，那么黑客可以修改消息后把摘要也一起改了，网站还是鉴别不出完整性。所以，真正的完整性必须要建立在机密性之上，在混合加密系统里用会话密钥加密消息和摘要，这样黑客无法得知明文，也就没有办法动手脚了。这有个术语，叫哈希消息认证码（HMAC）。

图3.2

3.3 数字签名

加密算法结合摘要算法，这样就保证了完整性，我们的通信过程可以说是比较安全了。但这里还有漏洞，就是通信的两个端点（endpoint）。

就像一开始所说的，黑客可以伪装成网站来窃取信息。而反过来，他也可以伪装成你，向网站发送支付、转账等消息，网站没有办法确认你的身份，钱可能就这么被偷走了。

现实生活中，解决身份认证的手段是签名和印章，只要在纸上写下签名或者盖个章，就能够证明这份文件确实是由本人而不是其他人发出的。

你回想一下之前的课程，在 TLS 里有什么东西和现实中的签名、印章很像，只能由本人持有，而其他任何人都不会有呢？只要用这个东西，就能够在数字世界里证明你的身份。

没错，这个东西就是非对称加密里的“私钥”，使用私钥再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认”。

数字签名的原理其实很简单，就是把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的。

图3.3

刚才的这两个行为也有专用术语，叫做“签名”和“验签”。

只要你和网站互相交换公钥，就可以用“签名”和“验签”来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双方的身份。比如，你用自己的私钥签名一个消息“我是小明”。网站收到后用你的公钥验签，确认身份没问题，于是也用它的私钥签名消息“我是某宝”。你收到后再用它的公钥验一下，也没问题，这样你和网站就都知道对方不是假冒的，后面就可以用混合加密进行安全通信了。实验环境的 URI“/25-2”演示了 TLS 里的数字签名，它使用的是 RSA1024。

3.3.1验签问题分析

问题：

在非对称加密算法中，公钥是公开信息，不需要保密，那用私钥加密，公钥解密的话（验证签名过程），其他知道公钥的人也可以解密，怎么确认发送者的身份？

解答：

1.私钥只能被一个人秘密持有，别人是不会有的。

2.任何人都可以用公钥解密私钥加密的数据，那么就证明数据是被对应的私钥加密的。

3.从1/2可以推出，数据必然是私钥持有者发出的，否则公钥必然会解密失败。

4.从3推出，发送者就是私钥持有者，也就确认了发送者的身份。

3.4 数字证书和CA

到现在，综合使用对称加密、非对称加密和摘要算法，我们已经实现了安全的四大特性，是不是已经完美了呢？

不是的，这里还有一个“公钥的信任”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者某宝的公钥呢？

真是“按下葫芦又起了瓢”，安全还真是个麻烦事啊，“一环套一环”的。我们可以用类似密钥交换的方法来解决公钥认证问题，用别的私钥来给公钥签名，显然，这又会陷入“无穷递归”。但这次实在是“没招”了，要终结这个“死循环”，就必须引入“外力”，找一个公认的可信第三方，让它作为“信任的起点，递归的终点”，构建起公钥的信任链。

这个“第三方”就是我们常说的 CA（Certificate Authority，证书认证机构）。它就像网络世界里的公安局、教育部、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）。知名的 CA 全世界就那么几家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它们签发的证书分 DV、OV、EV 三种，区别在于可信程度。

DV 是最低的，只是域名级别的可信，背后是谁不知道。EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）。

不过，CA 怎么证明自己呢？这还是信任链的问题。小一点的 CA 可以让大 CA 签名认证，但链条的最后，也就是 Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。你必须相信，否则整个证书信任链就走不下去了。

图3.4

有了这个证书体系，操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的。

我们的实验环境里使用的证书是“野路子”的自签名证书（在 Linux 上用 OpenSSL 命令行签发），肯定是不会被浏览器所信任的，所以用 Chrome 访问时就会显示成红色，标记为不安全。但你只要把它安装进系统的根证书存储区里，让它作为信任链的根，就不会再有危险警告。

图3.5

3.5 证书体系的弱点

证书体系（PKI，Public Key Infrastructure）虽然是目前整个网络世界的安全基础设施，但绝对的安全是不存在的，它也有弱点，还是关键的“信任”二字。

如果 CA 失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站却是假的。还有一种更危险的情况，CA 被黑客攻陷，或者 CA 有恶意，因为它（即根证书）是信任的源头，整个信任链里的所有证书也就都不可信了。这两种事情并不是“耸人听闻”，都曾经实际出现过。所以，需要再给证书体系打上一些补丁。

针对第一种，开发出了 CRL（证书吊销列表，Certificate revocation list）和 OCSP（在线证书状态协议，Online Certificate Status Protocol），及时废止有问题的证书。

对于第二种，因为涉及的证书太多，就只能操作系统或者浏览器从根上“下狠手”了，撤销对 CA 的信任，列入“黑名单”，这样它颁发的所有证书就都会被认为是不安全的。

3.6 小结

1摘要算法用来实现完整性，能够为数据生成独一无二的“指纹”，常用的算法是 SHA-2；

2数字签名是私钥对摘要的加密，可以由公钥解密后验证，实现身份认证和不可否认；

3公钥的分发需要使用数字证书，必须由 CA 的信任链来验证，否则就是不可信的；

4作为信任链的源头 CA 有时也会不可信，解决办法有 CRL、OCSP，还有终止信任。

4 TLS1.2连接过程解析

4.1 HTTPS建立连接

当你在浏览器地址栏里键入“https”开头的 URI，再按下回车，会发生什么呢？

你应该知道，浏览器首先要从 URI 里提取出协议名和域名。因为协议名是“https”，所以浏览器就知道了端口号是默认的 443，它再用 DNS 解析域名，得到目标的 IP 地址，然后就可以使用三次握手与网站建立 TCP 连接了。

在 HTTP 协议里，建立连接后，浏览器会立即发送请求报文。但现在是 HTTPS 协议，它需要再用另外一个“握手”过程，在 TCP 上建立安全连接，之后才是收发 HTTP 报文。这个“握手”过程与 TCP 有些类似，是 HTTPS 和 TLS 协议里最重要、最核心的部分，懂了它，你就可以自豪地说自己“掌握了 HTTPS”。

4.2 TLS协议的组成

在讲 TLS 握手之前，我先简单介绍一下 TLS 协议的组成。TLS 包含几个子协议，你也可以理解为它是由几个不同职责的模块组成，比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。

记录协议（Record Protocol）规定了 TLS 收发数据的基本单位：记录（record）。它有点像是 TCP 里的 segment，所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个 TCP 包里一次性发出，也并不需要像 TCP 那样返回 ACK。

警报协议（Alert Protocol）的职责是向对方发出警报信息，有点像是 HTTP 协议里的状态码。比如，protocol_version 就是不支持旧版本，bad_certificate 就是证书有问题，收到警报后另一方可以选择继续，也可以立即终止连接。

握手协议（Handshake Protocol）是 TLS 里最复杂的子协议，要比 TCP 的 SYN/ACK 复杂的多，浏览器和服务器会在握手过程中协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。

最后一个是变更密码规范协议（Change Cipher Spec Protocol），它非常简单，就是一个“通知”，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的。下面的这张图简要地描述了 TLS 的握手过程，其中每一个“框”都是一个记录，多个记录组合成一个 TCP 包发送。所以，最多经过两次消息往返（4 个消息）就可以完成握手，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。

图4.1

4.2.1 使用抓包分析TLS1.2

这次我们在实验环境里测试 TLS 握手的 URI 是“/26-1”，看了上面的图你就可以知道，TLS 握手的前几个消息都是明文的，能够在 Wireshark 里直接看。但只要出现了“Change Cipher Spec”，后面的数据就都是密文了，看到的也就会是乱码，不知道究竟是什么东西。

为了更好地分析 TLS 握手过程，你可以再对系统和 Wireshark 做一下设置，让浏览器导出握手过程中的秘密信息，这样 Wireshark 就可以把密文解密，还原出明文。

首先，你需要在 Windows 的设置里新增一个系统变量“SSLKEYLOGFILE”，设置浏览器日志文件的路径，比如“D:\http_study\www\temp\sslkey.log”（具体的设置过程就不详细说了，可以在设置里搜索“系统变量”）。

图4.2

然后在 Wireshark 里设置“Protocols-TLS”（较早版本的 Wireshark 里是“SSL”），在“(Pre)-Master-Secret log filename”里填上刚才的日志文件。

图4.3

设置好之后，过滤器选择“tcp port 443”，就可以抓到实验环境里的所有 HTTPS 数据了。

4.2.2 ECDHE 握手过程

刚才你看到的是握手过程的简要图，我又画了一个详细图，对应 Wireshark 的抓包，下面我就用这个图来仔细剖析 TLS 的握手过程。

图4.4-1

图4.4-2

在 TCP 建立连接之后，浏览器会首先发一个“Client Hello”消息，也就是跟服务器“打招呼”。里面有客户端的版本号、支持的密码套件，还有一个随机数（Client Random），用于后续生成会话密钥。具体如图4.5所示：

图4.5

图4.5的意思就是：“我这边有这些这些信息，你看看哪些是能用的，关键的随机数可得留着”。

作为“礼尚往来”，服务器收到“Client Hello”后，会返回一个“Server Hello”消息。把版本号对一下，也给出一个随机数（Server Random），然后从客户端的列表里选一个作为本次通信使用的密码套件，在这里它选择了“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”。

密钥交换算法：ECDHE

签名算法：RSA

对称加密算法：AES_256_GCM

摘要算法：SHA384

具体如图4.6所示：

图4.6

图4.6的意思就是：“版本号对上了，可以加密，你的密码套件挺多，我选一个最合适的吧，用椭圆曲线加 RSA、AES、SHA384。我也给你一个随机数，你也得留着。”

然后，服务器为了证明自己的身份，就把证书也发给了客户端（Server Certificate）。接下来是一个关键的操作，因为服务器选择了 ECDHE 算法，所以它会在证书后发送“Server Key Exchange”消息，里面是椭圆曲线的公钥（Server Params，也就是服务端使用的非对称加密公钥，公钥保存在了Pubkey中），用来实现密钥交换算法，再加上自己的私钥签名认证。具体如图4.7所示：

图4.7

图4.7的意思是：“刚才我选的密码套件有点复杂，所以再给你个算法的参数，和刚才的随机数一样有用，别丢了。为了防止别人冒充，我又盖了个章。”

之后是“Server Hello Done”消息，服务器说：“我的信息就是这些，打招呼完毕。”这样第一个消息往返就结束了（两个 TCP 包），结果是客户端和服务器通过明文共享了三个信息：Client Random、Server Random 和 Server Params。

客户端这时也拿到了服务器的证书，那这个证书是不是真实有效的呢？这就要用到第 25 讲里的知识了，开始走证书链逐级验证，确认证书的真实性，再用证书公钥验证签名，就确认了服务器的身份：“刚才跟我打招呼的不是骗子，可以接着往下走”。

然后，客户端按照密码套件的要求，也生成一个椭圆曲线的公钥（Client Params，也就是客户端使用的非对称加密公钥，公钥保存在了Pubkey中），用“Client Key Exchange”消息发给服务器。具体如图4.8所示。

图4.8

现在客户端和服务器手里都拿到了密钥交换算法的两个参数（Client Params、Server Params，即非对称加密的公钥），就用 ECDHE 算法一阵算，算出了一个新的东西，叫“Pre-Master”，其实也是一个随机数。

至于具体的计算原理和过程，因为太复杂就不细说了，但算法可以保证即使黑客截获了之前的参数，也是绝对算不出这个随机数的。

现在客户端和服务器手里有了三个随机数：Client Random、Server Random 和 Pre-Master。用这三个作为原始材料，就可以生成用于加密会话的主密钥，叫“Master Secret”。而黑客因为拿不到“Pre-Master”(因为Pre-Master是服务端和客户端各自算的)，所以也就得不到主密钥。

为什么非得这么麻烦，非要三个随机数呢？这就必须说 TLS 的设计者考虑得非常周到了，他们不信任客户端或服务器伪随机数的可靠性，为了保证真正的“完全随机”“不可预测”，把三个不可靠的随机数混合起来，那么“随机”的程度就非常高了，足够让黑客难以猜测。你一定很想知道“Master Secret”究竟是怎么算出来的吧，贴一下 RFC 里的公式：

图4.9-1

这里的“PRF”就是伪随机数函数，它基于密码套件里的最后一个参数，比如这次的 SHA384(如图4.6所示)，通过摘要算法来再一次强化“Master Secret”的随机性。主密钥有 48 字节，但它也不是最终用于通信的会话密钥，还会再用 PRF 扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患，如图4.9-2所示：

图4.9-2

有了主密钥和派生的会话密钥，握手就快结束了。客户端发一个“Change Cipher Spec”，然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。意思就是告诉服务器：“后面都改用对称算法加密通信了啊，用的就是打招呼时说的 AES，加密对不对还得你测一下”。

服务器也是同样的操作，发“Change Cipher Spec”和“Finished”消息，双方都验证加密解密 OK，握手正式结束，后面就收发被加密的 HTTP 请求和响应了。

注意：

Client Params, Server Params是ecdhe算法的公钥(即非对称加密的公钥)，用来算出Pre-Master，不是身份认证的公钥。

使用Client Random、Server Random 和 Pre-Master计算Master Secret。

4.2.3 RSA握手过程

整个握手过程可真是够复杂的，但你可能会问了，好像这个过程和其他地方看到的不一样呢？

刚才说的其实是如今主流的 TLS 握手过程，这与传统的握手有两点不同。

第一个，使用 ECDHE 实现密钥交换，而不是 RSA，所以会在服务器端发出“Server Key Exchange”消息。

第二个，因为使用了 ECDHE，客户端可以不用等到服务器发回“Finished”确认握手完毕，立即就发出 HTTP 报文，省去了一个消息往返的时间浪费。这个叫“TLS False Start”，意思就是“抢跑”，和“TCP Fast Open”有点像，都是不等连接完全建立就提前发应用数据，提高传输的效率。

实验环境在 440 端口（https://www.chrono.com:440/26-1）实现了传统的 RSA 密钥交换，没有“False Start”，你可以课后自己抓包看一下，这里我也画了个图。

图4.10-1

图4.10-2

大体的流程没有变，只是“Pre-Master”不再需要用算法生成，而是客户端直接生成随机数，然后用服务器的公钥(非对称加密的公钥)加密，通过“Client Key Exchange”消息发给服务器。服务器再用私钥解密，这样双方也实现了共享三个随机数，就可以生成主密钥。

一句话描述：RSA中pre_master由客户端生成，采用服务器公钥(非对称加密的公钥)加密pre_master来保证pre_master的安全性。

4.2.4 双向认证

到这里 TLS 握手就基本讲完了。不过上面说的是“单向认证”握手过程，只认证了服务器的身份，而没有认证客户端的身份。这是因为通常单向认证通过后已经建立了安全通信，用账号、密码等简单的手段就能够确认用户的真实身份。

但为了防止账号、密码被盗，有的时候（比如网上银行）还会使用 U 盾给用户颁发客户端证书，实现“双向认证”，这样会更加安全。

双向认证的流程也没有太多变化，只是在“Server Hello Done”之后，“Client Key Exchange”之前，客户端要发送“Client Certificate”消息，服务器收到后也把证书链走一遍，验证客户端的身份。

4.3 小结

1 HTTPS 协议会先与服务器执行 TCP 握手，然后执行 TLS 握手，才能建立安全连接；

2握手的目标是安全地交换对称密钥，需要三个随机数，第三个随机数“Pre-Master”必须加密传输，绝对不能让黑客破解；

自己的理解：握手的最终目的是用来计算出来对称加密所使用的会话密钥的，为达到此最终目的就需要导入该计算所使用的输入参数，握手就是用来交换这些输入参数的，这些输入参数(比如，握手协议Server Key Exchange中携带的椭圆曲线的公钥参数：EC Diffie-Hellman Server Params，以及握手协议Client Key Exchange中携带的椭圆曲线的公钥参数：EC Diffie-Hellman Client Params)虽然都是公开的，但是仍然可以保证密钥的安全交换，具体原因见第7章。 ECDHE算法可以保证在输入参数是公开的情况下，交互的双方都可以计算出相同的Pre-Master(也就是双方自己算自己的)，同时也能保证即使黑客截获了公开的输入参数，也是绝对算不出随机数Pre-Master的，也就是说Pre-Master参数并不是直接在握手中直接进行交换的，交换的仅仅是用来计算Pre-Master的输入参数。

后面继续根据Pre-Master以及其余相关参数(实际上就是Client Random、Server Random)通过PRF伪随机数函数计算出主密钥Master Secret，Master Secret并不是会话密钥，后面可根据Master Secret利用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患(具体参考4.2.2小节)。

3 “Hello”消息交换随机数，“Key Exchange”消息交换“Pre-Master[注释一] ”；

4 “Change Cipher Spec”之前传输的都是明文，之后都是对称密钥加密的密文。

[注释一]在ECDHE算法中Pre-Master 是计算出来的，并不是交换得来的，Key Exchange交换的只是用来计算 Pre-Master 的输入参数；而在RSA中 Pre-Master 确实是进行交换的。

5 TLS1.3特性解析

TLS1.3 的三个主要改进目标：兼容、安全与性能。

5.1 最大化兼容性

由于 1.1、1.2 等协议已经出现了很多年，很多应用软件、中间代理（官方称为“MiddleBox”）只认老的记录协议格式，更新改造很困难，甚至是不可行（设备僵化）。

在早期的试验中发现，一旦变更了记录头字段里的版本号，也就是由 0x303（TLS1.2）改为 0x304（TLS1.3）的话，大量的代理服务器、网关都无法正确处理，最终导致 TLS 握手失败。

为了保证这些被广泛部署的“老设备”能够继续使用，避免新协议带来的“冲击”，TLS1.3 不得不做出妥协，保持现有的记录格式不变，通过“伪装”来实现兼容，使得 TLS1.3 看上去“像是”TLS1.2。那么，该怎么区分 1.2 和 1.3 呢？

这要用到一个新的扩展协议（Extension Protocol），它有点“补充条款”的意思，通过在记录末尾添加一系列的“扩展字段”来增加新的功能，老版本的 TLS 不认识它可以直接忽略，这就实现了“后向兼容”。

在记录头的 Version 字段被兼容性“固定”的情况下，只要是 TLS1.3 协议，握手的“Hello”消息后面就必须有“supported_versions”扩展，它标记了 TLS 的版本号，使用它就能区分新旧协议。其实上一讲 Chrome 在握手时发的就是 TLS1.3 协议，你可以看一下“Client Hello”消息后面的扩展，只是因为服务器不支持 1.3，所以就“后向兼容”降级成了 1.2。

图5.1

TLS1.3 利用扩展实现了许多重要的功能，比如“supported_groups”“key_share”“signature_algorithms”“server_name”等，这些等后面用到的时候再说。

5.2 强化安全

TLS1.2 在十来年的应用中获得了许多宝贵的经验，陆续发现了很多的漏洞和加密算法的弱点，所以 TLS1.3 就在协议里修补了这些不安全因素。

比如：

1伪随机数函数由 PRF 升级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）；

2明确禁止在记录协议里使用压缩；

3废除了 RC4、DES 对称加密算法；

4废除了 ECB、CBC 等传统分组模式；

5废除了 MD5、SHA1、SHA-224 摘要算法；

6废除了 RSA、DH 密钥交换算法和许多命名曲线。

经过这一番“减肥瘦身”之后，TLS1.3 里只保留了 AES、ChaCha20 对称加密算法，分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要算法只能用 SHA256、SHA384，密钥交换算法只有 ECDHE 和 DHE，椭圆曲线也被“砍”到只剩 P-256 和 x25519 等 5 种。减肥可以让人变得更轻巧灵活，TLS 也是这样。

算法精简后带来了一个意料之中的好处：原来众多的算法、参数组合导致密码套件非常复杂，难以选择，而现在的 TLS1.3 里只有 5 个套件，无论是客户端还是服务器都不会再犯“选择困难症”了。

图5.2

这里还要特别说一下废除 RSA 和 DH 密钥交换算法的原因。

上一讲用 Wireshark 抓包时你一定看到了，浏览器默认会使用 ECDHE 而不是 RSA 做密钥交换，这是因为它不具有“前向安全”（Forward Secrecy）。

假设有这么一个很有耐心的黑客，一直在长期收集混合加密系统收发的所有报文。如果加密系统使用服务器证书里的 RSA 做密钥交换，一旦私钥泄露或被破解（使用社会工程学或者巨型计算机），那么黑客就能够使用私钥解密出之前所有报文的“Pre-Master”，再算出会话密钥，破解所有密文。这就是所谓的“今日截获，明日破解”。

而 ECDHE 算法在每次握手时都会生成一对临时的公钥和私钥，每次通信的密钥对都是不同的，也就是“一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的。

所以现在主流的服务器和浏览器在握手阶段都已经不再使用 RSA，改用 ECDHE，而 TLS1.3 在协议里明确废除 RSA 和 DH 则在标准层面保证了“前向安全”。

5.3 提升性能

HTTPS 建立连接时除了要做 TCP 握手，还要做 TLS 握手，在 TLS1.2中(图4.1) 中会多花两个消息往返（2-RTT），可能导致几十毫秒甚至上百毫秒的延迟，在移动网络中延迟还会更严重。

现在因为密码套件大幅度简化，也就没有必要再像以前那样走复杂的协商流程了。TLS1.3 压缩了以前的“Hello”协商过程，删除了“Key Exchange”消息，把握手时间减少到了“1-RTT”，效率提高了一倍。

那么它是怎么做的呢？

其实具体的做法还是利用了扩展。客户端在“Client Hello”消息里直接用“supported_groups”带上支持的曲线，比如 P-256、x25519，用“key_share”带上曲线对应的客户端公钥参数，用“signature_algorithms”带上签名算法。

服务器收到后在这些扩展里选定一个曲线和参数，再用“key_share”扩展返回服务器这边的公钥参数，就实现了双方的密钥交换，后面的流程就和 TLS1.2中(图4.1) 基本一样了。我为 TLS1.3(图5.3) 的握手过程画了一张图，你可以对比 TLS1.2中(图4.1) 看看区别在哪里。

图5.3

除了标准的“1-RTT”握手，TLS1.3 还引入了“0-RTT”握手，用“pre_shared_key”和“early_data”扩展，在 TCP 连接后立即就建立安全连接发送加密消息，不过这需要有一些前提条件，今天暂且不说。

5.4 握手分析

目前 Nginx 等 Web 服务器都能够很好地支持 TLS1.3，但要求底层的 OpenSSL 必须是 1.1.1，而我们实验环境里用的 OpenSSL 是 1.1.0，所以暂时无法直接测试 TLS1.3。

不过我在 Linux 上用 OpenSSL1.1.1 编译了一个支持 TLS1.3 的 Nginx，用 Wireshark 抓包存到了 GitHub 上，用它就可以分析 TLS1.3 的握手过程。

图5.4-1

图5.4-2

在 TCP 建立连接之后，浏览器首先还是发一个“Client Hello”。因为 1.3 的消息兼容 1.2，所以开头的版本号、支持的密码套件和随机数（Client Random）结构都是一样的（不过这时的随机数是 32 个字节）。

图5.5

注意“Client Hello”里的扩展，“supported_versions”表示这是 TLS1.3，“supported_groups”是支持的曲线，“key_share”是曲线对应的参数。

这就好像是说：“还是照老规矩打招呼，这边有这些这些信息。但我猜你可能会升级，所以再多给你一些东西，也许后面用的上，咱们有话尽量一口气说完”。

服务器收到“Client Hello”同样返回“Server Hello”消息，还是要给出一个随机数（Server Random）和选定密码套件。

图5.6

表面上看和 TLS1.2 是一样的，重点是后面的扩展。“supported_versions”里确认使用的是 TLS1.3，然后在“key_share”扩展带上曲线和对应的公钥参数。

服务器的“Hello”消息大概是这个意思：

“还真让你给猜对了，虽然还是按老规矩打招呼，但咱们来个‘旧瓶装新酒’。刚才你给的我都用上了，我再给几个你缺的参数，这次加密就这么定了。”

这时只交换了两条消息，客户端和服务器就拿到了四个共享信息：Client Random 和 Server Random、Client Params 和 Server Params，两边就可以各自用 ECDHE 算出“Pre-Master”，再用 HKDF 生成主密钥“Master Secret”，效率比 TLS1.2 提高了一大截。

在算出主密钥后，服务器立刻发出“Change Cipher Spec”消息，比 TLS1.2 提早进入加密通信，后面的证书等就都是加密的了，减少了握手时的明文信息泄露。

这里 TLS1.3 还有一个安全强化措施，多了个“Certificate Verify”消息，用服务器的私钥把前面的曲线、套件、参数等握手数据加了签名，作用和“Finished”消息差不多。但由于是私钥签名，所以强化了身份认证和和防窜改。

这两个“Hello”消息之后，客户端验证服务器证书，再发“Finished”消息，就正式完成了握手，开始收发 HTTP 报文。

虽然我们的实验环境暂时不能抓包测试 TLS1.3，但互联网上很多网站都已经支持了 TLS1.3，比如Nginx、GitHub，你可以课后自己用 Wireshark 试试。在 Chrome 的开发者工具里，可以看到这些网站的 TLS1.3 应用情况。

图5.7

5.5 小结

1为了兼容 1.1、1.2 等“老”协议，TLS1.3 会“伪装”成 TLS1.2，新特性在“扩展”里实现；

2 1.1、1.2 在实践中发现了很多安全隐患，所以 TLS1.3 大幅度删减了加密算法，只保留了 ECDHE、AES、ChaCha20、SHA-2 等极少数算法，强化了安全；

3 TLS1.3 也简化了握手过程，完全握手只需要一个消息往返，提升了性能。

6 HTTPS优化

你可能或多或少听别人说过，“HTTPS 的连接很慢”。那么“慢”的原因是什么呢？

通过前两讲的学习，你可以看到，HTTPS 连接大致上可以划分为两个部分，第一个是建立连接时的非对称加密握手，第二个是握手后的对称加密报文传输。由于目前流行的 AES、ChaCha20 性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。

所以，通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。在 TCP 建连之后，正式数据传输之前，HTTPS 比 HTTP 增加了一个 TLS 握手的步骤，这个步骤最长可以花费两个消息往返，也就是 2-RTT。而且在握手消息的网络耗时之外，还会有其他的一些“隐形”消耗，比如：

1产生用于密钥交换的临时公私钥对（ECDHE）；

2验证证书时访问 CA 获取 CRL 或者 OCSP；

3非对称加密解密处理“Pre-Master”。

在最差的情况下，也就是不做任何的优化措施，HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒，这其中既有网络耗时，也有计算耗时，就会让人产生“打开一个 HTTPS 网站好慢啊”的感觉。

不过刚才说的情况早就是“过去时”了，现在已经有了很多行之有效的 HTTPS 优化手段，运用得好可以把连接的额外耗时降低到几十毫秒甚至是“零”。

我画了一张图，把 TLS 握手过程中影响性能的部分都标记了出来，对照着它就可以“有的放矢”地来优化 HTTPS。

图6.1

6.1 硬件优化

在计算机世界里的“优化”可以分成“硬件优化”和“软件优化”两种方式，先来看看有哪些硬件的手段。

硬件优化，说白了就是“花钱”。但花钱也是有门道的，要“有钱用在刀刃上”，不能大把的银子撒出去“只听见响”。

HTTPS 连接是计算密集型，而不是 I/O 密集型。所以，如果你花大价钱去买网卡、带宽、SSD 存储就是“南辕北辙”了，起不到优化的效果。

那该用什么样的硬件来做优化呢？

首先，你可以选择更快的 CPU，最好还内建 AES 优化，这样即可以加速握手，也可以加速传输。

其次，你可以选择“SSL 加速卡”，加解密时调用它的 API，让专门的硬件来做非对称加解密，分担 CPU 的计算压力。

不过“SSL 加速卡”也有一些缺点，比如升级慢、支持算法有限，不能灵活定制解决方案等。

所以，就出现了第三种硬件加速方式：“SSL 加速服务器”，用专门的服务器集群来彻底“卸载”TLS 握手时的加密解密计算，性能自然要比单纯的“加速卡”要强大的多。

6.2 软件优化

不过硬件优化方式中除了 CPU，其他的通常可不是靠简单花钱就能买到的，还要有一些开发适配工作，有一定的实施难度。比如，“加速服务器”中关键的一点是通信必须是“异步”的，不能阻塞应用服务器，否则加速就没有意义了。

所以，软件优化的方式相对来说更可行一些，性价比高，能够“少花钱，多办事”。

软件方面的优化还可以再分成两部分：一个是软件升级，一个是协议优化。

软件升级实施起来比较简单，就是把现在正在使用的软件尽量升级到最新版本，比如把 Linux 内核由 2.x 升级到 4.x，把 Nginx 由 1.6 升级到 1.16，把 OpenSSL 由 1.0.1 升级到 1.1.0/1.1.1。

由于这些软件在更新版本的时候都会做性能优化、修复错误，只要运维能够主动配合，这种软件优化是最容易做的，也是最容易达成优化效果的。

但对于很多大中型公司来说，硬件升级或软件升级都是个棘手的问题，有成千上万台各种型号的机器遍布各个机房，逐一升级不仅需要大量人手，而且有较高的风险，可能会影响正常的线上服务。

所以，在软硬件升级都不可行的情况下，我们最常用的优化方式就是在现有的环境下挖掘协议自身的潜力。

6.3 协议优化

从刚才的 TLS 握手图中你可以看到影响性能的一些环节，协议优化就要从这些方面着手，先来看看核心的密钥交换过程。

如果有可能，应当尽量采用 TLS1.3，它大幅度简化了握手的过程，完全握手只要 1-RTT，而且更加安全。

如果暂时不能升级到 1.3，只能用 1.2，那么握手时使用的密钥交换协议应当尽量选用椭圆曲线的 ECDHE 算法。它不仅运算速度快，安全性高，还支持“False Start”，能够把握手的消息往返由 2-RTT 减少到 1-RTT，达到与 TLS1.3 类似的效果。

另外，椭圆曲线也要选择高性能的曲线，最好是 x25519，次优选择是 P-256。对称加密算法方面，也可以选用“AES_128_GCM”，它能比“AES_256_GCM”略快一点点。

在 Nginx 里可以用“ssl_ciphers”“ssl_ecdh_curve”等指令配置服务器使用的密码套件和椭圆曲线，把优先使用的放在前面，例如：

ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:EECDH+CHACHA20；

ssl_ecdh_curve X25519:P-256;

6.4 证书优化

除了密钥交换，握手过程中的证书验证也是一个比较耗时的操作，服务器需要把自己的证书链全发给客户端，然后客户端接收后再逐一验证。

这里就有两个优化点，一个是证书传输，一个是证书验证。

服务器的证书可以选择椭圆曲线（ECDSA）证书而不是 RSA 证书，因为 224 位的 ECC 相当于 2048 位的 RSA，所以椭圆曲线证书的“个头”要比 RSA 小很多，即能够节约带宽也能减少客户端的运算量，可谓“一举两得”。

客户端的证书验证其实是个很复杂的操作，除了要公钥解密验证多个证书签名外，因为证书还有可能会被撤销失效，客户端有时还会再去访问 CA，下载 CRL 或者 OCSP 数据，这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信，增加好几个 RTT。

CRL（Certificate revocation list，证书吊销列表）由 CA 定期发布，里面是所有被撤销信任的证书序号，查询这个列表就可以知道证书是否有效。

但 CRL 因为是“定期”发布，就有“时间窗口”的安全隐患，而且随着吊销证书的增多，列表会越来越大，一个 CRL 经常会上 MB。想象一下，每次需要预先下载几 M 的“无用数据”才能连接网站，实用性实在是太低了。

所以，现在 CRL 基本上不用了，取而代之的是 OCSP（在线证书状态协议，Online Certificate Status Protocol），向 CA 发送查询请求，让 CA 返回证书的有效状态。但 OCSP 也要多出一次网络请求的消耗，而且还依赖于 CA 服务器，如果 CA 服务器很忙，那响应延迟也是等不起的。

于是又出来了一个“补丁”，叫“OCSP Stapling”（OCSP 装订），它可以让服务器预先访问 CA 获取 OCSP 响应，然后在握手时随着证书一起发给客户端，免去了客户端连接 CA 服务器查询的时间。

6.5 会话复用

到这里，我们已经讨论了四种 HTTPS 优化手段（硬件优化、软件优化、协议优化、证书优化），那么，还有没有其他更好的方式呢？

我们再回想一下 HTTPS 建立连接的过程：先是 TCP 三次握手，然后是 TLS 一次握手。这后一次握手的重点是算出主密钥“Master Secret”，而主密钥每次连接都要重新计算，未免有点太浪费了，如果能够把“辛辛苦苦”算出来的主密钥缓存一下“重用”，不就可以免去了握手和计算的成本了吗？

这种做法就叫“会话复用”（TLS session resumption），和 HTTP Cache 一样，也是提高 HTTPS 性能的“大杀器”，被浏览器和服务器广泛应用。

会话复用分两种，第一种叫“Session ID”，就是客户端和服务器首次连接后各自保存一个会话的 ID 号，内存里存储主密钥和其他相关的信息。当客户端再次连接时发一个 ID 过来，服务器就在内存里找，找到就直接用主密钥恢复会话状态，跳过证书验证和密钥交换，只用一个消息往返就可以建立安全通信。

实验环境的端口 441 实现了“Session ID”的会话复用，你可以访问 URI“https://www.chrono.com:441/28-1”，刷新几次，用 Wireshark 抓包看看实际的效果。

图6.2

通过抓包可以看到，服务器在“ServerHello”消息后直接发送了“Change Cipher Spec”和“Finished”消息，复用会话完成了握手。

图6.3-1

图6.3-2

6.6 会话票证

“Session ID”是最早出现的会话复用技术，也是应用最广的，但它也有缺点，服务器必须保存每一个客户端的会话数据，对于拥有百万、千万级别用户的网站来说存储量就成了大问题，加重了服务器的负担。

于是，又出现了第二种“Session Ticket”方案。它有点类似 HTTP 的 Cookie，存储的责任由服务器转移到了客户端，服务器加密会话信息，用“New Session Ticket”消息发给客户端，让客户端保存。

重连的时候，客户端使用扩展“session_ticket”发送“Ticket”而不是“Session ID”，服务器解密后验证有效期，就可以恢复会话，开始加密通信。

这个过程也可以在实验环境里测试，端口号是 442，URI 是“https://www.chrono.com:442/28-1”。

不过“Session Ticket”方案需要使用一个固定的密钥文件（ticket_key）来加密 Ticket，为了防止密钥被破解，保证“前向安全”，密钥文件需要定期轮换，比如设置为一小时或者一天。

6.7 预共享密钥

“False Start”“Session ID”“Session Ticket”等方式只能实现 1-RTT，而 TLS1.3 更进一步实现了“0-RTT”，原理和“Session Ticket”差不多，但在发送 Ticket 的同时会带上应用数据（Early Data），免去了 1.2 里的服务器确认步骤，这种方式叫“Pre-shared Key”，简称为“PSK”。

图6.4

但“PSK”也不是完美的，它为了追求效率而牺牲了一点安全性，容易受到“重放攻击”（Replay attack）的威胁。黑客可以截获“PSK”的数据，像复读机那样反复向服务器发送。

解决的办法是只允许安全的 GET/HEAD 方法（参见第 10 讲），在消息里加入时间戳、“nonce”验证，或者“一次性票证”限制重放。

6.8 小结

1可以有多种硬件和软件手段减少网络耗时和计算耗时，让 HTTPS 变得和 HTTP 一样快，最可行的是软件优化；

2应当尽量使用 ECDHE 椭圆曲线密码套件，节约带宽和计算量，还能实现“False Start”；

3服务器端应当开启“OCSP Stapling”功能，避免客户端访问 CA 去验证证书；

4会话复用的效果类似 Cache，前提是客户端必须之前成功建立连接，后面就可以用“Session ID”“Session Ticket”等凭据跳过密钥交换、证书验证等步骤，直接开始加密通信。

7 DHE/ECDHE算法的原理

在第 26 讲里，我介绍了 TLS 1.2 的握手过程，在 Client Hello 和 Server Hello 里用到了 ECDHE 算法做密钥交换，参数完全公开，但却能够防止黑客攻击，算出只有通信双方才能知道的秘密 Pre-Master。

这是 TLS 握手的关键步骤，也让很多同学不太理解，“为什么数据都是不保密的，但中间人却无法破解呢？”

解答这个问题必须要涉及密码学，我原本觉得有点太深了，不想展开细讲，但后来发现大家都对这个很关心，有点“打破砂锅问到底”的精神。所以，这次我就试着从底层来解释一下。不过你要有点心理准备，这不是那么好懂的。

先从 ECDHE 算法的名字说起。ECDHE 就是“短暂 - 椭圆曲线 - 迪菲 - 赫尔曼”算法（ephemeral Elliptic Curve Diffie–Hellman），里面的关键字是“短暂”“椭圆曲线”和“迪菲 - 赫尔曼”，我先来讲“迪菲 - 赫尔曼”，也就是 DH 算法。

7.1 离散对数

DH 算法是一种非对称加密算法，只能用于密钥交换，它的数学基础是“离散对数”（Discrete logarithm）。

那么，什么是离散对数呢？

上中学的时候我们都学过初等代数，知道指数和对数，指数就是幂运算，对数是指数的逆运算，是已知底数和真数（幂结果），反推出指数。

例如，如果以 10 作为底数，那么指数运算是 y=10^x，对数运算是 y=logx，100 的对数是 2（10^2=100，log100=2），2 的对数是 0.301（log2≈0.301）。

对数运算的域是实数，取值是连续的，而“离散对数”顾名思义，取值是不连续的，数值都是整数，但运算具有与实数对数相似的性质。

离散对数里的一个核心操作是模运算，也就是取余数（mod，在 C、Java、Lua 等语言里的操作符是“%”）。

假设有模数 17，底数 5，那么“5 的 3 次方再对 17 取余数得 6”（5 ^ 3 % 17 = 6）就是在离散整数域上的一次指数运算（5 ^ 3 (mod 17) = 6）。反过来，以 5 为底，17 为模数，6 的离散对数就是 3（Ind(5, 6) = 3 ( mod 17)）。

这里的（17，5）是离散对数的公共参数，6 是真数，3 是对数。知道了对数，就可以用幂运算很容易地得到真数，但反过来，知道真数却很难推断出对数，于是就形成了一个“单向函数”。

在这个例子里，选择的模数 17 很小，使用穷举法从 1 到 17 暴力破解也能够计算得到 6 的离散对数是 3。

但如果我们选择的是一个非常非常大的数，比如说是有 1024 位的超大素数，那么暴力破解的成本就非常高了，几乎没有什么有效的方法能够快速计算出离散对数，这就是 DH 算法的数学基础。

7.2 DH算法

知道了离散对数，我们来看 DH 算法，假设 Alice 和 Bob 约定使用 DH 算法来交换密钥。

基于离散对数，Alice 和 Bob 需要首先确定模数和底数作为算法的参数，这两个参数是公开的，用 P 和 G 来代称，简单起见我们还是用 17 和 5（P=17，G=5）。

然后 Alice 和 Bob 各自选择一个随机整数作为私钥（必须在 1 和 P-2 之间），严格保密。比如 Alice 选择 a=10，Bob 选择 b=5。

有了 DH 的私钥，Alice 和 Bob 再计算幂作为公钥，也就是 A = (G ^ a % P) = 9，B = (G ^ b % P) = 14，这里的 A 和 B 完全可以公开，因为根据离散对数的原理，从真数反向计算对数 a 和 b 是非常困难的。

交换 DH 公钥之后，Alice 手里有五个数：P=17，G=5，a=10，A=9，B=14，然后执行一个运算：(B ^ a % P)= 8。

因为离散对数的幂运算有交换律，B ^ a = (G ^ b ) ^ a = (G ^ a) ^ b = A ^ b，所以 Bob 计算 A ^ b % P 也会得到同样的结果 8，这个就是 Alice 和 Bob 之间的共享秘密，可以作为会话密钥使用，也就是 TLS 里的 Pre-Master。

图7.1

那么黑客在这个密钥交换的通信过程中能否实现攻击呢？

整个通信过程中，Alice 和 Bob 公开了 4 个信息：P、G、A、B，其中 P、G 是算法的参数，A 和 B 是公钥，而 a、b 是各自秘密保管的私钥，无法获取，所以黑客只能从已知的 P、G、A、B 下手，计算 9 或 14 的离散对数。

由离散对数的性质就可以知道，如果 P 非常大，那么他很难在短时间里破解出私钥 a、b，所以 Alice 和 Bob 的通信是安全的（但在本例中数字小，计算难度很低）。

实验环境的 URI“/42-1”演示了这个简单 DH 密钥交换过程，可以用浏览器直接访问，命令行下也可以用“resty www/lua/42-1.lua”直接运行。

7.3 DHE算法

DH 算法有两种实现形式，一种是已经被废弃的 DH 算法，也叫 static DH 算法，另一种是现在常用的 DHE 算法（有时候也叫 EDH）。

static DH 算法里有一方的私钥是静态的，通常是服务器方固定，即 a 不变。而另一方（也就是客户端）随机选择私钥，即 b 采用随机数。

于是 DH 交换密钥时就只有客户端的公钥会变，而服务器公钥不变，在长期通信时就增加了被破解的风险，使得拥有海量计算资源的攻击者获得了足够的时间，最终能够暴力破解出服务器私钥，然后计算得到所有的共享秘密 Pre-Master，不具有“前向安全”。

而 DHE 算法的关键在于“E”表示的临时性上（ephemeral），每次交换密钥时双方的私钥都是随机选择、临时生成的，用完就扔掉，下次通信不会再使用，相当于“一次一密”。所以，即使攻击者破解了某一次的私钥，其他通信过程的私钥仍然是安全的，不会被解密，实现了“前向安全”。

7.4 ECDHE 算法

现在如果你理解了 DHE，那么理解 ECDHE 也就不那么困难了。

ECDHE 算法，就是把 DHE 算法里整数域的离散对数，替换成了椭圆曲线上的离散对数。

图7.2

原来 DHE 算法里的是任意整数，而 ECDHE 则是把连续的椭圆曲线给“离散化”成整数，用椭圆曲线上的“倍运算”替换了 DHE 里的幂运算。

在 ECDHE 里，算法的公开参数是椭圆曲线 C、基点 G 和模数 P，私钥[注释二] 是倍数 x，公钥是倍点 xG，已知倍点 xG 要想计算出离散对数 x 是非常困难的。

在通信时 Alice 和 Bob 各自随机选择两个数字 a 和 b 作为私钥，计算 A=aG、B=bG 作为公钥，然后互相交换，用与 DHE 相同的算法，计算得到 aB=abG=Ab，就是共享秘密 Pre-Master。

因为椭圆曲线离散对数的计算难度比普通的离散对数更大，所以 ECDHE 的安全性比 DHE 还要高，更能够抵御黑客的攻击。

[注释二]ECDHE算法中的公钥和私钥都是临时的，目的就是用来生成对称加密所使用的密钥。这里的私钥指的就是ECDHE的私钥，不是证书的私钥。证书的私钥主要用来进行数字签名。也就是说在TLS握手的时候实际上是存在两套公钥/私钥对，一套是用来生成对称加密密钥的ECDHE公钥/私钥对；另外一套就是证书的公钥/私钥对。

8 SRTP中的密钥

8.1 从DTLS中获得SRTP中的master_key和master_salt

在4.2.2小节中讲到了：使用Client Params, Server Params配合ecdhe算法计算出Pre-Master；然后使用Client Random、Server Random 和 Pre-Master计算Master Secret。

Master Secret的计算方式前面4.2.2小节中的图4.9-1中也讲了(RFC4346)，计算出来的Master Secret是48个字节的长度，配合使用PRF继续生成其他的密钥，生成方式参考RFC5705，具体如图8.1所示：

图8.1

在生成SRTP的相关密钥时使用的就是图8.1中的方式，此时图8.1中label的值为“EXTRACTOR-dtls_srtp”；

SecurityParameters.master_secret就是DTLS各自计算出来的Master Secret，SecurityParameters.client_random和SecurityParameters.server_random就是DTLS中的Client Hello和Server Hello中携带的Client Random、Server Random参数(也是计算Master Secret的输入参数)。

关于length的长度见RFC5764的4.2小节中，具体如图8.2所示：

图8.2

图8.2中的SRTPSecurityParams.master_key_len 和 SRTPSecurityParams.master_salt_len的值，在 use_srtp(RFC5764第4小节DTLS Extensions for SRTP Key Establishment) 描述的profile中定义。这里举个例子，假设profile为SRTP_AES128_CM_HMAC_SHA1_80，该profile对应的配置如图8.3所示：

图8.3

此时的length为：2*(128 + 112) / 8 = 60 bytes，图8.3中的长度单位为bit，而length的单位长度为byte。

经过以上步骤我们就可以使用图8.2中的公式求出Client和Server所使用的SRTP的加密参数：master_key和master_salt。这两个参数在RFC3711中被用来生成SRTP的session keys。

8.2 SRTP中session keys的生成

具体可以参考RFC3711中的4.3小节，如下图8.4所示：

图8.4

接着前面进行分析，在DTLS的 use_srtp 中已经协商好了生成SRTP session key 的 profile，这里还是以图8.3为例进行讲解。在图8.3中使用的KDR(Key Derivation Function)就是使用 use_srtp 协商的AES_128_CM，剩下的步骤链接：

https://mp.weixin.qq.com/s/u7eStMiCGxNyEWsYkG8UYg

中已经讲解的很详细了，这里直接贴上截图了，具体如图8.5所示：

图8.5

这里着重说一下如何计算 session kyes，这里以计算 RTP 的 session keys为例进行讲解，使用的例子的数据来自上述链接(实际上就是RTC3711中的B.3小节)，也就是：

master_key: E1F97A0D3E018BE0D64FA32C06DE4139 // 128-bits
master_salt: 0EC675AD498AFEEBB6960B3AABE6 // 112-bits

计算 session keys 的步骤是这样的：

sesseion keys 的生成使用的是 AES-ICM-128bits，加密key(也就是AES-KEY)就是从DTLS导出的master_key，然后基于 master_salt 按照图8.5算出IV(Initialization Vector)，具体如下图8.6所示：

图8.6

这个过程可以参考RFC3711 中的 B.3小节，具体如图8.7所示：

图8.7

最后使用 AES-ICM-128bits 这个KDR，配合master_key和IV，对一个空的字符串进行加密，得到的结果就是下面将要计算的三种key。参考网上的代码，使用openssl写了个代码，具体如下：

// openssl-aes-128-ctr.cpp
// gcc openssl-aes-128-ctr.cpp -lssl -lcrypto
// 参考链接：
// http://www.voidcn.com/article/p-zimhdgcr-bry.html
// https://blog.csdn.net/zyhse/article/details/112294229
// https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption#C.2B.2B_Programs
// https://www.coder.work/article/1732480#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>
#include <openssl/err.h>
#include <string>void handleErrors(void)
{ERR_print_errors_fp(stderr);abort();
}int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char *key,unsigned char *iv, unsigned char *ciphertext)
{EVP_CIPHER_CTX *ctx;int len;int ciphertext_len;/* Create and initialise the context */if (!(ctx = EVP_CIPHER_CTX_new()))handleErrors();/* Initialise the encryption operation. IMPORTANT - ensure you use a key* and IV size appropriate for your cipher* In this example we are using 256 bit AES (i.e. a 256 bit key). The* IV size for *most* modes is the same as the block size. For AES this* is 128 bits */if (1 != EVP_EncryptInit_ex(ctx, EVP_aes_128_ctr(), NULL, key, iv))handleErrors();/* Provide the message to be encrypted, and obtain the encrypted output.* EVP_EncryptUpdate can be called multiple times if necessary*/if (1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len))handleErrors();ciphertext_len = len;/* Finalise the encryption. Further ciphertext bytes may be written at* this stage.*/if (1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len))handleErrors();ciphertext_len += len;/* Clean up */EVP_CIPHER_CTX_free(ctx);return ciphertext_len;
}int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char *key,unsigned char *iv, unsigned char *plaintext)
{EVP_CIPHER_CTX *ctx;int len;int plaintext_len;/* Create and initialise the context */if (!(ctx = EVP_CIPHER_CTX_new()))handleErrors();/* Initialise the decryption operation. IMPORTANT - ensure you use a key* and IV size appropriate for your cipher* In this example we are using 256 bit AES (i.e. a 256 bit key). The* IV size for *most* modes is the same as the block size. For AES this* is 128 bits */if (1 != EVP_DecryptInit_ex(ctx, EVP_aes_128_ctr(), NULL, key, iv))handleErrors();/* Provide the message to be decrypted, and obtain the plaintext output.* EVP_DecryptUpdate can be called multiple times if necessary*/if (1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len))handleErrors();plaintext_len = len;/* Finalise the decryption. Further plaintext bytes may be written at* this stage.*/if (1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len))handleErrors();plaintext_len += len;/* Clean up */EVP_CIPHER_CTX_free(ctx);return plaintext_len;
}void HexToBytes(const std::string& hex, std::string& out) {for (unsigned int i = 0; i < hex.length(); i += 2) {std::string byteString = hex.substr(i, 2);char byte = (char) strtol(byteString.c_str(), NULL, 16);out.push_back(byte);}
}int main(int argc, char const *argv[])
{if (argc != 3){return -1;}std::string strKey, strIv;      HexToBytes(argv[1], strKey);HexToBytes(argv[2], strIv);printf("size: %d, input-key: %s\n", strKey.size(), argv[1]);printf("size: %d, input-iv: %s\n", strIv.size(), argv[2]);/* Message to be encrypted */unsigned char plaintext[16] = {0};/* Buffer for ciphertext. Ensure the buffer is long enough for the* ciphertext which may be longer than the plaintext, dependant on the* algorithm and mode*/unsigned char ciphertext[128];/* Buffer for the decrypted text */unsigned char decryptedtext[128];int decryptedtext_len, ciphertext_len;printf("Plaintext is:\n%s~\n", plaintext);/* Encrypt the plaintext */ciphertext_len = encrypt(plaintext, 16, (unsigned char *)strKey.c_str(), (unsigned char *)strIv.c_str(), ciphertext);/* Do something useful with the ciphertext here */printf("Ciphertext is %d bytes long:\n", ciphertext_len);BIO_dump_fp(stdout, (const char *)ciphertext, ciphertext_len);/* Decrypt the ciphertext */decryptedtext_len = decrypt(ciphertext, ciphertext_len, (unsigned char *)strKey.c_str(), (unsigned char *)strIv.c_str(), decryptedtext);/* Add a NULL terminator. We are expecting printable text */decryptedtext[decryptedtext_len] = '\0';/* Show the decrypted text */printf("Decrypted text is:\n");printf("%s~\n", decryptedtext);return 0;
}

8.2.1 计算 cipher key (16字节 128-bits)

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEEBB6960B3AABE60000

输出：

8.2.2 计算 cipher salt (14字节 112-bits)

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEE9B6960B3AABE60000

输出：

8.2.3 计算 auth key (94字节)

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEEAB6960B3AABE60000

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEEAB6960B3AABE60001

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEEAB6960B3AABE60002

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEEAB6960B3AABE60003

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEEAB6960B3AABE60004

./a.out E1F97A0D3E018BE0D64FA32C06DE4139 0EC675AD498AFEEAB6960B3AABE60005

这里仅贴出来一个输出：

9 TLS和DTLS的一些区别

TLS和DTLS的握手过程基本上是一致的，差别以及说明主要如下：
1. DTLS的HelloVerify不是必须的。这个也是DTLS防止重放攻击加的一个消息；
2. TLS没有发送CertificateRequest，这个也不是必须的，是反向验证即服务器验证客户端；
3. DTLS的RecordLayer新增了SequenceNumber和Epoch、ClientHello中新增了Cookie，以及Handshake中新增了Fragment信息（防止超过UDP的MTU），这是针对UDP的丢包以及DOS而做出的改进。

TLS-DTLS-SRTP相关总结相关推荐

SSL/TLS/DTLS对比
SSL/TLS/DTLS对比_Leon-CSDN博客 SSL/TLS/DTLS对比_放飞自己-CSDN博客 https://segmentfault.com/a/1190000002554673 SS ...
什么是TLS DTLS和SRTP？
TLS 传输层安全性协议(英语:Transport Layer Security,缩写作TLS),及其前身安全套接层(Secure Sockets Layer,缩写作SSL)是一种安全协议,目的是为互 ...
什么是TLS DTLS和SRTP
TLS 传输层安全性协议(英语:Transport Layer Security,缩写作TLS),及其前身安全套接层(Secure Sockets Layer,缩写作SSL)是一种安全协议,目的是为互 ...
openssl 的 tls 命令和相关使用心得
声明:本文基于 openssl 1.1.1f 版本服务端: Usage: s_server [options] Valid options are:-help Display this summar ...
Android HTTPS、TLS版本支持相关解决方案
前言简介 HTTPS相关名词解释图解HTTPS协议加密解密全过程异常解决问题描述原因分析解决方案参考链接前言在互联网安全通信方式上,目前用的最多的就是https配合ssl和数字证 ...
WebRTC 传输安全机制：DTLS 和 SRTP
在 WebRTC 中,为了保证媒体传输的安全性,引入了 DTLS 和 SRTP 来对通信过程进行加密.DTLS 的作用.原理与 SSL/TLS 类似,都是为了使通信过程变得更安全. 常用加密方法加密 ...
WebRTC 协议介绍--一篇读懂DTLS、SRTP、SRTCP
DTLS作用资料包传输层安全(英语:Datagram Transport Layer Security,缩写为 DTLS),又译数据包传输层安全,是一种通信协议,提供UDP协议在传输层的发送安全.它 ...
网络协议文档阅读笔记-TLS vs DTLS | Difference between TLS and DTLS
TLS是工作在除应用层协议外最顶层的协议.也就是传输层协议,这个协议,在有些文档中称为应用层的子协议.DTLS与TLS区别就在那个D,也就是Datagram TLS协议 TLS:提供了应用程序(如We ...
DTLS与TLS的比较
原文地址:https://www.rfc-editor.org/rfc/pdfrfc/rfc6347.txt.pdf 1. 背景简介 TLS [TLS] is the most widely depl ...
详解 WebRTC 传输安全机制：一文读懂 DTLS 协议
DTLS(Datagram Transport Layer Security) 是基于 UDP 场景下数据包可能丢失或重新排序的现实情况下,为 UDP 定制和改进的 TLS 协议.在 WebRTC 中 ...

TLS-DTLS-SRTP相关总结