传输层安全协议TLS-密码学概述-CSDN博客

许多小伙伴应该都听过大名鼎鼎的HTTPS，而HTTPS就是通过在HTTP的基础上引入TLS，实现对明文进行传输加密和身份认证，保证了传输过程的安全。由于TLS协议深度依赖抽象复杂的密码学原理、工具箱及设计模式，令许多小伙伴都望而却步。不用担心，今天小怿会用通俗易懂的方式，层层递进，带领大家一起经历密码学入门到TLS精通之路。

01TLS速览—3W1H分析

1. WHAT：TLS是什么？

TLS（传输层安全性协议，Transport Layer Security）及它的前身SSL（安全套接字层，现在不推荐使用的）是一种旨在提供计算机网络上的安全通信的加密协议。TLS建立在网景（Netscape）开发的早期SSL规范（1994、1995、1996）的基础上；SSL从网景移交到IETF后，IETF将其更名为TLS，TLS最早版本发布于1999年，当前最新版本为发布于2018年8月的TLS 1.3。

2. WHY：为什么要用TLS？

目的是在两个或多个通信计算机应用程序之间提供机密性、认证、数据完整性、前向安全性等安全特性，防止通信被窃听和篡改。

3. WHERE：TLS现在用在哪？

广泛用于电子邮件，即时消息传递（微信）和IP语音等应用中，最常见的应用场景是作为HTTPS的‘安全’层。

4. HOW：TLS到底咋用？

借用密码学的经典原则：永远不要试图去创造自己的加密算法，要使用专家设计好的标准算法。让我们引申下，由于side effect破解的存在，在生产环境中甚至都不要使用自己实现的TLS协议，目前有很多开源的TLS协议实现，可以针对应用场景进行裁剪和适配。

以上内容你学会（废）了吗？那让我们再上点对抗哈。让我们看一个TLS中最常使用的密码套件(Cipher Suite)：

由上面这个加密算法套件可见，如果想弄清楚TLS，必须对密码学的基本概念（密钥交换、身份验证、加密算法模式等），使用它们期望解决的威胁以及各场景下常用的密码学算法有基本的了解，才能真正从整体“战略”上了解TLS，为后面从“战术”角度逐个击破单个技术点打下基础，否则就是“基础不牢，地动山摇”，雾里看花，不知所云。

考虑到很多小伙伴对于密码学概念不甚了解，我们的TLS介绍将分为两期：

1.密码学概述：对密码学概念、威胁、解决方案做总览式介绍

2.TLS协议详解：从时间线、握手流程、分层模型及记录格式角度刨析TLS

那下面就让我们开始密码学概述的介绍吧。

02TLS密码学初识—概念、威胁及解决方案

TLS作为安全通信的协议，每一设计细节无不是围绕着安全与性能两大核心来展开的，跟着小怿来看看现实中安全通信面临的威胁、受威胁的特性及相应解决方案。

1. 机密性(Confidentiality)

这个安全特性是最直观的，直白讲就是我们理解的对消息加密。比如平时大家都喜欢在网上买东西，付款时需要输入账户密码，如果网上传输的是实际密码本身，黑客只要简单窃听下网线上的消息即可获取交易密码，所以在实际的交易过程中不能直接传输密码原文，必须使用密钥对交易的密码进行加密再传输。对消息进行加密后，即使黑客窃听到了我们的消息，也无法获知消息的具体内容，这个过程实现了消息的机密性。现实中常常使用加解密速度较快的对称加密算法来实施加密：AES，3DES等。

2. 密钥配送(Key Exchange)

虽然通过密钥对消息进行加密实现了机密性，但同时也引入了另一威胁，即进行加密用的密钥该如何传递给对方呢？如果加密消息用的密钥是使用原文来传输的，那如果该密钥被窃听了，黑客直接使用该密钥对密文进行解密，还是可以得到原消息，机密性也就无从谈起。

因此在通信开始之前，必须先传输加密时使用的密钥，或者就加密时使用的密钥达成一致，基于此便引入了密钥配送技术来解决这一威胁。现实中最常使用的密钥交换技术有Diffie-Hellman、RSA等。

Tips：Diffie-Hellman 密钥交换（Diffie-Hellman key exchange）基本原理是：通信双方通过交换一些可以公开的信息就能够生成出共享的秘密数字，而这一秘密数字就可以被用作对称密码的密钥，实际上双方并没有真正交换密钥，而是通过计算生成出了一个相同的共享秘钥。因此，这种方法又称为Diffie-Hellman 密钥协商（Diffie-Hellman key agreement）。

以上两个威胁中黑客只使用窃听等被动攻击手段，并没有实施篡改或拦截消息等其他主动攻击，然而现实中，黑客往往更加强力，具备主动攻击的能力，同样随着攻击者的攻击能力升级，也会带来更加难以解决的对安全通信的威胁。

3. 消息完整性(Integrity)

现实中很多消息比如HTTP，常常具有一些固定的格式，一些场景下黑客可以无需破解原文，直接对密文中的某些字段进行修改来施加攻击。如下图所示：如果黑客知晓转账消息的消息格式，识别出其中的账户部分，直接将转账账户设为黑客自己的账户，就能绕过破解密码难题和机密性防御，轻易达成盗窃目的。

为此，通信双方必须对其发出的消息的内容完整性进行验证，即确保发出的消息是原消息，未在传输过程中被篡改。这个威胁的解决方法是在消息末尾添加消息认证码MAC (Message authentication code)，常用的算法有HMAC、GMAC等。

实际使用中通常将机密性和消息完整性解决方案使用固定的方式组合在一起，构成称为认证加密AE (Authenticated Encryption)的技术。常用的AE算法有：AES-192-GCM、AES-256-GCM、ChaCha20-IETF-Poly1305等。

4. 身份验证与中间人攻击(Identification & MITM)

主动攻击者还可能通过对消息进行拦截、替换、伪装，实施臭名昭著的中间人攻击。所谓中间人攻击，就是主动攻击者混入发送者和接收者的中间，对发送者伪装成接收者，对接收者伪装成发送者的攻击方式，在这里，Mallory就是“中间人”。教科书式的讲法比较抽象，其实这种攻击模式颇似“梁山伯与祝英台”式的棒打鸳鸯的桥段，让我们一起看下：

比如梁山伯写一封信向祝英台表示爱意，并约定一起私奔的时间，好巧不巧，这封信在投递过程中被祝父母拦下来了，看到信上的内容，大为生气，下定决心阻挠这段姻缘。于是，一边伪造祝英台笔迹给梁山伯回了封绝交书，一边又伪造梁山伯笔迹给祝英台也写了封绝交书，祝英台和梁山伯各自收到信后，悲痛欲绝，在这个过程中祝英台父母施加就是中间人攻击。

为了解决该威胁，正如现实生活中一样，我们首先想到的是在报文上签个名字，这个想法很直观，也是正确的。这个做法在数字领域被称为数字签名：即发送方通过私钥对消息进行加密，而接受方通过对应公钥进行解密，利用公私钥的一一对应特性（私钥加密所得到的密文只有用与之对应的公钥才能正确解密）。现实中常用的签名算法有：RSA、DSA、ECDSA等。

5. 公钥证书及公钥基础设施(PKC & PKI)

然而，要正确使用数字签名，有一个大前提，那就是用于验证签名的公钥必须属于真正的发送者。即便数字签名算法再强大，如果你得到的公钥是伪造的，那么数字签名也会完全失效，类比现实中手写签名、盖章也是可以伪造的，那么即使消息签了名字盖了章，也还是无法确认信件的真实性。

现在我们发现自己陷入了一个死循环——数字签名是用来识别消息篡改及伪装的，但是为此我们又必须从没有被伪装的发送者得到没有被篡改的公钥才行。

公钥在传输过程中被拦截、替换，数字签名被破解，安全通信再次土崩瓦解，好像我们又回到了原点？但让我们重新整理下思路，会发现其实我们已经离“真相”只差了一步：最开始传输的加密密钥是无法公开的，而现在我们需要传输的公钥却是可以公开给任何人。传输需要保密的东西问题转化为了传输不需要保密，只需确保真实性的东西，就好比由最初需要是传输的是银行卡密码，转变为只需传输身份证号即可。而在虚拟网络上身份的证明被称为公钥证书(Public-Key Certificate，PKC)，里面记有姓名、组织、邮箱地址等个人信息以及属于此人的公钥，类比于政府机关，网络中由认证机构CA（Certification Authority）来管理颁发公钥证书。

有了这种类似的证书之后通信传输的双方不在直接交换公钥，而是通过交换双方经过权威机构背书的公钥证书来间接实现公钥的传递。

喜欢刨根问底的小伙伴们肯定会问，那认证机构又是如何来确保公钥证书的真实性呢？其实这个问题类似于递归循环，服务器的证书由中间证书来背书，中间权威机构又会由根证书来背书，这中间的认证链接关系称为信任链(trust chain)，而这个最终的颁发根证书机构，称作信任锚点(Trust Anchor)。而操作系统或是浏览器通常会内置很多知名的权威根证书机构的公钥证书，所以通信传输中无需传输根证书机构的证书，这使得最终的信任链如递归一样有一个结束条件，不至于陷入死循环中。