但是随后出现了一些不太明确的问题，例如：对TLS_RSA_EXPORT_WITH_RC4_40_MD5的支持是一个完整的“帽子”还是一个缺点？并且，如果这套
结果，诞生了一种用于编制索引的方法，该方法可以正式评估HTTPS连接的可靠性程度，分为31个点，分为5个组，从“根本不是HTTPS”到“保持！”
索引绝对不是，它是对NIST / HIPAA / PCI DSS等的“俄罗斯响应”。有两个原因。
首先，索引仅考虑HTTPS连接的可靠性。 Web服务器性能（NPN / ALPN /会话恢复）等物质索引不考虑，不是因为它是发明的。
第二个是NIST.SP.800和其他行业标准以NIST椭圆曲线为指导，其中几乎没有置信度，但是从ECDLP / ECC的角度来看存在一些问题（关于铝箔帽的活泼言论可以毫无例外地留在评论中）。
虽然谁知道，但随着时间的流逝，也许会随着索引的增长而增加具有
索引的主要思想是：到2020年，只有TLS 1.2及更高版本以及相应的密码套件和椭圆曲线集才能被视为``真实HTTPS''。现在是时候使用旧密码套件了，即使它们没有已知的漏洞，也已经成为历史。关于支持旧版客户端的需求的争论是对穷人的支持：Windows XP仍然很流行，但是其用户今天没有通过具有史前Schannel的Internet Explorer 8通过Internet漫游，而是使用基于Chromium / Firefox的浏览器来实现此目的...这同样适用于旧版Android的用户-他们要么安装了不依赖系统加密库的替代浏览器，要么即使通过HTTP也无法使用大多数现代网站（没有CSS3支持和其他现代举报协议）。
从这些立场出发，建议对方法草案进行批评。您是否考虑了所有问题？你拧得太紧了吗？你不是误解了吗？以下是条件列表，该链接是更详细的文本，包括注释和注释。
1.最低标准
1.1。使用加密TLS协议支持加密的HTTP（HTTPS）通信。通过TCP端口443通过协议标识符（URI方案）https建立HTTPS连接
。1.2。连接的加密由权威证书颁发机构（CA）颁发的有效，非自签名且非空的X.509版本3 TLS站点证书进行验证。
2.附加标准
2.1。在安全连接支持（BEAST，POODLE，GOLDENDOODLE等）的实现中，服务器不容易受到已知漏洞的影响
2.2。不支持TLS压缩。
2.3。仅支持服务器启动的安全重新协商；不支持客户端启动的重新协商。
3.推荐标准
3.1。 HTTP连接自动（强制）切换为HTTPS。
3.2。站点的TLS证书的公钥长度≥2048位。证书使用≥SHA256算法和RSA或ECDSA加密进行数字签名。
3.3。支持TLS协议版本1.2。
3.4。不支持SSL和TLS版本≤1.1。
3.5。支持基于强大算法的标准密码套件。
3.6。不支持弱，不合适和易受攻击的密码套件。
3.7。支持ECDLP / ECC安全的椭圆曲线。
3.8。设置密码套件的协调顺序。
3.9。使用Diffie-Hellman（DH）密钥协商算法的鲁棒参数。
3.10。支持重要的TLS扩展。
3.11。支持服务器名称指示（SNI）。
4.扩展标准
4.1。已发布完整且非冗余的TLS证书链及其正确的链序列。
4.2。该站点的TLS证书支持证书透明性。
4.3。该站点的TLS证书支持证书吊销列表（CRL）和在线证书状态协议（OCSP）。
4.4。备用链中的TLS证书符合标准1.2、4.1。
4.5。不支持ECDLP / ECC不安全椭圆曲线。
4.6。设置椭圆曲线的匹配顺序。
4.7。服务器响应标头包含带有includeSubDomains指令的HTTP Strict Transport Security标头。
5.奖励标准
5.1。该站点的TLS证书支持OCSP装订。
5.2。 TLS站点证书是使用组织验证（OV）或扩展验证（EV）程序颁发的。
5.3。支持TLS协议版本1.3。
5.4。设置了稳定的密码套件从更高的抵抗力到更不稳定的协调顺序（通过可比较的参数）。
5.5。站点域名的DNS资源记录包括CAA（证书颁发机构授权）记录。
5.6。站点域名的DNS资源记录包括DS和TLSA记录（支持DNSSEC和DANE）。
5.7。支持加密服务器名称指示（ESNI）。
5.8。HTTP响应标头包含带有upgrade-insecure-requests指令的Content-Security-Policy标头。