Frage In Chrome wird ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY über HTTPS mit dem lokalen Webserver verbunden


Zusammenfassung

Chrome meldet ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY wenn ich versuche, eine Verbindung zu meinem lokalen Webserver über HTTPS herzustellen. Ich bin mir fast sicher, dass dieses Problem mit meinem letzten Windows 10-Upgrade zu tun hat, aber ich weiß nicht, wie ich es beheben kann.

Was hat funktioniert?

Hier ist die Kette der Ereignisse, wobei ich Windows 8.1 Pro am Anfang installiert habe:

  1. Ein selbstsigniertes Zertifikat generiert, das mithilfe des folgenden Befehls als vertrauenswürdige Stammzertifizierungsstelle verwendet werden soll: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
  2. Ein anwendungsspezifisches Zertifikat von der vertrauenswürdigen Stammzertifizierungsstelle generiert: makecert.exe -pe -ss My -sr LocalMachine -n "CN=myapp.local, OU=Development" -is Root -ir LocalMachine -in local -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -a sha512 -e 01/01/2020 -sky -eku 1.3.6.1.5.5.7.3.1
  3. Hinzugefügt a HOSTS Dateieintrag für myapp.local das zeigt auf 127.0.0.1
  4. Erstellt eine IIS 8.5-Anwendung, die an die myapp.local Domäne und hört nur auf HTTPS-Anfragen
  5. Zugewiesen die myapp.local Zertifikat für die Website

Mit dieser Einrichtung hatte ich keine Probleme, von Chrome aus auf meine lokale Website zuzugreifen, ohne dass ein Zertifikat oder Sicherheitswarnungen angezeigt wurden. Der Browser zeigte erwartungsgemäß das grüne Vorhängeschloss.

Was nicht funktioniert

Kürzlich habe ich auf Windows 10 aktualisiert. Ich wusste zu der Zeit nicht, dass Windows 10 mit IIS 10 ausgeliefert wird, das HTTP / 2 unterstützt. Wenn ich nun versuche, mit Chrome auf meine lokalen Websites zuzugreifen, erhalte ich eine ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY Error. Ich sollte beachten, dass dieselbe Anfrage, die von Edge gesendet wird, nicht zu einem Fehler führt und HTTP / 2 für die Verbindung verwendet. Eine oberflächliche Google-Suche ergab nichts, was vielversprechend war, außer dass das Problem darin bestand, dass HTTP / 2 oder Chrome streng darauf abgestellt waren, welche Verschlüsselungen in SSL-Zertifikaten akzeptiert werden.

Ich denke, es könnte ein Problem mit aktivierten Cipher Suites in Windows sein (aber ich bin kein Experte in solchen Dingen), ich habe die neueste Version von Windows heruntergeladen IIS-Kryptografie. Ich habe auf die Schaltfläche Best Practices geklickt, auf Übernehmen geklickt und meinen Computer neu gestartet.

IIS Crypto meldet diese Einstellungen als "bewährte Methoden":

  • Aktivierte Protokolle: TLS 1.0, TLS 1.1, TLS 1.2
  • Aktivierte Chiffren: Triple DES 168, AES 128/128, AES 256/256
  • Aktivierte Hashes: MD5, SHA, SHA 256, SHA 384, SHA 512
  • Aktivierter Schlüsselaustausch: Diffie-Hellman, PKCS, ECDH
  • SSL-Verschlüsselungsreihenfolge:

    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P284
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P284
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P284
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
    TLS_RSA_WITH_AES_256_GCM_SHA384
    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA

Ich füge auch hinzu, dass die Browser-Anwendung, die ich entwickle tut nicht müssen von Windows XP aus nutzbar sein. Ich weiß, dass es Probleme gibt, dass Windows XP neuere Protokolle nicht unterstützt.

Detaillierte Informationen zur HTTPS-Verhandlung

Ich entschied mich, Fiddler zu verwenden, um die HTTPS-Verhandlung abzufangen. Hier ist, was Fiddler über die Anfrage berichtet hat:

Version: 3.3 (TLS/1.2)
Random: 6B 47 6D 2B BC AE 00 F1 1D 41 57 7C 46 DB 35 19 D7 EF A9 2B B1 D0 81 1D 35 0D 75 7E 4C 05 14 B0
"Time": 2/1/1993 9:53:15 AM
SessionID: 98 2F 00 00 15 E7 C5 70 12 70 CD A8 D5 C7 D4 4D ED D8 1F 42 F9 A8 2C E6 67 13 AD C0 47 C1 EA 04
Extensions: 
    server_name myapp.local
    extended_master_secret  empty
    SessionTicket   empty
    signature_algs  sha512_rsa, sha512_ecdsa, sha384_rsa, sha384_ecdsa, sha256_rsa, sha256_ecdsa, sha224_rsa, sha224_ecdsa, sha1_rsa, sha1_ecdsa
    status_request  OCSP - Implicit Responder
    NextProtocolNego    empty
    SignedCertTimestamp (RFC6962)   empty
    ALPN        http/1.1, spdy/3.1, h2-14, h2
    channel_id(GoogleDraft) empty
    ec_point_formats    uncompressed [0x0]
    elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
Ciphers: 
    [C02B]  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    [C02F]  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    [009E]  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    [CC14]  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    [CC13]  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    [CC15]  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    [C00A]  TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    [C014]  TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
    [0039]  TLS_DHE_RSA_WITH_AES_256_SHA
    [C009]  TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    [C013]  TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
    [0033]  TLS_DHE_RSA_WITH_AES_128_SHA
    [009C]  TLS_RSA_WITH_AES_128_GCM_SHA256
    [0035]  TLS_RSA_AES_256_SHA
    [002F]  TLS_RSA_AES_128_SHA
    [000A]  SSL_RSA_WITH_3DES_EDE_SHA
    [00FF]  TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Compression: 
    [00]    NO_COMPRESSION

und die Antwort:

Version: 3.3 (TLS/1.2)
SessionID:  98 2F 00 00 15 E7 C5 70 12 70 CD A8 D5 C7 D4 4D ED D8 1F 42 F9 A8 2C E6 67 13 AD C0 47 C1 EA 04
Random:     55 C6 8D BF 78 72 88 41 34 BD B4 B8 DA ED D3 C6 20 5C 46 D6 5A 81 BD 6B FC 36 23 0B 15 21 5C F6
Cipher:     TLS_RSA_WITH_AES_128_GCM_SHA256 [0x009C]
CompressionSuite:   NO_COMPRESSION [0x00]
Extensions:
        ALPN        h2
        0x0017      empty
        renegotiation_info  00
        server_name empty

Was funktioniert?

Basierend auf der Antwort von Håkan Lindqvist und der sehr detaillierten und scheinbar gründlich recherchierten Antwort HierIch habe IIS Crypto mit den folgenden Einstellungen neu konfiguriert, wodurch der Chrome-Fehler behoben wurde:

  • Aktivierte Protokolle: TLS 1.0, TLS 2.0, TLS 3.0
  • Aktivierte Chiffren: AES 128/128, AES 256/256
  • Aktivierte Hashes: SHA, SHA 256, SHA 384, SHA 512
  • Aktivierter Schlüsselaustausch: Diffie-Hellman, PKCS, ECDH
  • SSL-Verschlüsselungsreihenfolge:

    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
    TLS_RSA_WITH_AES_256_GCM_SHA384
    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA256
    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA


19
2017-08-08 22:47


Ursprung


Bevor jemand auf das Offensichtliche hinweist: Ja, ich bin mir dessen bewusst makecert.exe ist veraltet. Ich benutze es nur für Entwicklungsszenarien wie dieses, weil es die einfachste Option ist, die [verwendet?] Funktioniert. - NathanAldenSr
Vielleicht nicht die Chiffre, sondern die ssl / tls-Version, die aktiviert ist. Hast du tls v1.0 oder niedriger aktiviert? - Drifter104
Ich habe die Frage aktualisiert, um zu beschreiben, was ich mit IIS Crypto getan habe, um diese Einstellungen zu kontrollieren. Weißt du, ob die Einstellungen für HTTP / 2 und Chrome zu freizügig sind? - NathanAldenSr
stackoverflow.com/questions/31746620/... kann helfen. Offenbar deaktiviert Spdy im Browser ist der Weg zu gehen - Drifter104
IIS Crypto "Best Practices" in Version 2.0 behebt diesen Fehler für mich. Ich habe versucht, die von Ihnen angegebene Reihenfolge zu verwenden, hatte aber keine Wirkung. Anscheinend wurde es irgendwo in Windows oder IIS Crypto behoben. :) - ahwm


Antworten:


Http / 2 Anforderungen gemäß https://http2.github.io/http2-spec/#rfc.section.9.2.2 :

9.2.2 TLS 1.2 Cipher Suites

Eine Bereitstellung von HTTP / 2 über TLS 1.2 SOLLTE KEINE der Cipher Suites verwenden, die in der Cipher Suite Black List aufgeführt sind (Anhang A).

Endpoints können einen Verbindungsfehler (Abschnitt 5.4.1) vom Typ INADEQUATE_SECURITY generieren, wenn eine der Cipher Suites aus der Blacklist ausgehandelt wird. Eine Bereitstellung, die sich für die Verwendung einer Blacklist-Cipher-Suite entscheidet, kann einen Verbindungsfehler auslösen, wenn nicht bekannt ist, dass die Gruppe potenzieller Peers diese Cipher-Suite akzeptiert.

Implementierungen MÜSSEN diesen Fehler NICHT als Reaktion auf die Aushandlung einer Cipher-Suite generieren, die nicht auf der schwarzen Liste steht. Wenn Clients eine Cipher-Suite anbieten, die nicht auf der schwarzen Liste steht, müssen sie daher darauf vorbereitet sein, diese Cipher-Suite mit HTTP / 2 zu verwenden.

Die schwarze Liste enthält die Verschlüsselungssuite, die TLS 1.2 zwingend vorschreibt, was bedeutet, dass TLS 1.2-Bereitstellungen sich nicht überschneidende Sätze zulässiger Verschlüsselungssammlungen aufweisen können. Um zu vermeiden, dass TLS-Handshake-Fehler zu diesem Problem führen, MÜSSEN TLS-Implementierungen von HTTP / 2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] mit der elliptischen P-256-Kurve [FIPS186] unterstützen.

Beachten Sie, dass Clients möglicherweise die Unterstützung von Verschlüsselungssuites ankündigen, die sich auf der schwarzen Liste befinden, um die Verbindung mit Servern zu ermöglichen, die HTTP / 2 nicht unterstützen. Dadurch können Server HTTP / 1.1 mit einer Verschlüsselungssuite auswählen, die sich in der schwarzen HTTP / 2-Liste befindet. Dies kann jedoch dazu führen, dass HTTP / 2 mit einer Blacklist-Cipher-Suite ausgehandelt wird, wenn das Anwendungsprotokoll und die Cipher-Suite unabhängig voneinander ausgewählt werden.


Ihre ausgehandelte Chiffre TLS_RSA_WITH_AES_128_GCM_SHA256 ist in der oben erwähnten (und verlinkten) Http / 2 Blacklist.

Ich glaube, dass Sie Ihre Chiffre-Suiten (Bestellung?) Anpassen möchten, um die oben genannten Anforderungen zu erfüllen. Vielleicht einfach Putten TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 mit dem NIST P-256 elliptische Kurve (identifiziert als TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256 unter Windows) am Anfang der Liste oder zumindest vor allem, was in der Blacklist enthalten ist?


18
2017-08-09 03:29



Ich werde das sofort versuchen und Sie wissen lassen, wie es sich entwickelt. Danke für die ausführliche Antwort! :) Ehrlich gesagt scheint es so, als ob dieses Cipher-Suite-Problem die Verwendung von HTTP / 2 zur selben Zeit wie HTTP / 1.1 wirklich schwierig, wenn nicht sogar unmöglich machen könnte, bis Browser die Inkonsistenzen umgehen. IPv4 / IPv6, irgendjemand? - NathanAldenSr
Ich habe die Cipher-Suite-Liste von "Best Practices" von IIS Crypto mit der Blacklist verglichen. Was ich gefunden habe, ist das Beste TLS_RSA Cipher Suites sind in der Blacklist. Ich habe sie alle deaktiviert und neu gestartet. Allerdings kann ich jetzt keine sichere Verbindung zu meiner lokalen Website herstellen irgendein Browser. Ich verstehe nur ERR_CONNECTION_RESET. Könnte das etwas mit den Zertifikaten selbst zu tun haben? - NathanAldenSr
@NathanAldenSr Ich glaube nicht, dass du das musst Löschen die Blacklist-Chiffren (sie können für Kompatibilitätszwecke für HTTP / 1.x-Clients nützlich sein), solange nicht-Blacklist-Chiffren höhere Priorität haben. Insbesondere erwähnt die, dass alle HTTP / 2-Bereitstellungen MUSS Unterstützung (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256). - Håkan Lindqvist
Danke für den Startpunkt. Ich habe meine Antwort aktualisiert, um zu zeigen, was für mich funktioniert hat. - NathanAldenSr
Beachten Sie, dass die HTTP / 2-Spezifikation besagt, dass es sich um TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 handelt mit die elliptische P-256-Kurve [FIPS186], also die Zeichenkette: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256 für Windows. - Bart Verkoeijen


Hier ist eine PowerShell, die ich erstellt habe, um HTTP / 2 in IIS vorübergehend zu deaktivieren:

Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\HTTP\Parameters -Name EnableHttp2Tls -Value 0 -Type DWord
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\HTTP\Parameters -Name EnableHttp2Cleartext -Value 0 -Type DWord

Ich mache dies zu einer Antwort, da die Deaktivierung von HTTP / 2 anscheinend die einzige "Lösung" für das Problem darstellt. Ich werde es jedoch nicht akzeptieren, da ich HTTP / 2 in IIS 10 wirklich zuverlässig mit allen Browsern verwenden möchte.


2
2017-08-08 23:50



Wenn Sie Ihre Cipher Suites (möglicherweise nur die Reihenfolge) anpassen, um die Http / 2-Spezifikationen zu erfüllen, sollten Sie das Problem richtig lösen. (Siehe separate Antwort) - Håkan Lindqvist
Es scheint, du musst Windows neu starten Damit diese Änderungen wirksam werden. Einfach anrufen iisreset hat den Trick für mich nicht gemacht. - Sebastian Krysmanski


Holen Sie sich einfach ein Zertifikat von einer richtigen CA, es gibt kostenlose (StartSSL) und es dauert nicht mehr lange, um einen zu bekommen.

Bei Verwendung eines geeigneten Zertifikats hatte ich kein Problem mit IIS 10 unter Windows 10 und HTTP / 2 mit Chrome.


0
2017-08-09 02:54



Das wird leider nicht funktionieren. Ich habe automatisierte Skripts, die diese Zertifikate sowohl für lokale als auch für Entwicklungsumgebungen generieren, und jede Workstation eines Entwicklers benötigt sie. Außerdem möchte ich die Flexibilität haben, Hostnamen ändern zu können, ohne zu einem Drittanbieter zurückkehren zu müssen, um neue Zertifikate zu erhalten. - NathanAldenSr
@NathanAldenSr - Ich verstehe. Für einen vollständigen Skriptprozess verwenden wir eine lokale interne Zertifizierungsstelle. Es wäre schön zu wissen, ob die makecert.exe selbst erstellte Zertifikate sind das Problem. Ich habe nie makecert.exe verwendet, ich dachte immer, dass eine lokale CA eine viel sauberere Lösung ist. - Peter Hahndorf