2018年8月，IETF批准了TLS 1.3标准TLS 1.0和
TLS 1.1很快将不复存在。
Firefox遥测已经表明，这些协议在HTTPS流量中所占的比例可忽略不计：分别为1.11％和0.09％。 现在，绝大多数站点都使用TLS 1.2。 并且在2019-2020年，所有领先的浏览器都打算完全放弃对TLS 1.0和TLS 1.1的支持。 在服务器端，建议立即禁用这些协议。
为什么禁用TLS 1.0和1.1
TLS 1.0将于明年1月发布20年。 他履行了自己的职责：多年来，该协议已经加密了数十亿（甚至数万亿）个连接。 随着时间的流逝，更好地了解应如何设计加密协议。 对密码可靠性的要求提高。 不幸的是，TLS 1.0和1.1无法满足这些要求。
Mozilla安全博客
写道 ，TLS 1.0和1.1的某些方面令人担忧。 最糟糕的是，它们不支持使用现代密码算法。 例如，握手时，他们必然需要使用SHA-1哈希算法。 在这些版本的TLS中，无法为ServerKeyExchange或CertificateVerify签名安装更强大的哈希算法。 因此，唯一的出路是升级到新版本的TLS。
2018年9月14日，互联网工程任务组（IETF）发布了
一份正式文件草案 ，其中
不建议使用TLS 1.0和1.1。 它尤其提到加密强度为2 ^ 77的SHA-1不能被现代标准认为是安全的：“ [攻击]的2 ^ 77次操作低于可接受的安全限制。”
IETF丢弃旧TLS的片段该文档提供了有关此决定原因的更详细的技术信息。 它讨论了对TLS 1.0的BEAST（针对SSL / TLS的浏览器攻击）攻击，即块密码，其中前一条消息（n-1）的最后一个加密块用作消息n的初始化向量。
TLS 1.1与TLS 1.0一起被淘汰，因为它没有本质上的不同，并且具有基本相同的缺点。 在此版本中，仅修复了TLS 1.0的一些限制，可以通过
其他方式避免这种情况（同样，我们正在谈论BEAST攻击）。
根据NIST的建议，邀请Web服务在2018年7月之前删除对旧版本TLS的支持。 这是由Amazon，CloudFlare，GitHub，KeyCDN，PayPal和许多其他Web服务完成的。
关机日期
所有领先浏览器的开发人员都同意遵守IETF的建议。
Chrome浏览器将是第一个拒绝支持旧版TLS的人。 开发人员计划从2019年1月发布的Chrome 72版本开始该过程：从现在开始，对于协议过期的网站，DevTools控制台中将显示警告。 Chrome 81版本将完全关闭，该版本计划于2020年3月发布（从2020年1月开始的初始版本）。
微软
承诺 “在2020年上半年”禁用协议。 Mozilla
宣布将于2020年3月在Firefox中禁用TLS 1.0和1.1。 苹果
计划在2020年3月取消对Safari浏览器的支持。
来自所有领先浏览器开发人员的新闻稿都非常协调：
现代TLS 1.2配置文件
根据IETF的建议，HTTPS连接的最小密码基础应为TLS 1.2。 根据Firefox遥测技术，它现在占HTTPS流量的93.12％（
根据Qualys称为94％ ），因此事实上的建议正在得到实施。
对Firefox Beta 62中的所有HTTPS连接使用TLS版本，2018年8月至9月的遥测数据TLS 1.2是HTTP / 2的先决条件，它
可以提高站点性能 。 如果没有特殊需要，Mozilla建议在服务器端使用
现代的 TLS 1.2
配置文件 。 现代配置文件提供了高级别的安全性，并包括以下参数：
- 密码套件 ： ECDHE-ECDSA-AES256-GCM-SHA384：ECDHE-RSA-AES256-GCM-SHA384：ECDHE-ECDSA-CHACHA20-POLY1305：ECDHE-RSA-CHACHA20-POLY1305：ECDHEC-E8-E12-ECDEHE-EEC-SHEE-EEC -RSA-AES128-GCM-SHA256：ECDHE-ECDSA-AES256-SHA384：ECDHE-RSA-AES256-SHA384：ECDHE-ECDSA-AES128-SHA256：ECDHE-RSA-AES128-SHA256
- TLS的椭圆曲线： prime256v1，secp384r1，secp521r1
- 证书类型： ECDSA
- 证书椭圆曲线： prime256v1，secp384r1，secp521r1
- 证书签名： sha256WithRSAEncryption，ecdsa-with-SHA256，ecdsa-with-SHA384，ecdsa-with-SHA512
- RSA密钥大小： 2048 （如果没有ECDSA）
- DH参数大小： 无 （完全禁用）
- ECDH参数大小： 256
- HSTS： 最大年龄= 15768000
- 证书切换： 否
专家指出，现在很少有证书颁发机构支持ECDSA签名，因此建议中允许使用ECDSA证书的RSA签名。
DHE密钥交换协议已从密码套件中完全删除，因为它比ECDHE慢，并且所有现代客户端都支持椭圆曲线。
SHA1签名算法也已从集合中完全删除：取而代之的是使用AES256的SHA384和AES128的SHA256。
Windows 7，Edge，Opera 17，Safari 9，Android 5.0和Java 8上的Firefox 27，Chrome 30，IE 11版本均支持此配置。如果需要对旧版浏览器的支持，则必须将密码套件的要求降低到
“平均”级别。 ，它被设置为默认级别。 建议仅在最极端的情况下才转向支持Windows XP / IE6的
向后兼容密码套件 。
不幸的是，今天，并非所有供应商都遵守有关TLS 1.2安全配置的建议。
2018年9月24日，arXiv.org发表了
有关此问题的
学术研究，该研究由来自加拿大蒙特利尔（加拿大）的康考迪亚大学的研究人员进行。 作者分析了13种不同类别（免费，开源，低级和高级）的网络TLS工具的17个版本的行为。
结论令人失望：几乎所有正在考虑的产品都是脆弱的：
例如，事实证明WebTitan，UserGate和Comodo没有执行TLS验证。 默认情况下，Comodo和Endian认为所有证书都需要验证，并且Cacheguard接受自签名TLS证书。
趋势科技，McAfee和Cacheguard使用预先生成的密钥对（尽管McAfee文档另有说明）。 来自UserGate，WebTitan，Microsoft和Comodo的四种设备接受它们自己的外部传递内容证书。 私钥存储在设备上，可以使用其他漏洞轻松提取。
BEAST攻击允许来自Microsoft，Cisco和TrendMicro的TLS用户使用身份验证cookie，而Sophos，Cacheguard，OpenSense，Comodo和Endian客户端则接受RSA-512证书，该证书的私钥很容易被伪造四个小时。
TLS 1.3的未来
2018年8月，IETF批准了
TLS 1.3标准，该标准
在Habré上进行了详细介绍 。 新版本的主要创新：
- 新的握手协议：由于多个步骤的组合，该过程的速度提高了一倍，握手机制变得更加安全，因为开发人员已删除了所有不使用AEAD模式的块加密算法；
- 使用提取和扩展密钥派生函数（HKDF）HMAC的新密钥生成过程；
- 使用RSA或DH密钥交换，CBC模式和SHA-1删除密码套件。
现在，初步版本中的1.3版支持Chrome和Firefox。 根据遥测，Firefox浏览器现在在TLS 1.3上建立的连接比在TLS 1.0和1.1上建立的连接更多。
显然，更新最重要的协议之一将影响许多站点，并且花费很长时间，因此，Internet将变得更加安全。
