阅读 820

HTTPS 工作原理详解 | TLS握手过程

HTTPS 概念

HTTPS 就是一个有安全保障的 HTTP 通信,我们都知道,http 是明文传输的,http 报文是人肉眼就可识别的 ASCII 码,在通信过程中,http 报文很容易被黑客窃听、篡改、伪造,而在互联网交易中,我们必须保证通信安全,所以就需要像 https 这样有安全层的协议。

那么,https是怎么保障通信安全的呢?什么样的通信可以被称为是安全的,安全的定义是什么?

通常,如果通信过程具备了四个特性,就可以认为是“安全”的,这四个特性是:机密性、完整性,身份认证和不可否认。而HTTPS正是实现了这四个特性,所以被认为是“安全的”。

HTTPS 和 HTTP 的区别:

  • http 是超文本传输协议,信息是明文传输,https 则是具有安全性的加密传输协议

  • http 基于 tcp 协议,tcp 三次握手之后即可开始 http 通信;https 是在 http 与 tcp 之间加了一个 SSL/TLS 安全层,在 tcp 握手之后,还要进行 TLS 握手,才可以开始通信。

  • http 没有身份认证,存在安全隐患;https 使用证书系统来进行身份认证,使用 https 的网站需要到 CA 申请证书,一般免费证书较少,因而需要一定费用。

  • http 默认端口是 80,https默认端口 443

HTTPS的基本概念:

SSL:安全套接层,在 OSI 模型中处于第 5 层(会话层);TLS:1999年,SSL被改名为TLS(传输层安全),正式标准化,所以 TLS1.0 实际上就是 SSLv3.1,目前应用的最广泛的 TLS 是 1.2。

TLS 综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信,这些算法的组合被称为“密码套件”。

TLS 的密码套件命名:密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法。

如:ECDHE-RSA-AES256-GCM-SHA38

含义:握手时使用 ECDHE 算法进行密钥交换,用 RSA 签名和身份认证,握手后的通信使用AES 对称算法,密钥长度 256 位,分组模式是 GCM,摘要算法 SHA384 用于消息认证和产生随机数

机密性实现机制

前置知识

为什么要有机密性?

因为 http 是明文传输的,明文的意思就是头部字段等信息直接使用 ASCII 码这种人能看懂的符号传递,很容易被劫取和篡改。当我们使用 http 进行金钱方面的交易时,是毫无安全性可言的。

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

这里的“钥匙”就叫做“密钥”,加密前的消息叫“明文”,加密后的乱码叫“密文”,使用密钥还原明文的过程叫“解密”,是加密的反操作,加密解密的操作过程就是“加密算法”。

按照密钥的使用方式,加密可以分为两大类:对称加密和非对称加密。

对称加密

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

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

目前最常用的加密算法是 AES(高级加密标准),密钥长度可以是128、192 或 256。

对称算法还有一个“分组模式”的概念,它可以让算法用固定长度的密钥加密任意长度的明文,把小秘密(即密钥)转化为大秘密(即密文),常用的是 GCM、CCM 和Poly1305。

把上面这些组合起来,就可以得到 TLS 密码套件中定义的对称加密算法。比如,AES128-GCM,意思是密钥长度为 128 位的 AES 算法,使用的分组模式是 GCM;ChaCha20-Poly1305 意思是ChaCha20 算法,使用的分组模式是 Poly1305。

非对称加密

对称加密有一个缺点,就是无法解决“密钥交换”问题,因为在对称加密算法中只要持有密钥就可以解密。如果你和网站约定的密钥在传递途中被黑客窃取,那他就可以在之后随意解密收发的数据,通信过程也就没有机密性可言了。

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

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

RSA是最著名的非对称加密算法,它的安全性基于“整数分解”的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的。

ECC是非对称加密里的“后起之秀”,它基于“椭圆曲线离散对数”的数学难题,使用特定的曲线方程和基点生成公钥和私钥,子算法 ECDHE 用于密钥交换,ECDSA 用于数字签名。

HTTPS的加密方式

混合加密

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

所以,TLS里使用了”混合加密“方式:

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

完整性实现机制

完整性用来保证通信数据没有被篡改过。

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

摘要

实现完整性的手段主要是 摘要算法,也就是常说的散列函数、哈希函数。

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

最常用的摘要算法有 MD5、SHA-1,它们能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低,不够安全,在 TLS 里已经被禁止使用了。

目前 TLS 推荐使用的是 SHA-1 的后继者:SHA-2,SHA-2 实际上是一系列摘要算法的统称,总共有 6 种,常用的有 SHA224、SHA256、SHA384,分别能够生成 28 字节、32 字节、48 字节的摘要

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

比如,你发了条消息:“转账 1000 元”,然后再加上一个 SHA-2 的摘要。网站收到后也计算一下消息的摘要,把这两份“指纹”做个对比,如果一致,就说明消息是完整可信的,没有被修改。如果黑客在中间哪怕改动了一个标点符号,摘要也会完全不同,网站计算比对就会发现消息被窜改,是不可信的。

身份认证和不可否认

数字签名

数字签名就是经过私钥加密后的摘要。

为什么要对摘要使用私钥加密?

  • 因为黑客可以在修改数据内容的同时把摘要也修改掉,这样摘要就起不到任何作用了,所以要对摘要进行加密,防止被同时替换内容和摘要
  • 使用私钥加密,公钥解密的好处:无法被伪造。因为私钥保密,中间人没有私钥,就算窃取了数字签名,对签名进行修改,这时用公钥就解不开签名了,客户端也就发现消息被篡改了。

数字证书

还有一个问题,就是黑客冒充某网站给客户端一个假的公钥,如果你拿到了假的公钥,混合加密就完全失效了。所以,为了解决公钥的信任问题,需要引入“数字证书”。

数字证书就是可信任的权威机构(CA)颁发的服务器相关信息和其公钥。服务器通过向客户端提供证书来证明自己确实是某某网站。CA的公钥是公开的,客户端拿到证书后用CA公钥解开就可以拿到服务器公钥了。

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

通信过程中,

服务器需提供:

  • 数据内容(会话密钥加密)
  • 数字签名(服务器私钥加密后的摘要)
  • 数字证书(CA私钥加密的服务器公钥)

客户端收到后:

  • 先用CA公钥解密证书,把服务器公钥拿出来
  • 使用服务器公钥解密数字签名,得到摘要
  • 使用摘要算法对内容进行计算,算出的摘要与刚才解密出的摘要进行对比,如果一模一样,说明数据是完整的,没被篡改的

身份认证:使用CA颁发的数字证书来证明这个公钥确实是某某服务器的公钥。

不可否认:如果能用某某服务器的公钥解开数字签名,就说明这个消息只能是某某服务器发出的,不可能是别人冒充的,因为只有配对的公钥能解开唯一的私钥加密过的文件。

TLS 握手过程

在 http 协议中,TCP三次握手成功后,浏览器会立即发送请求报文;但是https协议,它还需要另一个握手过程(TLS握手),在TCP上建立安全连接,之后才是收发报文。TLS握手的主要目的是使用非对称加密交换对称密钥,这个对称密钥是由三个随机数生成的。

TLS握手一共4个回合:

1.客户端发出请求

  • 支持的协议版本,比如TLS 1.0版
  • 一个客户端生成的随机数,稍后用于生成"会话密钥"
  • 支持的密码套件(支持的加密方法)

2.服务器回应

  • 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
  • 一个服务器生成的随机数,稍后用于生成"会话密钥"
  • 确认使用的加密方法,比如RSA公钥加密
  • 服务器证书

3.客户端回应

客户端收到服务器回应以后,开始走证书链逐级验证,确认证书的真实性,如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信:

如果证书真实有效,从证书中拿出服务器公钥,向服务器发送下面三项信息:

  • 一个用服务器公钥加密随机数(pre-master key),防止被窃听
  • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送(Change Cipher Spec)
  • 客户端握手结束通知(Finished),表示客户端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要(hash值),再加密一下,供服务器校验

上面第一项的随机数,是整个握手阶段出现的第三个随机数,又称"pre-master key"。有了它以后,客户端和服务器就同时有了三个随机数,接着双方就用事先商定的加密方法,各自生成本次会话所用的同一把"会话密钥"。

4.服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的"会话密钥"。

然后,向客户端最后发送下面信息:

  • 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送(Change Cipher Spec)
  • 服务端握手结束通知(Finished),表示服务端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要(hash值),再加密一下,供客户端校验

TLS握手结束后,双方开始使用对称会话密钥进行加密通信。

HTTPS的优缺点

优点

  • 使用 HTTPS 协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;

  • HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议,要比 http 协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。

  • HTTPS 是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。

  • 谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等 HTTP 网站,采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。

缺点

  • HTTPS 协议握手阶段比较费时,会使页面的加载时间延长近 50%,增加 10% 到 20% 的耗电;

  • HTTPS 连接缓存不如 HTTP 高效,会增加数据开销和功耗

  • SSL 证书需要钱,功能越强大的证书费用越高,个人网站、小网站没有必要一般不会用。

  • HTTPS 协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,SSL 证书的信用链体系并不安全,特别是在某些国家可以控制 CA 根证书的情况下,中间人攻击一样可行。

参考文献

极客时间:透视TTP协议

SSL/TLS协议运行机制的概述