しかし、その後、明確な疑問が生じます。たとえば、TLS_RSA_EXPORT_WITH_RC4_40_MD5のサポートは完全な「ハット」なのか、それとも単なる欠点なのか。そして、
その結果、「これはHTTPSではない」から「維持する」までの5つのグループに分けて、HTTPS接続の信頼性の程度を31ポイントで正式に評価できるインデックスを作成する方法が生まれました。
インデックスが絶対にないのは、NIST / HIPAA / PCIDSSなどに対する「ロシアの対応」です。 2つの理由で。
まず、インデックスはHTTPS接続の信頼性のみを考慮します。 Webサーバーのパフォーマンス（NPN / ALPN /セッション再開）など。マターインデックスは、それが発明されたという理由ではなく、考慮していません。
2つ目は、NIST.SP.800やその他の業界標準は、信頼性がほとんどないNIST楕円曲線によって導かれているということですが、ECDLP / ECCの観点からは疑問があります（フォイルハットについてのはつらつとした発言は理由なしにコメントに残すことができます）。
誰が知っているとしても、時間の経過とともに、
インデックスの主なアイデア：2020年には、対応する暗号スイートと楕円曲線のセットを備えたTLS1.2以降のみが「実際のHTTPS」と見なすことができます。古い暗号スイートは、たとえ既知の脆弱性がなくても、歴史のゴミ箱に入る時が来ました。レガシークライアントをサポートする必要性についての議論は貧しい人々を支持しています：Windows XPは依然として人気がありますが、そのユーザーは今日、先史時代のSchannelを備えたInternet Explorer 8を介してインターネットをローミングしませんが、この目的でNSSを使用するChromium / Firefoxベースのブラウザを使用します..。同じことが古いバージョンのAndroidのユーザーにも当てはまります。システム暗号ライブラリに依存しない代替ブラウザをインストールしたか、HTTP経由でもほとんどの最新サイトを使用できません（CSS3サポートやその他の最新の口笛を吹く取引なし）。
これらの立場から、方法論草案を批判することが提案されています。すべてを考慮に入れましたか？ナットをきつく締めすぎていませんか？あなたは何かを偽って伝えませんでしたか？以下は基準のリストであり、リンクはメモとコメントを含むより詳細なテキストです。
1.最小基準
1.1。暗号化されたHTTP（HTTPS）通信は、暗号化TLSプロトコルを使用してサポートされます。 HTTPS接続は、TCPポート443を介してプロトコル識別子（URIスキーム）httpsで確立されます。1.2
。接続の暗号化は、権限のある認証機関（CA）によって発行された、有効で、自己署名されておらず、空ではないX.509バージョン3TLSサイト証明書によって検証されます。
2.追加の基準
2.1。サーバーは、安全な接続サポート（BEAST、POODLE、GOLDENDOODLEなど）の実装における既知の脆弱性の影響を受けません
。 TLS圧縮はサポートされていません。
2.3。サーバーが開始する安全な再ネゴシエーションのみがサポートされます。クライアントが開始する再ネゴシエーションはサポートされていません。
3.推奨基準
3.1。 HTTP接続は自動的に（強制的に）HTTPSに切り替わります。
3.2。サイトのTLS証明書の公開鍵は2048ビット以上の長さです。証明書は、RSAまたはECDSA暗号化を使用した≥SHA256アルゴリズムを使用してデジタル署名されています。
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証明書は、Certificate Revocation List（CRL）およびOnline Certificate Status Protocol（OCSP）をサポートしています。
4.4。代替チェーンのTLS証明書は、基準1.2、4.1に準拠しています。
4.5。 ECDLP / ECCの安全でない楕円曲線はサポートされていません。
4.6。楕円曲線のマッチング順序を設定します。
4.7。サーバー応答ヘッダーには、includeSubDomainsディレクティブを含むHTTP Strict TransportSecurityヘッダーが含まれています。
5.ボーナス基準
5.1。サイトのTLS証明書は、OCSPステープルをサポートしています。
5.2。 TLSサイト証明書は、組織検証（OV）または拡張検証（EV）手順を使用して発行されます。
5.3。 TLSプロトコルバージョン1.3がサポートされています。
5.4。安定性の高い暗号スイートから安定性の低いものへの調整の順序（同等のパラメーターによる）が設定されます。
5.5。サイトドメイン名のDNSリソースレコードには、CAA（Certification Authority Authorization）レコードが含まれます。
5.6。サイトドメイン名のDNSリソースレコードには、DSおよびTLSAレコードが含まれます（DNSSECおよびDANEがサポートされています）。
5.7。暗号化されたサーバー名表示（ESNI）がサポートされています。
5.8。サーバー応答ヘッダー（HTTP応答ヘッダー）には、upgrade-insecure-requestsディレクティブを含むContent-Security-Policyヘッダーが含まれています。