密码套件:密码,算法和协商安全设置

本文深入地研究TLS 1.2密码套件的四个不同组件。首先看看我们在SSL / TLS中看到的两种不同类型的加密。

两种加密

SSL/TLS的最大困惑之一就是所使用的加密类型,与SSL证书关联的2048位密钥用于帮助协商HTTPS连接,但是它的作用实际上比大多数人认为的要小得多。

我们似乎只专注于私钥的位数,如2048位的私钥,因为它听起来似乎很安全。我们甚至会大胆地认为,"现代计算机要花上四千万万年才能破解此密钥,到那时我们都已经死了!"

但是,可以说,你在连接期间使用的批量加密和对称密钥同等重要,甚至比公/私密钥对还重要。

对称加密涉及两个相同的密钥,顾名思义,它们是对称的。两个密钥都可以执行以下两个功能:加密和解密。这是你实际上与访问的网站进行通信所使用的加密类型。

相反,如果我们使用非对称加密,加解密使用的密钥并不对称,一个密钥用来加密,另一个密钥用来解密。非对称加密通常采用带TLS1.2的RSA形式,它负责验证数字签名,并且在使用RSA密钥交换时,它从加密计算出对称会话密钥的主密码,但是RSA并不是唯一的密钥交换机制。

对称加密密钥(通常为AES或高级加密标准)的密钥大小范围为128位到256位。对于对称加密,这是完全有效和安全的,在对称加密中,计算难度必须与可用性或者说与其加密性能保持一致。

那些2048位非对称RSA密钥的计算成本很高,并且增加了握手延迟。在某些实际应用中,它们还容易遭受填充攻击。

长话短说,这里既讲了非对称加密也讲了对称加密,但是对称加密在密码套件的上下文中关联性更强。

现在,让我们看一下密码套件的四个不同组件。

密钥交换

TLS 1.2密码套件中的第一个位置指定用于将要使用的密钥交换机制。

密钥交换是指用于传输对称会话密钥的实际过程,但这并不是密钥生成过程中使用的唯一算法。握手的密钥交换部分确定用于密钥生成的参数,但是散列算法在通过提供伪随机函数(PRF)(通常作为加密安全的伪随机数生成器"CSPRNG")提供密钥的过程中也发挥着作用。

我们要明白的重要一点是,所选的密钥交换机制并不完全负责生成实际密钥。

RSA

RSA以创建它的绅士的名字命名:Rivest,Shamir和Adleman。这是最常见的非对称密码算法。它使用质数的幂运算,具有广泛的应用范围。使用SSL/TLS,通常会在密钥交换的上下文中看到使用RSA。同样,这是所有这些2048位(以及3072和4096位)密钥的来源。

每次握手,无论是否选择RSA密钥协商机制都会从ClientHello和ServerHello交换随机数。

一旦客户端和服务端决定使用包含RSA密钥交换的密码套件,并且在客户端对服务端进行身份验证之后,RSA的运行方式就非常简单。

1.客户端使用服务端发送的公钥来加密预主密钥并进行传输。

2.服务端使用其私钥解密预主密钥。

3.双方都使用PRF,客户端随机数,服务端随机和主机密码来导出主密钥。

4.双方都使用主密钥和更多伪随机函数来计算会话密钥。

在最后两个步骤3和4中,混合主密钥并派生会话密钥,在此利用散列算法的伪随机函数。

RSA密钥交换已经使用了很长时间,但是它已经寿终正寝了。由于已知漏洞,TLS 1.3除了所有其他静态密钥交换机制之外,还取消了RSA密钥交换。

Diffie-Hellman和椭圆曲线Diffie-Hellman

它们以惠特菲尔德·迪菲(Whitfield Diffie)和马丁·海尔曼(Martin Hellman)的名字命名,这是一个密钥交换协议,但它与RSA非对称加密协议并不相同。Diffie和Hellman在这里着手解决的问题是如何在不安全的网络上交换安全密钥,并由攻击者监视。

Diffie-Hellman密钥交换的工作方式如下:

1.在交换了随机数(g&p)之后,客户端和服务端都选择了自己的主控机密(分别为a&b),并计算出一个类似的方程式--gamodp = A,&gbmodp =B。

2.每个到达的值(A&B)被发送给对方,并且双方重复相同的操作-Bamodp和Abmodp。

各方提供所谓的"密钥共享",并且他们各自独立地到达共享会话密钥。有一个模幂的规则规定了这一点。

如果这是很多数学运算,那么关键在于:使用Diffie-Hellman进行密钥交换时,实际上没有进行非对称加密,而是两方相互得出了可用于导出会话密钥的值。

现在让我们来谈谈椭圆曲线Diffie-Hellman,它基本上只是Diffie-Hellman的现代迭代,它受椭圆曲线密码学的支配,而不是其他一些密码系统。基本上,它使用绘制在椭圆曲线上的点作为其计算的基础。

首先,Diffie-Hellman需要牢记两点--在短暂使用时,它缺乏真正的身份验证机制。临时密钥是临时的,所以通常不进行身份验证。

其次,正如我们刚刚提到的,在TLS 1.3中,所有静态密钥生成/交换机制都已弃用。这基本上是废弃RSA的原因,它也消除了非短暂的DH方案。现在ECDHE或"椭圆曲线Diffie-Hellman临时"是密钥交换的标准。

因为在TLS 1.3中,Perfect Forward Secrecy是必须的。完美转发保密功能可保护各个会话免遭解密,即使证书的私钥被泄露也是如此。静态密钥交换方案不支持这一点。

PSK(共享密钥)

通常是写为TLS-PSK的密码,它是根据预先在各方之间交换的预共享对称密钥提供安全通信的。在这里我们就不讲PSK了,因为在高度管制的网络环境之外它还是很少见的,并且我们绝对不建议其作为商业用途。它也未包含在TLS 1.3中。

相关推荐
赖small强4 小时前
【ZeroRange WebRTC】KVS WebRTC 示例中的 HTTP 通信安全说明
https·webrtc·tls·aws sigv4·信道安全·时间与重放控制
赖small强21 小时前
【ZeroRange WebRTC】Amazon Kinesis Video Streams WebRTC Data Plane REST API 深度解析
https·webrtc·data plane rest·sigv4 签名
果壳~1 天前
【Java】使用国密2,3,4.仿照https 统一请求响应加解密
java·https
赖small强1 天前
【ZeroRange WebRTC】Amazon Kinesis Video Streams WebRTC Control Plane API 深度解析
https·webrtc·control plane
2501_916007471 天前
iOS性能调试工具终极指南,从系统底层到多端协同的全方位优化实践(2025版)
android·ios·小程序·https·uni-app·iphone·webview
2501_916008892 天前
没有源码如何加密 IPA 实战流程与多工具组合落地指南
android·ios·小程序·https·uni-app·iphone·webview
MyFreeIT2 天前
HTTPs
https·443·certificate
站长朋友2 天前
解决SSL证书安装后网站仍显示“不安全”的问题
网络协议·安全·ssl·ssl证书安装不安全·锐安信ssltrus·ocsp响应速度·根证书链完整
挠到秃头的涛某2 天前
华为防火墙web配置SSL-在外人员访问内网资源
运维·网络·网络协议·tcp/ip·华为·ssl·防火墙