本博客自即日起仅支持 TLSv1.2 及以上安全传输层协议

自从又拍云 CDN 开始支持“最低 TLS 版本功能”后(可参考【又拍云 CDN 又增添两大给力功能支持】一文),明月就第一时间的用上了,经过最近一周的测试和体验后,果断将目前服务器、 CDN 的最低 TLS 版本限定在 TLSv1.2 以上了,目前凡是支持 TLSv1.3 的浏览器均可以完美的支持,TLSv1.2 已经是当今主流浏览器默认就支持的协议了。

对 TLS 安全传输层协议有兴趣的可以看看下面百度百科上的介绍引用:

安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议(例如 TCP)上面。

协议结构

TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息 [1] 。
TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等,然后将它们传送到高层客户机。

TLS 连接状态指的是 TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。

TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算:记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。TLS 握手协议由三个子协议组构成,允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。

TLS 握手协议:

1.改变密码规格协议

2.警惕协议

3.握手协议

TLS 记录协议

TLS 记录协议提供的连接安全性具有两个基本特性:

私有――对称加密用以数据加密(DES 、RC4 等)。对称加密所产生的密钥对每个连接都是唯一的,且此密钥基于另一个协议(如握手协议)协商。记录协议也可以不加密使用。

可靠――信息传输包括使用密钥的 MAC 进行信息完整性检查。安全哈希功能( SHA、MD5 等)用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作,但一般只能用于这种模式,即有另一个协议正在使用记录协议传输协商安全参数。

TLS 记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证,协商加密算法和加密密钥。

TLS 握手协议

TLS 握手协议提供的连接安全具有三个基本属性:

1.可以使用非对称的,或公共密钥的密码术来认证对等方的身份。该认证是可选的,但至少需要一个结点方。

2.共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密,即使是进入连接中间的攻击者也不能。

3.协商是可靠的。没有经过通信方成员的检测,任何攻击者都不能修改通信协商。

综述

TLS 的最大优势就在于:TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而,TLS 标准并没有规定应用程序如何在 TLS 上增加安全性;它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。

TLS 包含三个基本阶段:

1.对等协商支援的密钥算法

2.基于私钥加密交换公钥、基于 PKI 证书的身份认证

3.基于公钥加密的数据传输保密

虽然看着好复杂的样子,但是归根结底其实这就是一个增强 HTTPS 安全性和执行效率的协议,HTTPS 被人诟病的影响网站载入速度其实就是早期 TLS 协议不完善造成的,而即将正式发布的 TLSv1.3 就是在速度上提升非常的明显,如果你是独立 VPS 主机的话,明月建议尽快升级 TLS 协议到最高版本。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: