本文是关于TLSv1.3采用的三部分系列的第三部分也是最后一部分。它解决了网络加密和监控的选项，包括备用会话加密协议。
通过TLSv1.3的批准，并在IETF出版物队列中，是时候考虑部署选项和障碍，并规划此修订内在的变化。
无论您计划升级它，可能需要对内部应用程序和网络体系结构进行重要规划，而对于基于Internet的会话则需要更少的规划。为即将发布的版本提供支持库和浏览器。
作为负责TLSv1.3的前IETF地区负责人，协助管理TLSv1.3监控和管理网络的艰难对话并确保它们可能发生。有选项可以保持可见性，但为网络确定和实施最合适的选择需要仔细规划。
在理想的世界中，组织可以在其内部网络中无缝地将TLSv1.2的使用升级到TLSv1.3
对于一些企业来说，这种情况会发生，他们已经转移到了没有边界或没有单一可辨别的防火墙网关接入点的网络。这些网络已经依赖于安全的TLS会话-这是更难以拦截的-遵循RFC7525中TLSv1.2的部署最佳实践。
在其他情况下，企业可能会放弃依靠带外或被动TLS侦听中间件，而是依靠端点上提供的信息和主动拦截来通过基于代理的解决方案进行监控。如果您的组织仍然依赖于TLSv1.0或TLSv1.1，那么您应该最低限度地转移到根据最佳实践配置的TLSv1.2，因为弃用较旧的加密算法和密码套件并提供前向保密。
其他的网络体系结构会导致巨大的费用来检修并且不能够拦截加密的流量，但仍然希望在其内部网络上应用会话加密的最佳实践。
因此，IETF已经提出了迄今未成功的工作，以便在TLSv1.3中提供可见性。这些企业可能需要一个技术桥梁，使他们能够在考虑转向会话协议的情况下继续监控其当前的方式，而会话拦截会更困难。到目前为止，这两项提案都没有推向采用。
提案包括TLS1.3中的数据中心使用静态Diffie-Hellman和数据中心中可见性协商的TLS1.3选项。阻碍他们前进的两个技术参数或障碍包括，工作组希望确保技术或扩展可能受数据中心或企业的约束，并且需要客户选择加入。问题在于，如果有方法拦截流量，那么除了那些已经可以访问服务器上的数据或TLS会话的终止点的人之外，还可以由未知或恶意的人员完成。
计划继续使用TLSv1.2
那些计划继续使用带有RSA静态密钥的TLSv1.2进行被动拦截以管理和监控功能的公司有以下几种选择：
留在TLSv1.2中;弃用可能还有很长的路要走！
目前的法规不要求在内部网络上进行会话加密，所以不太可能会看到这个特定的版本被认为是不允许在内部网络上使用的。您组织的安全策略和体系结构可能会指导选择适当的会话加密协议。
通过对象级加密或标记化来保护数据是必需的，并且将提供当前法规规定的保护。
在内部网络上使用会话加密是最好的做法，目前TLSv1.2中没有任何已知的漏洞可能会强制其弃用。
TLSv1.1在12年前已经标准化，并将在2018年6月与TLSv1.0一起在浏览器供应商和内容交付网络中被弃用。
在POODLE迫使它被业界和IETF弃用之前，SSLv3已经进行了20年的部署。除非浏览器和库中仍存在重大漏洞和支持，否则不应急于从您的内部网络中删除TLSv1.2。
NIST的800-52草案修订版“要求所有*TLS服务器和客户都支持配置了基于FIPS的密码套件的TLS1.2，并建议代理机构制定迁移计划以在2020年1月1日之前支持TLS1.3。”该建议符合部署TLSv1.2的最佳实践。NIST也弃用TLSv1.0，并建议不要在指南草案中使用TLSv1.1。
注意：请务必逐步淘汰任何对TLSv1.0和TLSv1.1的使用。对于IETF尚未弃用的这些协议的支持可能会在6月/7月的时间段内减少，因为CDN和其他组织将弃用他们对这些协议的支持。浏览器支持计划尚不清楚，但来自AlexaTop100万的Web流量统计数据显示，TLSv1.0占流量的0.8％，而TLSv1.1更低。
转换您的网络和安全体系结构以在端点上执行监视，以准备过渡到TLSv1.3
评估应用程序和系统的日志和调试级别日志。与供应商合作填补可视性方面的空白。
消除使用被动地观察和解密流量的中间件。看看这些功能是否需要或者可以在网络中的其他位置执行，最好是边缘。通过代理（主动）进行监控仍然可以通过TLSv1.3进行，并且与TLSv1.2部署中的最终用户类似。基于代理的监控是您终止TLS会话，执行监控，然后启动新会话的地方。
寻找人工智能和机器学习解决方案来处理来自终端的日志和警报
这里有创新空间来更好地扩展安全和系统管理。未来和新兴的协议选项可以更好地满足您的内部网络管理和监控要求，可以考虑采用更长期的解决方案。
以下三种可能性中的前两种假定TLS在面向Internet的边缘终止，而备用加密协议可以在服务器到服务器的配置中内部部署-第三种可以与TLS并行运行。
TCPcrypt
机会安全性应用于TCP会话，使头部暴露。机会性安全意味着会话没有被认证，这简化了部署，因为它可以很容易地被自动化，但也使得它可以被拦截。
IPsec传输模式会将源地址和目标地址信息暴露给网络管理人员。
组键控选项已经标准化：GDOI和MIKEY。
目前还鲜为人知，但许多实现允许调试会话提供完整，清晰的会话要收集在端点的文本进行故障排除。
为了使IPsec传输模式成为真正的竞争者，需要实现互操作性工作，但如果有需求，可能会发生此项工作。在IPsec的维护（IPsecMe）工作组是相当活跃。这需要客户推动他们的供应商才能看到支持。或者，可以从端点使用IPsec隧道模式来保留数据包标头中的源地址和目标地址信息。
IETF的网络接口服务功能（I2NSF）工作组正在积极开展工作，以便通过数据中心甚至托管环境中的SDN控制器自动配置IPsec。
为数据中心使用而设计的多方协议
候选解决方案旨在与TLS并行运行。据我了解，患者的努力正在寻找解决方案，使所有监测点都可以看到客户可以看到存在哪些监测点，同时保持前向保密。
有几个候选解决方案，并且可能会在IETF中形成一个努力，在这个协议中专门为这个用例设计了一个协议。
如果感兴趣，您可以跟随并参与患者邮件列表，查看是否可以将工作转化为安全的解决方案，以满足企业和数据中心的需求。
TLSv1.3采用=技术差距
最近，在2018年RSA大会和2018年戴尔技术世界大会上，针对TLSv1.3会议的受众进行了有关计划采用的调查。计划用于内部网络的TLSv1.3部署很少。我认为这是一个技术差距问题。
标准工作和行业已经提出了维护安全会话的工具，但仍然必须为通过中间盒技术被动地拦截流量的网络和安全管理功能提供路径。
在采用阶段之前，我们处于学习曲线。但是，这些工具已经准备就绪，实现已经在互操作性方面进行了充分测试，并且对于包括基于Internet的会话在内的一些使用案例而言，安全优势是明确的。（黑客周刊）