SSL/TLS详解

最新推荐文章于 2023-10-13 23:20:12 发布

A神经质

最新推荐文章于 2023-10-13 23:20:12 发布

阅读量3.1k

点赞数 5

分类专栏：计算机网络文章标签： ssl https http

本文链接：https://blog.csdn.net/weixin_45637300/article/details/125200936

版权

计算机网络专栏收录该内容

3 篇文章 1 订阅

订阅专栏

SSL/TLS详解

1. 前言

我们都知道Https就是加密协议中采用了SSL/TLS协议，这是面试常客，如果被问到了，你懂的越多，答得越深，你的面评相应来说也就会越高，对于SSL/TLS，我们不仅仅要知道其为数据传输提供了加密服务，提高了数据传输的安全性，还得了解什么是对称加密算法、非对称加密算法、散列算法，以及数字证书等。以下，我会详细讲解。

2. SSL/TLS工作原理

HTTPS协议的主要功能基本都依赖于TLS/SSL协议，TLS/SSL的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

2.1 对称加密算法

常见的有AES-CBC、DES、3DES、AES-GCM等，相同的密钥可以用于信息的加密和解密，掌握密钥才能获取信息，能够防止信息窃听，通信方式是1对1; 对称加密的优势是信息传输1对1，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和 N 个客户端通信，需要维持 N 个密码记录，且缺少修改密码的机制。

举例：公钥和密钥都可以进行加密与解密。

2.2 非对称加密算法

即常见的 RSA 算法，还包括 ECC、DH 等算法，算法特点是，密钥成对出现，一般称为公钥(公开)和私钥(保密)，公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信，服务器可以实现1对多的通信，客户端也可以用来验证掌握私钥的服务器身份。非对称加密的特点是信息传输1对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。

举例：公钥只能对进行加密，而私钥能进行加密与解密。

2.3 散列函数Hash

这里我们以MD5算法举例，通常面试说到这个算法的原理即可。

2.3.1 MD5算法原理

MD5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子分组，经过一些列的处理后，算法输出由四个32位分组组成的128位散列值。具体的步骤如下所示：

填充：如果输入信息的长度(bit)对512求余的结果不等于448，就需要填充使得对512求余结果等于448。填充的方法是填充一个1和n个0。填充完成后，信息的长度为N*512+448。
记录信息长度：用64位内存来存储填充前信息长度。这64位加在第一步结果的后面，这样信息长度就变为N*512 + 448 + 64 = (N+1)*512。
装入标准的幻数：标准的幻数（物理顺序）是（A=(01234567)16，B=(89ABCDEF)16，C=(FEDCBA98)16，D=(76543210)16）。如果在程序中定义应该是（A=0X67452301L，B=0XEFCDAB89L，C=0X98BADCFEL，D=0X10325476L）。

首先清楚整型的位表示方法，其次标准文档上要求的是：四个幻数在内存地址上从低到高为：
A: 01 23 45 67
B: 89 ab cd ef
C: fe dc ba 98
D: 76 54 32 10
采用小端表示法表示为A=0X67452301L，则在地址中就是A=01 23 45 67
循环运算：
- 把消息分以512位为一分组进行处理
- 每一个分组进行4轮变换，以上面所说4个标准的幻数为起始变量进行计算，重新输出4个变量
- 以这4个变量再进行下一分组的运算，如果已经是最后一个分组，则这4个变量为最后的结果，即MD5值。

更多相关信息，参考链接：https://blog.csdn.net/weixin_39640298/article/details/84555814

3. TLS握手过程

客户端与服务端建立TCP连接后，TLS握手从客户端发送Client Hello开始，此消息包含客户端支持的加密套件和一个随机数。
服务端接收客户端的Client Hello消息后，响应Server Hello消息，此消息携带服务端从客户端提供的支持的加密套件列表中选择使用的加密套件，同时还会携带一个随机数。
服务端向客户端发送证书，证书包含公钥和签名。
客户端验证服务端发送的证书，验证通过后，假设选择的加密套件是RSA_WITH_AES_128_CBC_SHA256，那么客户端要生成一个预主密钥，然后从服务器发送的证书中提取公钥，利用证书的公钥对预主密钥进行RSA加密，再发送给服务端。

此时客户端开始根据发送Client Hello时生成的随机数+服务端Server Hello响应的随机数+客户端生成的预主密钥，生成主密钥，此密钥用于给后续传输的数据进行加解密。

接着，客户端向服务端发送Change Cipher Spec消息，告诉服务端，它后续将切换到使用协商好的加密密钥对数据进行加密再传输。同时也是跟Client Key Exchange（此加密套件需要使用Client Key Exchange消息携带加密后的预主密钥）、Finished消息一起发送，Finished消息使用了该密钥进行加密。
服务端收到Client Key Exchange消息后，从消息中提取加密过的预主密钥，然后拿证书的私钥解密获取预主密钥。

服务端根据前面客户端发送Client Hello携带的随机数、服务端响应给客户端的随机数，加上这次接收的预主密钥，生成主密钥。

服务端响应Change Cipher Spec消息，告诉客户端，服务器执行相同操作，后续将切换到使用协商好的加密密钥对数据进行加密再传输。同时也是跟Finished消息一起发送，Finished消息使用密钥进行加密。

结合三类算法的特点，TLS的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

4. PKI体系

4.1 RSA身份验证的隐患

身份验证和密钥协商是TLS的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但RSA算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患:

客户端C和服务器S进行通信，中间节点M截获了二者的通信;
节点M自己计算产生一对公钥pub_M和私钥pri_M;
C向S请求公钥时，M把自己的公钥pub_M发给了C;
C使用公钥 pub_M加密的数据能够被M解密，因为M掌握对应的私钥pri_M，而 C无法根据公钥信息判断服务器的身份，从而 C和 * M之间建立了"可信"加密连接;
中间节点 M和服务器S之间再建立合法的连接，因此 C和 S之间通信被M完全掌握，M可以进行信息的窃听、篡改等操作。
另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。

因此该方案下至少存在两类问题：中间人攻击和信息抵赖。

4.2 身份验证CA和证书

解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA(如沃通CA)。CA 负责核实公钥的拥有者的信息，并颁发认证"证书"，同时能够为使用者提供证书验证服务，即PKI体系(PKI基础知识)。

数字签名

假设A用自己的私钥对Email加密发送，这存在下面问题：

对文件本身加密可能是个耗时过程，比如这封Email足够大，那么私钥加密整个文件以及拿到文件后的解密无疑是巨大的开销。
数字签名可以解决这个问题：

A先对这封Email执行哈希运算得到hash值简称“摘要”，取名h1
然后用自己私钥对摘要加密，生成的东西叫“数字签名”
把数字签名加在Email正文后面，一起发送给B
（当然，为了防止邮件被窃听你可以用继续公钥加密，这个不属于数字签名范畴）
B收到邮件后用A的公钥对数字签名解密，成功则代表Email确实来自A，失败说明有人冒充
B对邮件正文执行哈希运算得到hash值，取名h2
B 会对比第4步数字签名的hash值h1和自己运算得到的h2，一致则说明邮件未被篡改。

5. HTTPS性能与优化

由于HTTPS具有加密协议，而有了加密，相应的性能也会有损耗，在这里，我们来提一下相关HTTPS性能与优化。

5.1 HTTPS的性能损耗

增加延时

分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2* RTT，利用会话缓存从而复用连接，延时也至少1* RTT*
消耗较多的CPU资源

除数据传输之外，HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU：对称加密算法AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销，10G 网卡为对称加密需要消耗 CPU 约17核，24核CPU最多接入 HTTPS 连接 4800; 静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s，如果将所有的HTTP连接变为HTTPS连接，则明显RSA的解密最先成为瓶颈。因此，RSA的解密能力是当前困扰HTTPS接入的主要难题。

5.2 HTTPS的接入优化

CDN接入

HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。

会话缓存

虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化;同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。

硬件加速

为接入服务器安装专用的SSL硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力，相当于175核 CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。

远程解密

本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。