Eine Einladung zur Erörterung der Methode zum Erstellen eines Index der HTTPS-Sicherheit von Websites

Wir haben bereits mehrere Überprüfungen der HTTPS-Unterstützung auf den Websites der russischen Behörden veröffentlicht und stehen vor der unvermeidlichen Notwendigkeit, die Kriterien für die Bewertung klarer zu formalisieren. Es ist klar, dass wenn der Server die Sicherheit der Verbindung mit dem TLS-Zertifikat einer anderen Person "bestätigt", dies ein "Hut" ist und die entsprechende Site keinen hohen Platz in der "Bewertung" einnimmt.



Dann stellen sich jedoch weniger eindeutige Fragen: Ist die Unterstützung von TLS_RSA_EXPORT_WITH_RC4_40_MD5 ein vollständiger "Hut" oder nur ein Nachteil? Und wenn diese Chiffresuite aus den 60er und 90er Jahren dem Kunden als erste zur Einigung angeboten wird? Und wenn alle anderen nicht viel besser sind? Und was ist "viel besser"? Angenommen, TLS_PSK_DHE_WITH_AES_128_CCM_8 ist besser oder nicht?



Als Ergebnis wurde eine Methode zur Erstellung eines Index entwickelt, mit der der Grad der Zuverlässigkeit einer HTTPS-Verbindung anhand von 31 Punkten, die in 5 Gruppen unterteilt sind, formal bewertet werden kann: "Dies ist überhaupt kein HTTPS", um "Schritt zu halten!"



Was der Index definitiv nicht ist, ist die "russische Antwort" auf NIST / HIPAA / PCI DSS usw. aus zwei Gründen.



Erstens berücksichtigt der Index nur die Zuverlässigkeit der HTTPS-Verbindung. Webserverleistung (NPN / ALPN / Wiederaufnahme der Sitzung) usw. Der Index berücksichtigt keine Materie, er wurde dafür nicht erfunden.



Das zweite ist, dass NIST.SP.800 und andere Industriestandards von den elliptischen NIST-Kurven geleitet werden, in denen es kaum mehr als kein Vertrauen gibt, aber es gibt Fragen aus Sicht von ECDLP / ECC (eine freche Bemerkung über einen Folienhut kann ausnahmslos in den Kommentaren hinterlassen werden ).



Obwohl wer weiß, wird im Laufe der Zeit vielleicht ein souveräner Standard mit Spiritualität und "Grasshopper" - und "Magma" -Klammern aus dem Index wachsen (aber nicht bevor die IETF sie als Teil der Standard-Chiffresuiten für TLS erkennt).



Die Grundidee des Index: Im Jahr 2020 kann nur TLS 1.2 und höher mit dem entsprechenden Satz von Chiffresuiten und elliptischen Kurven als "echtes HTTPS" betrachtet werden. Es ist Zeit für alte Chiffresuiten, auch wenn sie keine bekannten Schwachstellen haben, in den Mülleimer der Geschichte. Argumente für die Notwendigkeit, ältere Clients zu unterstützen, sprechen für die Armen: Windows XP ist nach wie vor beliebt, aber seine Benutzer durchstreifen das Internet heute nicht über Internet Explorer 8 mit seinem prähistorischen Schannel, sondern verwenden für diesen Zweck Chromium / Firefox-basierte Browser, die NSS verwenden ... Gleiches gilt für Benutzer älterer Android-Versionen - sie haben entweder einen alternativen Browser installiert, der nicht auf der System-Kryptobibliothek basiert, oder sie können die meisten modernen Websites nicht einmal über HTTP verwenden (ohne CSS3-Unterstützung und andere moderne Whistleblowing-Angebote).



Aus diesen Positionen wird vorgeschlagen, den Entwurf der Methodik zu kritisieren. Hast du alles berücksichtigt? Haben Sie die Muttern zu fest angezogen? Haben Sie nichts falsch dargestellt? Unten finden Sie eine Liste mit Kriterien. Der Link enthält einen detaillierteren Text mit Notizen und Kommentaren .



1. Mindestkriterien



1.1. Die verschlüsselte HTTP-Kommunikation (HTTPS) wird mithilfe des kryptografischen TLS-Protokolls unterstützt. Eine HTTPS-Verbindung wird mit der Protokollkennung (URI-Schema) https über TCP-Port 443 hergestellt.



1.2. Die Verschlüsselung der Verbindung wird durch ein gültiges, nicht selbstsigniertes und nicht leeres X.509 Version 3 TLS-Standortzertifikat überprüft, das von einer autorisierenden Zertifizierungsstelle (CA) ausgestellt wurde.



2. Zusätzliche Kriterien



2.1. Der Server ist nicht anfällig für bekannte Schwachstellen bei der Implementierung der Unterstützung für sichere Verbindungen (BEAST, POODLE, GOLDENDOODLE usw.).



2.2. TLS-Komprimierung wird nicht unterstützt.



2.3. Es wird nur eine vom Server initiierte sichere Neuverhandlung unterstützt. Vom Kunden initiierte Neuverhandlungen werden nicht unterstützt.



3. Empfohlene Kriterien



3.1. Die HTTP-Verbindung wechselt automatisch (erzwungen) zu HTTPS.



3.2. Der öffentliche Schlüssel der TLS-Zertifikate der Site ist ≥ 2048 Bit lang. Das Zertifikat wird mit dem ≥SHA256-Algorithmus mit RSA- oder ECDSA-Verschlüsselung digital signiert.



3.3. TLS-Protokoll Version 1.2 wird unterstützt.



3.4. SSL- und TLS-Version ≤1.1 werden nicht unterstützt.



3.5. Standard-Chiffresuiten, die auf starken Algorithmen basieren, werden unterstützt.



3.6. Schwache, ungeeignete und anfällige Cipher Suites werden nicht unterstützt.



3.7. ECDLP / ECC-sichere elliptische Kurven werden unterstützt.



3.8. Die Reihenfolge der Koordination der Chiffresuiten ist festgelegt.



3.9. Die robusten Parameter der Diffie-Hellman (DH) -Schlüsselvereinbarungsalgorithmen werden verwendet.



3.10. Wichtige TLS-Erweiterungen werden unterstützt.



3.11. Die Servernamenanzeige (SNI) wird unterstützt.



4. Erweiterte Kriterien



4.1. Eine vollständige und nicht redundante TLS-Zertifikatkette wurde mit der richtigen Kettenreihenfolge veröffentlicht.



4.2. Das TLS-Zertifikat der Site unterstützt die Zertifikatstransparenz.



4.3. Das TLS-Zertifikat der Site unterstützt die Zertifikatsperrliste (Certificate Revocation List, CRL) und das Online Certificate Status Protocol (OCSP).



4.4. TLS-Zertifikate in alternativen Ketten entsprechen den Kriterien 1.2, 4.1.



4.5. Unsichere elliptische ECDLP / ECC-Kurven werden nicht unterstützt.



4.6. Die Reihenfolge der Anpassung der elliptischen Kurven wird festgelegt.



4.7. Serverantwort-Header enthalten den HTTP Strict Transport Security-Header mit der Anweisung includeSubDomains.



5. Bonuskriterien



5.1. Das TLS-Zertifikat der Site unterstützt OCSP Stapling.



5.2. Das TLS-Standortzertifikat wird mithilfe eines Organisationsverifizierungsverfahrens (OV) oder eines erweiterten Validierungsverfahrens (EV) ausgestellt.



5.3. TLS-Protokoll Version 1.3 wird unterstützt.



5.4. Die Reihenfolge der Koordination stabiler Chiffresuiten von widerstandsfähiger zu weniger stabil (durch vergleichbare Parameter) wird festgelegt.



5.5. Die DNS-Ressourceneinträge für den Site-Domänennamen enthalten einen CAA-Eintrag (Certification Authority Authorization).



5.6. Die DNS-Ressourceneinträge für den Site-Domänennamen enthalten DS- und TLSA-Einträge (DNSSEC und DANE werden unterstützt).



5.7. Die verschlüsselte Servernamenanzeige (ESNI) wird unterstützt.



5.8. Die HTTP-Antwortheader enthalten einen Content-Security-Policy-Header mit der Direktive zum Upgrade unsicherer Anforderungen.