RELATED CONTENT
TLS 1.3 已获国际互联网工程任务组 (IETF) 批准,其包含“安全、性能和隐私领域的重大革新”,与 TLS 1.2 不同,TLS 1.3 似乎自带升级驱动属性。不应仅是安全从业人员,业界各方都应对性能大幅提升的 TLS 1.3 所能提供的优势予以关注。
TLS 1.3 可以提供诸多切实益处;但更全面的加密也使得发现恶意流量和防御隐藏在加密流量中的攻击变得愈发艰难。而实质的威胁便是:F5 实验室近期研究发现,68% 的恶意软件隐藏在加密中。您可能需要采用全新的方法来获得所需可视性,同时保留使用更新的协议实现的性能增益。
TLS 1.3 可以提供诸多切实益处;但更全面的加密也使得发现恶意流量变得愈发艰难。
对比 TLS 1.2,TLS 1.3 可以提供一些重要改进。协议的易受攻击的可选部分已被删除,支持实现完美前向保密 (PFS) 所需的更强密码,并且握手过程已经得到显著缩短。
此外,相对而言,TLS 1.3 的实施应该会更加简单。您可以使用与 TLS 1.2 相同的密钥。客户端和服务器在均支持 TLS 1.3 握手时将自动协商该握手,而大多数主流浏览器会默认在最新版本上进行协商。
尽管仍然可以安全地部署 TLS 1.2,但一些备受关注的漏洞已经开始利用协议的可选部分和过时密码。TLS 1.3 删除了许多有问题的选项,并且仅包括对当前并无已知漏洞的算法的支持。
IETF 选择从 TLS 连接中删除所有不支持 PFS 的密码,包括 DES、AES-CBC、RC4 和其他不太常用的密码;还删除了执行所谓“重新协商”(该功能允许已具有 TLS 连接的客户端和服务器协商新参数、生成新密钥等)的能力。删除重新协商可以消除发动攻击的可能性。
默认情况下,TLS 1.3 还会启用 PFS。此加密技术为加密会话另附一层机密性,确保只有两个端点可以解密流量。借助 PFS,即便第三方会录制加密会话,并且稍后获取了服务器私钥的访问权限,也无法使用该密钥来解密会话。
在性能方面,TLS 1.3 免去了连接建立握手的整个往返时间,从而将加密延迟减半。另一项优势则是,当访问以前访问过的网站时,现在可以将第一条消息的数据发送到服务器。这称为“零往返时间”(0-RTT)。这些增强功能与高效的现代加密算法相结合,可以使 TLS 1.3 比 TLS 1.2 更快。
拥有全部这些益处后,是不是还会有其他隐患?这种担忧其实非常合理!使用 PFS 时,只有端点(Web 用户和应用服务器)才能解密流量。但是,您很可能拥有不止一个用于发现流经网络的恶意流量解决方案(例如下一代防火墙、入侵检测系统 (IDS) 或恶意软件沙盒)。或者,您可能已在托管应用前部署有 Web 应用防火墙、IDS 或分析解决方案。所有这些解决方案都位于用户与其连接到的应用或网站之间,因此通常无法察觉加密流量。
某些安全检查工具确实具有解密功能;但是,这通常会与工具性能下降、增加网络架构复杂性相关。此外,毫无根据地解密所有内容可能会牵扯出违反隐私法规的行为。
另有一点值得关注,由于存在重播攻击的可能性,一些安全专业人士对 0-RTT 功能颇有微词。如果 TLS 配置中未启用 0-RTT,又有可能会失去本来促使您实施升级的多数性能优势。
当下是否要实施 TLS 1.3 取决于您的需求和动机。有些浏览器并不支持 1.3,这可能会导致用户体验欠佳。此外,如果您采用潜在的易受攻击的功能(如重新谈判)并使用 PFS 进行应用的 TLS 1.2 配置,则会获得与 TLS 1.3 同等的所有安全和隐私益处。至于潜在的性能提升,您应该执行彻底的测试,查看是否契合您的应用,原因在于这种做法可能与禁用 0-RTT 所要付出的条件并不对等。
无论决定如何,当下您还是可以使用以前版本的 TLS。Google 已经宣布,会在 2020 年弃用 TLS 1.0 和 1.1,因此对 TLS 1.2 的使用还会持续一段时间。而且,除了某些点对点 API 连接之外,您可能还需要继续支持 TLS 1.2(可能还有 1.1)一段时间,以确保不会中断用户与应用的连接。
无论 TLS 版本如何,您都需要了解加密威胁来保护您的业务。允许数据包检查的基于 SSL/TLS 的解密设备可以拦截加密流量、解密、检查和重新加密进出网络的不受信任的 TLS 流量,但这仍旧有所欠缺。
允许数据包检查的基于 SSL/TLS 的解密设备可以拦截加密流量、解密、检查和重新加密进出网络的不受信任的 TLS 流量,但这仍旧有所欠缺。
安全团队和网络运营人员发现,设置解密区域并不容易。他们通常需要采用手动菊花链或繁琐的配置来管理整个安全堆栈的解密/加密,随即意外情况频发。
F5 SSL Orchestrator 可以提供可视性,但可以通过编排与包进行区分,这种编排可以根据风险和动态网络条件向服务链提供基于策略的流量转向。由于 SSL/TLS 和 HTTP 均作为完整代理,因此 SSL Orchestrator 可以做出明智决策,将入站和出站流量引导到安全堆栈中的任意检查工具组合。
无论入站和出站加密要求的复杂程度如何,SSL Orchestrator 均可以赋予检查解决方案可视性,助力达成稳定的网络和应用安全性。