TLS/SSL概述

TLS/SSL协议

TLS/SSL位于TCP层和应用层之间,具体如下图所示

设计目的

  • 身份验证
  • 保密性
  • 完整性

握手协议

  • 验证通讯双方的身份
  • 交换加解密的安全套件
  • 协商加密参数

TLS安全密码套件解读

SSL/TLS协议在协商时,会选择一组恰当的加密算法来实现安全通信,这些算法的组合被称为“密码套件”

密码套件的命名如上所示,格式很固定,基本的形式是:“密钥交换算法+签名算法+对称加密算法+摘要算法”
以上密码套件的意思如下:“握手时使用ECDHE算法进行密钥交换,用RSA签名和身份认证,握手后的通信使用AES对称算法,密钥长度128位,分组模式是GCM,摘要算法SHA256用于消息认证和产生随机数。”

对称加密和非对称加密

对称加密

使用同一把密钥对数据进行加解密

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

ChaCha20 是 Google 设计的另一种加密算法,密钥长度固定为 256 位

AES加密算法详解

AES:高级加密标准,密钥长度可以是128、192 或 256。它是 DES 算法的替代者,安全强度很高,性能也很好,
常用填充算法:PKCS7
常用分组模式:GCM

AES的加密步骤:

  1. 把明文按照 128bit(16 字节)拆分成若干个明文块,每个明文块是 4*4 矩阵
  2. 按照选择的填充方式来填充最后一个明文块
  3. 每一个明文块利用 AES 加密器和密钥,加密成密文块
  4. 拼接所有的密文块,成为最终的密文结果

对称加密分组模式

对称算法还有一个“分组模式”的概念,它可以让算法用固定长度的密钥加密任意长度的明文,把小秘密(即密钥)转化为大秘密(即密文)。
最新的分组模式被称为 AEAD(Authenticated Encryption with Associated Data),在加密的同时增加了认证的功能,常用的是 GCM、CCM 和 Poly1305。
比如,AES128-GCM,意思是密钥长度为 128 位的 AES 算法,使用的分组模式是 GCM

非对称加密

对称加密看上去好像完美地实现了机密性,但其中有一个很大的问题:如何把密钥安全地传递给对方,术语叫“密钥交换”。
非对称加密有两个密钥,一个叫“公钥”(public key),一个叫“私钥”(private key)。两个密钥是不同的,“不对称”,公钥可以公开给任何人使用,而私钥必须严格保密。

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

  • RSA:它的安全性基于“整数分解”的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的。
  • ECC:它基于“椭圆曲线离散对数”的数学难题,使用特定的曲线方程和基点生成公钥和私钥,子算法 ECDHE 用于密钥交换,ECDSA 用于数字签名。

混合加密

非对称加密算法因为基于复杂的数学难题,运算速度很慢,所以需要使用混合加密。

  • 在通信刚开始的时候使用非对称算法,比如 RSA、ECDHE,首先解决密钥交换的问题。
  • 然后用随机数产生对称算法使用的“会话密钥”(session key),再用公钥加密。因为会话密钥很短,通常只有 16 字节或 32 字节,所以慢一点也无所谓。
  • 对方拿到密文后用私钥解密,取出会话密钥。这样,双方就实现了对称密钥的安全交换,后续就不再使用非对称加密,全都使用对称加密。

摘要算法

实现完整性的手段主要是摘要算法(Digest Algorithm),也就是常说的散列函数、哈希函数(Hash Function)。
摘要算法是对数据进行的唯一标识,对数据做任何一点修改都会造成摘要完全不同。
日常中常用的有MD5、SHA-1,目前TLS中推荐使用的是SHA-1的后继者:SHA-2
SHA-2实际上是一系列摘要算法的统称,总共有6种,常用的有SHA224、SHA256、SHA384,分别能够生成28字节、32字节、48字节的摘要。

通常摘要也可能被黑客修改,所以需要对数据和摘要都加密传输,在混合加密系统里用会话密钥加密消息和摘要,这有个术语,叫哈希消息认证码(HMAC)。

数字签名

当双方通信时无法确定对方身份,此时需要使用数字签名进行验证。操作步骤如下:

  1. 使用自己的私钥加密原文的摘要,得到数字签名
  2. 对方获得数字签名后,使用发布的公钥进行解密,如果能正常解密且数据正确,则验明对方身份


以上过程分别叫做“签名”和“验签”

数字证书和CA

上边可以通过使用公钥解密数据确定对方身份,但是对方如果发布的公钥是假的,是黑客发布的,怎么验证公钥的正确性呢,此时用到第三方的证书认证机构CA,由它来给各个公钥签名,用自身的信誉来保证公钥无法伪造,是可信的。
CA对公钥的签名认证也是有格式的,不是简单地把公钥绑定在持有者身份上就完事了,还要包含序列号、用途、颁发者、有效时间等等,把这些打成一个包再签名,完整地证明公钥关联的各种信息,形成“数字证书”(Certificate)。
签发的证书分类DV、OV、EV三种,区别在于可信程度,DV是最低的,只是域名级别的可信,背后是谁不知道。EV是最高的,经过了法律和审计的严格核查,可以证明网站拥有者的身份(在浏览器地址栏会显示出公司的名字,例如Apple、GitHub的网站)。

不过CA怎么证明自己呢?
有一条如下的信任链条,但最后由Root CA终结此链条,Root CA只能自己证明自己,这个就叫“自签名证书”(Self-Signed Certificate)或者“根证书”(Root Certificate)。你必须相信,否则整个证书信任链就走不下去了。

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

猜你喜欢

转载自www.cnblogs.com/baihl/p/11967088.html
今日推荐