Chrome meldet, dass ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY über HTTPS eine Verbindung zum lokalen Webserver hergestellt hat

19

Zusammenfassung

Chrome meldet, ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYwenn ich versuche, über HTTPS eine Verbindung zu meinem lokalen Webserver herzustellen. Ich bin mir fast sicher, dass dieses Problem mit meinem letzten Windows 10-Upgrade zusammenhängt, aber ich weiß nicht, wie ich es beheben soll.

Was hat funktioniert?

Hier ist die Ereigniskette, bei der ich Windows 8.1 Pro zu Beginn installiert habe:

  1. Mit dem folgenden Befehl wurde ein selbstsigniertes Zertifikat generiert, das 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. Generierte ein anwendungsspezifisches Zertifikat von der vertrauenswürdigen Stammzertifizierungsstelle: 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. Ein HOSTSDateieintrag für myapp.localdiese Punkte wurde hinzugefügt127.0.0.1
  4. Erstellt eine IIS 8.5-Anwendung, die an die myapp.localDomäne gebunden ist und nur auf HTTPS-Anforderungen wartet
  5. Das myapp.localZertifikat der Website zugewiesen

Mit diesem Setup konnte ich ohne Zertifikat- oder Sicherheitswarnungen problemlos von Chrome aus auf meine lokale Website zugreifen. Der Browser zeigte erwartungsgemäß das grüne Vorhängeschloss an.

Was geht nicht

Vor kurzem habe ich ein Upgrade auf Windows 10 durchgeführt. Ich wusste damals noch nicht, dass Windows 10 mit IIS 10 ausgeliefert wird, das HTTP / 2 unterstützt. Wenn ich jetzt versuche, mit Chrome auf meine lokalen Websites zuzugreifen, wird eine ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYFehlermeldung angezeigt. Ich sollte beachten, dass dieselbe von Edge gesendete Anforderung nicht zu einem Fehler führt und HTTP / 2 für die Verbindung verwendet. Eine flüchtige Google-Suche ergab keine vielversprechenden Ergebnisse, außer als Hinweis darauf, dass das Problem möglicherweise darin besteht, dass HTTP / 2 oder Chrome genau festlegen, welche Verschlüsselungen in SSL-Zertifikaten akzeptiert werden.

Da ich denke, dass es ein Problem mit aktivierten Cipher Suites in Windows sein könnte (aber kein Experte für solche Dinge ist), habe ich die neueste Version von IIS Crypto heruntergeladen . Ich habe auf die Schaltfläche Best Practices geklickt, auf Übernehmen geklickt und meinen Computer neu gestartet.

IIS Crypto meldet diese Einstellungen als "Best Practices":

  • 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
  • Bestellung der SSL-Verschlüsselungssuite:

    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 hinzu, dass die von mir entwickelte Browser-Anwendung nicht unter Windows XP verwendet werden muss. Ich weiß, dass es einige Probleme mit Windows XP gibt, die neuere Protokolle nicht unterstützen.

Detaillierte Informationen zur HTTPS-Aushandlung

Ich habe mich für Fiddler entschieden, um die HTTPS-Aushandlung abzufangen. Folgendes berichtete Fiddler über die Anfrage:

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 läuft?

Basierend auf der Antwort von Håkan Lindqvist und der sehr detaillierten und anscheinend gründlich recherchierten Antwort hier habe ich 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
  • Bestellung der SSL-Verschlüsselungssuite:

    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

NathanAldenSr
quelle
Bevor jemand auf das Offensichtliche hinweist: Ja, mir ist bewusst, dass makecert.exees veraltet ist. Ich benutze es nur für solche Entwicklungsszenarien, weil es die einfachste Option ist, die [früher?] Funktioniert.
NathanAldenSr
Prehaps nicht die Chiffre, sondern die aktivierte ssl / tls-Version. Haben Sie tls v1.0 oder niedriger aktiviert?
Drifter104
Ich habe die Frage dahingehend aktualisiert, was ich mit IIS Crypto getan habe, um diese Einstellungen zu steuern. Wissen Sie, ob die Einstellungen für HTTP / 2 und Chrome zu tolerant sind?
NathanAldenSr
stackoverflow.com/questions/31746620/… kann helfen. Anscheinend ist das Deaktivieren von Spdy im Browser der
richtige
1
IIS Crypto "Best Practices" in Version 2.0 hat diesen Fehler für mich behoben. Ich habe versucht, die von Ihnen angegebene Suite-Reihenfolge zu verwenden, hatte jedoch keine Auswirkung. Anscheinend wurde es irgendwo auf dem Weg entweder in Windows oder IIS Crypto behoben. :)
ahwm

Antworten:

20

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

9.2.2 TLS 1.2-Verschlüsselungssammlungen

Bei einer Bereitstellung von HTTP / 2 über TLS 1.2 DÜRFEN KEINE der in der schwarzen Liste der Chiffresuiten ( Anhang A ) aufgeführten Chiffresuiten verwendet werden .

Endpunkte KÖNNEN einen Verbindungsfehler (Abschnitt 5.4.1) vom Typ INADEQUATE_SECURITY generieren, wenn eine der Chiffresuiten aus der schwarzen Liste ausgehandelt wird. Eine Bereitstellung, die sich für die Verwendung einer Cipher Suite auf der schwarzen Liste entscheidet, kann einen Verbindungsfehler auslösen, sofern nicht bekannt ist, dass die Gruppe potenzieller Peers diese Cipher Suite akzeptiert.

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

Die schwarze Liste enthält die von TLS 1.2 vorgeschriebene Chiffresuite. Dies bedeutet, dass TLS 1.2-Bereitstellungen möglicherweise nicht überlappende Mengen zulässiger Chiffresuiten enthalten. Um dieses Problem zu vermeiden, das TLS-Handshake-Fehler verursacht, MÜSSEN Bereitstellungen von HTTP / 2, die TLS 1.2 verwenden, 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 Cipher Suites ankündigen, die auf der schwarzen Liste stehen, um die Verbindung zu Servern zu ermöglichen, die HTTP / 2 nicht unterstützen. Auf diese Weise können Server HTTP / 1.1 mit einer Verschlüsselungssuite auswählen, die sich auf der HTTP / 2-Blacklist befindet. Dies kann jedoch dazu führen, dass HTTP / 2 mit einer Cipher Suite auf der schwarzen Liste ausgehandelt wird, wenn das Anwendungsprotokoll und die Cipher Suite unabhängig voneinander ausgewählt werden.


Ihre ausgehandelte Chiffre TLS_RSA_WITH_AES_128_GCM_SHA256befindet sich in der oben genannten (und verknüpften) HTTP / 2-Blacklist.

Ich glaube, Sie werden Ihre Cipher Suites (Bestellung?) Anpassen wollen, um die oben genannten Anforderungen zu erfüllen. Vielleicht einfach TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256mit der P-256elliptischen NIST- Kurve (wie TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256unter Windows angegeben) ganz oben auf der Liste oder zumindest vor allem, was auf der schwarzen Liste steht?

Håkan Lindqvist
quelle
Ich werde es sofort versuchen und Sie wissen lassen, wie es ausgeht. Danke für die ausführliche Antwort! :) Ehrlich gesagt, scheint es so, als würde dieses Problem mit der Cipher Suite die Verwendung von HTTP / 2 zur gleichen Zeit wie HTTP / 1.1 wirklich schwierig, wenn nicht unmöglich machen, bis Browser garantiert die Inkonsistenzen umgehen. IPv4 / IPv6, jemand?
NathanAldenSr
Ich habe die Liste der "Best Practices" der Cipher Suite von IIS Crypto mit der Blacklist verglichen. Was ich herausgefunden habe, ist, dass alle Best-Practice- TLS_RSACipher-Suites auf der schwarzen Liste stehen. Ich habe sie alle deaktiviert und neu gestartet. Jetzt kann ich jedoch mit keinem Browser eine sichere Verbindung zu meiner lokalen Website herstellen . Ich verstehe gerade ERR_CONNECTION_RESET. Könnte dies etwas mit den Zertifikaten selbst zu tun haben?
NathanAldenSr
@ NathanAldenSr Ich glaube nicht, dass Sie die Chiffren auf der schwarzen Liste entfernen müssen (sie können aus Kompatibilitätsgründen für HTTP / 1.x-Clients hilfreich sein), solange nicht auf der schwarzen Liste stehende Chiffren eine höhere Priorität haben. Insbesondere die erwähnte, dass alle HTTP / 2-Bereitstellungen MÜSSEN ( TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) unterstützen.
Håkan Lindqvist
1
Vielen Dank für den Ausgangspunkt. Ich habe meine Antwort aktualisiert, um zu zeigen, was für mich funktioniert hat.
NathanAldenSr
1
In der HTTP / 2-Spezifikation heißt es TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 mit der elliptischen P-256-Kurve [FIPS186], was die Zeichenfolge bedeutet: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256für Windows.
Bart Verkoeijen
2

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 das Deaktivieren von HTTP / 2 die einzige "Lösung" für das Problem zu sein scheint. Ich werde es jedoch nicht akzeptieren, da ich HTTP / 2 in IIS 10 wirklich zuverlässig mit allen Browsern verwenden möchte.

NathanAldenSr
quelle
Die Anpassung Ihrer Cipher Suites (möglicherweise nur die Reihenfolge) an die HTTP / 2-Spezifikationen sollte das Problem ordnungsgemäß lösen. (Siehe separate Antwort)
Håkan Lindqvist
3
Anscheinend müssen Sie Windows neu starten, damit diese Änderungen wirksam werden. Nur anzurufen hat iisresetmir nicht geholfen.
Sebastian Krysmanski
-1

Holen Sie sich einfach ein Zertifikat von einer geeigneten Zertifizierungsstelle. Es gibt kostenlose Zertifikate ( StartSSL ), und es dauert nicht lange, bis Sie eines erhalten.

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

Peter Hahndorf
quelle
1
Das klappt bei mir leider nicht. Ich habe automatisierte Skripte, die diese Zertifikate sowohl für lokale Umgebungen als auch für Entwicklungsumgebungen generieren, und jede Entwickler-Workstation benötigt sie. Außerdem möchte ich die Flexibilität, 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ändig skriptbasierten Prozess verwenden wir eine lokale interne Zertifizierungsstelle. Es wäre schön zu wissen, ob die makecert.exeselbst erstellten Zertifikate das Problem sind. Ich habe nie makecert.exe verwendet. Ich dachte immer, eine lokale Zertifizierungsstelle ist eine viel sauberere Lösung.
Peter Hahndorf