Chrome zgłasza ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY połączenie z lokalnym serwerem internetowym przez HTTPS

streszczenie

Chrome zgłasza, ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYgdy próbuję połączyć się z moim lokalnym serwerem internetowym przez HTTPS. Jestem prawie pewien, że ten problem dotyczy mojej ostatniej aktualizacji systemu Windows 10, ale nie wiem, jak go naprawić.

Co zadziałało

Oto ciąg wydarzeń, w których na początku mam zainstalowany system Windows 8.1 Pro:

1. Wygenerowano samopodpisany certyfikat przeznaczony do użytku jako zaufany główny urząd certyfikacji za pomocą następującego polecenia: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
2. Wygenerowano certyfikat aplikacji z zaufanego głównego urzędu certyfikacji: 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. Dodano HOSTSwpis pliku dla myapp.localtych punktów127.0.0.1
4. Utworzono aplikację IIS 8.5, która jest powiązana z myapp.localdomeną i nasłuchuje tylko żądań HTTPS
5. Przypisał myapp.localcertyfikat do strony internetowej

Dzięki tej konfiguracji nie miałem problemów z dostępem do mojej lokalnej witryny internetowej z Chrome bez żadnego certyfikatu ani ostrzeżeń bezpieczeństwa. Przeglądarka wyświetliła zieloną kłódkę, zgodnie z oczekiwaniami.

Co nie działa

Ostatnio zaktualizowałem system do Windows 10. Nie wiedziałem wtedy, że Windows 10 jest dostarczany z IIS 10, który obsługuje HTTP / 2. Teraz, gdy próbuję uzyskać dostęp do moich lokalnych stron internetowych za pomocą Chrome, pojawia się ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYbłąd. Należy zauważyć, że to samo żądanie wysłane z Edge nie powoduje błędu i używa połączenia HTTP / 2. Pobieżna wyszukiwarka Google nie znalazła niczego obiecującego, poza wskazówką, że problem może polegać na tym, że HTTP / 2 lub Chrome ściśle określają, jakie szyfry będą akceptować w certyfikatach SSL.

Myśląc, że może to być problem z włączonymi pakietami szyfrów w systemie Windows (ale nie jestem ekspertem w takich sprawach), pobrałem najnowszą wersję Crypto IIS . Kliknąłem przycisk najlepszych praktyk, kliknąłem Zastosuj i ponownie uruchomiłem komputer.

IIS Crypto zgłasza te ustawienia jako „najlepsze praktyki”:

• Włączone protokoły: TLS 1.0, TLS 1.1, TLS 1.2
• Włączone szyfry: Triple DES 168, AES 128/128, AES 256/256
• Włączone skróty: MD5, SHA, SHA 256, SHA 384, SHA 512
• Włączone wymiany kluczy: Diffie-Hellman, PKCS, ECDH

• Kolejność zestawów szyfrów SSL:

  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

Dodam też, że tworzona przeze mnie przeglądarka nie musi działać w systemie Windows XP. Wiem, że są pewne problemy z tym, że Windows XP nie obsługuje nowszych protokołów.

Szczegółowe informacje na temat negocjacji HTTPS

Zdecydowałem się użyć Fiddlera do przechwycenia negocjacji HTTPS. Oto, co Fiddler zgłosił na temat żądania:

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

i odpowiedź:

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

Co działa

Na podstawie odpowiedzi Håkana Lindqvista oraz bardzo szczegółowej i najwyraźniej dokładnie zbadanej odpowiedzi tutaj ponownie skonfigurowałem Crypto IIS z następującymi ustawieniami, co wyeliminowało błąd Chrome:

• Włączone protokoły: TLS 1.0, TLS 2.0, TLS 3.0
• Włączone szyfry: AES 128/128, AES 256/256
• Włączone skróty: SHA, SHA 256, SHA 384, SHA 512
• Włączone wymiany kluczy: Diffie-Hellman, PKCS, ECDH

• Kolejność zestawów szyfrów SSL:

  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

Wymagania HTTP / 2 zgodnie z https://http2.github.io/http2-spec/#rfc.section.9.2.2 :

9.2.2 Zestawy szyfrów TLS 1.2

Wdrożenie HTTP / 2 na TLS 1.2 NIE POWINIEN używać żadnego z zestawów szyfrów wymienionych na czarnej liście zestawu szyfrów ( Załącznik A ).

Punkty końcowe MOGĄ wybrać generowanie błędu połączenia (sekcja 5.4.1) typu INADEQUATE_SECURITY, jeśli wynegocjowano jeden z zestawów szyfrów z czarnej listy. Wdrożenie, które zdecyduje się użyć pakietu szyfrów umieszczonego na czarnej liście, może spowodować błąd połączenia, chyba że znany jest zestaw potencjalnych rówieśników, który akceptuje ten zestaw szyfrów.

Implementacje NIE MOGĄ generować tego błędu w reakcji na negocjacje pakietu szyfrów, który nie znajduje się na czarnej liście. W związku z tym, gdy klienci oferują pakiet szyfrów, którego nie ma na czarnej liście, muszą być przygotowani do korzystania z tego zestawu szyfrów z HTTP / 2.

Czarna lista obejmuje zestaw szyfrów, który TLS 1.2 czyni obowiązkowym, co oznacza, że ​​wdrożenia TLS 1.2 mogą mieć nieprzecinające się zestawy dozwolonych pakietów szyfrów. Aby uniknąć tego problemu powodującego błędy uzgadniania TLS, wdrożenia HTTP / 2 korzystające z TLS 1.2 MUSZĄ obsługiwać TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] z krzywą eliptyczną P-256 [FIPS186].

Należy pamiętać, że klienci mogą reklamować obsługę pakietów szyfrów znajdujących się na czarnej liście, aby umożliwić połączenie z serwerami, które nie obsługują HTTP / 2. Pozwala to serwerom wybrać HTTP / 1.1 z pakietem szyfrów, który znajduje się na czarnej liście HTTP / 2. Może to jednak prowadzić do negocjacji protokołu HTTP / 2 z zestawem szyfrów z czarnej listy, jeśli protokół aplikacji i zestaw szyfrów zostaną niezależnie wybrane.

Twój wynegocjowany szyfr TLS_RSA_WITH_AES_128_GCM_SHA256znajduje się na wyżej wymienionej (i powiązanej) czarnej liście Http / 2.

Wierzę, że będziesz chciał dostosować swoje zestawy szyfrów (zamawianie?), Aby spełnić powyższe wymagania. Może po prostu umieszczenie krzywej eliptycznej TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256NIST P-256(oznaczonej jako TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256Windows) na górze listy, a przynajmniej przed czymkolwiek znajdującym się na czarnej liście?

Oto niektóre PowerShell, które utworzyłem, aby tymczasowo wyłączyć HTTP / 2 w IIS:

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

Udzielam odpowiedzi, ponieważ wyłączenie HTTP / 2 wydaje się być jedynym „rozwiązaniem” problemu. Nie zaakceptuję tego, ponieważ naprawdę chciałbym niezawodnie używać HTTP / 2 w IIS 10 we wszystkich przeglądarkach.

Po prostu uzyskaj certyfikat od właściwego urzędu certyfikacji, są bezpłatne ( StartSSL ) i uzyskanie go nie trwa dłużej.

Korzystając z odpowiedniego certyfikatu, nie miałem problemu z używaniem IIS 10 na Windows 10 i HTTP / 2 z Chrome.