传输层安全协议 TLS 1.3 RFC 8446 正式发布

by admin on 2020年3月23日

TLS 1.3 是国际互联网工程任务组(IETF)制定的 TLS
新标准。在过去的五年里,IETF 一直致力于 TLS 1.3 协议的标准制定工作。TLS
用于保护 Web(以及更多其他领域),提供加密并确保每个 HTTPS 网站和 API
的真实性。

摘选自 High Performance Browser
Networking

引言

早些年,HTTP协议传输的数据都是没有加密的,也就是明文的,因此使用HTTP协议传输隐私信息是非常不安全的,为了保证这些隐私数据能加密传输,网景公司设计了SSL(Secure
Sockets Laver)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。

由于苹果规定2017年1月1日以后,所有APP都要使用HTTPS进行网络请求,否则无法上架。iOS9以后,iOS系统越来越重视用户的隐私和安全,访问相机、位置等信息都需要添加一些对应的key。在2017年,Apple的AppStore审核机制也会更加严格,使自己的应用尽快的支持Https请求,是开发者不得不做的项目修改。

最新版本的 TLS —— TLS 1.3 (

SSL 协议最初是由 Netscape
开发,以便实现电子商务交易安全,这需要加密个人数据,身份验证以及完整性保证。为了实现这些功能,SSL
协议在应用层实现,直接在 TCP 之上,确保为其上的协议(HTTP, email,
即时通讯等)提供安全,不变的通信。
一旦 SSL
正确使用,第三方观察者(中间人)只能推测连接的端点,加密的类型,以及数据传输的频率和大致的规模,但是无法读取或者修改实际的数据。

一.HTTP与HTTPS

在 IETF 中,协议又被称为 RFC。TLS 1.0 是 RFC 2246,TLS 1.1 是 RFC
4346,TLS 1.2 是 RFC 5246。现在,TLS 1.3 则为 RFC 8446。RFC
通常按顺序发布,并保留 46 作为 RFC 编号的一部分。

图片 1

HTTP

HTTP是一种常用的网络传输协议,基于TCP的一种应用层协议。但是在安全性方便存在着一些问题。例如:
1.HTTP协议在传输数据时是明文的,凡是懂一点小技术的人都可以通过一些抓包工具截取传输的数据。
2.HTTP协议在传输数据时无法保证数据的完整,在截获明文数据后,很容易就可以将其篡改,这也是一些网页老是被植入一些恶意不健康的广告原因之一。
3.HTTP协议在传输数据时无法保证真实性,这是最重要的一点!!!对于一些太单纯的人容易误入了域名欺骗的钓鱼网站,极容易对用户带来财产损失。
综上所述,于是乎就推出一种更完善更安全的HTTPS网络传输协议。

推动制定 TLS 1.3 协议的主要诉求是:

tls.PNG

HTTPS

再讲HTTPS协议,首先你需要弄明白什么是SSL/TLS,SSL(Secure Sockets
Layer)安全套接层。为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure
Sockets
Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。SSL目前的版本是3.0,被IETF(Internet
Engineering Task Force)定义在RFC 6101中,之后IETF对SSL
3.0进行了升级,于是出现了TLS(Transport Layer Security) 1.0,定义在RFC
2246。实际上我们现在的HTTPS都是用的TLS协议,但是由于SSL出现的时间比较早,并且依旧被现在浏览器所支持,因此SSL依然是HTTPS的代名词,但无论是TLS还是SSL都是上个世纪的事情,SSL最后一个版本是3.0,今后TLS将会继承SSL优良血统继续为我们进行加密服务。

关于HTTPS更多资料可参考:
HTTPS
科普扫盲帖
HTTPS中的加密算法相关概念
HTTPS
协议降级攻击原理
HTTPS 工作原理和 TCP
握手机制
SSL/TLS协议运行机制的概述
SSL/TLS
握手优化详解

  • 减少握手的延迟时间

  • 对更多的握手消息进行加密

  • 提高应对跨协议攻击的机动性

  • 删除遗留下来的旧功能

当 SSL 协议被 IETF 标准化时,它被重新命名为 Transport Layer
Security(TLS)
。许多人互换使用 SSL 和 TSL
名称,但技术上来说,它们是不同的,因为它们描述了协议的不同版本。

目前 TLS 1.3 RFC 8446
已正式发布,相信随着采用的增加,新协议将使互联网更快、更安全。

SSL 2.0 第一个公开发布的协议版本,但很快就由于被发现一系列安全漏洞而被
SSL 3.0 所替代。由于 SSL 协议的所有权归属于 Netscape,在 IETF
的努力下形成了一个标准化的协议—— RFC 2246,于 1999 年 1 月发布,被称为
TLS 1.0。从那时起,IETF
一直在持续迭代协议来解决安全漏洞,并增加它的能力:TLS 1.1 (RFC 2246)
发布于 2006 年 4 月,TLS 1.2 (RFC 5246) 发布于 2008 年 8 月,目前 TLS
1.3 也已经释出。
也就是说,不要被丰富的数字版本所迷惑:你的服务器应始终使用最新的稳定的
TLS
协议版本以确保最佳的安全性,功能和性能保证。实际上,一些关键性的功能,比如
HTTP/2,明确要求 TLS 1.2 或更高版本否则终止连接。高安全性和高性能并存。

详情请查看 https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/。

TLS 被设计在可靠的传输协议 (TCP)
之上运行,然而,它同样可以在数据报协议之上运行,如 UDP。Datagram
Transport Layer Security (DTLS)
协议,定义在 RFC 6347,建立在 TLS
协议的基础上并且在保留数据报传输模型的同时提供相似的安全保证。

(文/开源中国)    

TLS 握手

在客户端和服务器开始利用 TLS
交换应用数据之前,必须协商好加密隧道:客户端和服务器必须确定使用的 TLS
协议版本,选择加密套件(ciphersuite),以及验证证书是否有效。不幸的是,每个步骤都需要新的数据包往返客户端和服务器,这将为所有
TLS 连接增加启动延迟。

图片 2

tls_handshake.PNG

  • 0 ms
    TLS 运行在可靠的传输层之上(TCP),这意味着我们必须先实现 TCP
    三次握手,需要一个完整的往返。
  • 56 ms
    TCP 连接就位,客户端向服务器发送一些纯文本的规范,比如正在运行的 TLS
    协议版本,支持的加密套件列表,以及其他可能要使用的 TLS 选项。
  • 84 ms
    服务器选择 TLS
    协议版本进行下一步的通信,根据客户端提供的列表决定加密套件,然后发送响应到客户端。或者可选的,服务器还可以发送客户端证书请求和其他
    TLS 扩展参数。
  • 112 ms
    假设两端协商好相同的协议版本和加密方式,并且客户端对服务器提供的证书表示满意,客户端将启动
    RSA 或 Diffie-Hellman 密钥交换,用于建立随后会话的对称密钥。
  • 140 ms
    服务器处理客户端发送来的密钥交换参数,通过验证 MAC
    来检查消息的完整性,并返回加密后的 Finished 消息给客户端。
  • 168 ms
    客户端通过协商好的对称性密钥解密消息,验证
    MAC,假如一切顺利,则隧道建立并且可以发送应用数据。

正如上面的描述,新的 TLS 连接需要两次往返的回路实现 “full
handshake”——这是个坏消息。然而实际上,优化的部署可以做的更好并提供一致的一次往返
TLS 握手:

  • False Start 是一个 TLS
    协议的扩展,允许客户端和服务器在握手部分完成时就可以传输加密后的应用数据。例如,一旦发送了
    ChangeCipherSpecFinished
    信息,而不用等待对方执行相同的操作。这种优化可以减少新的 TLS
    连接的开销到一次往返;可以参考 Enable False
    Start。
  • 假如客户端之前与服务器通信过,可以使用 “abbreviated
    handshake”,这需要一次往返,并且允许客户端和服务器通过重新使用之前协商好的安全会话参数来减少
    CPU 开销;可以参考 TLS Session
    Resumption。

结合上述两种优化可以使我们为新的或者重来的访问提供一致的 1-RTT TLS
握手,加上重用之前协商的会话参数减少计算资源的开销。确保在您的部署中利用好这些优化。

TLS 1.3 的设计目标就是减少延迟开销:新设置的安全连接为
1-RTT,重用会话的为 0-RTT!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图