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

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

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?

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.

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.