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


20

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


Zanim ktokolwiek zwróci uwagę na oczywiste: Tak, wiem, że makecert.exejest przestarzałe. Używam go tylko w takich scenariuszach programistycznych, ponieważ jest to najłatwiejsza opcja, która [przywykła?] Działa.
NathanAldenSr

Być może nie szyfr, ale włączona wersja ssl / tls. Czy masz włączony tls v1.0 lub niższy?
Drifter104

Zaktualizowałem pytanie, aby uwzględnić to, co zrobiłem z IIS Crypto, aby kontrolować te ustawienia. Czy wiesz, czy ustawienia są zbyt liberalne dla HTTP / 2 i Chrome?
NathanAldenSr

stackoverflow.com/questions/31746620/… może pomóc. Najwyraźniej wyłączanie spdy w przeglądarce jest
dobrym rozwiązaniem

1
IIS Crypto „Najlepsze praktyki” w wersji 2.0 naprawił dla mnie ten błąd. Próbowałem użyć określonej kolejności pakietu, ale nie przyniosło to efektu. Najwyraźniej zostało to naprawione w Windows lub IIS Crypto gdzieś po drodze. :)
ahwm

Odpowiedzi:


21

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?


Spróbuję tego natychmiast i dam znać, jak to się potoczy. Dzięki za szczegółową odpowiedź! :) Szczerze mówiąc, wydaje się, że ten problem z pakietem szyfrów może sprawić, że używanie HTTP / 2 w tym samym czasie co HTTP / 1.1 będzie naprawdę trudne, jeśli nie niemożliwe, dopóki przeglądarki nie będą mogły obejść tych niespójności. IPv4 / IPv6, ktoś?
NathanAldenSr,

Porównałem listę pakietów najlepszych praktyk IIS Crypto z czarną listą. Odkryłem, że wszystkie najlepsze TLS_RSAzestawy szyfrów znajdują się na czarnej liście. Wyłączyłem je wszystkie i uruchomiłem ponownie. Jednak teraz nie mogę nawiązać bezpiecznego połączenia z moją lokalną witryną za pomocą dowolnej przeglądarki. Właśnie rozumiem ERR_CONNECTION_RESET. Czy to może mieć coś wspólnego z samymi certyfikatami?
NathanAldenSr

@NathanAldenSr Nie sądzę, że musisz usuwać szyfry z czarnej listy (mogą być przydatne do celów kompatybilności dla klientów HTTP / 1.x), o ile szyfry z czarnej listy nie mają wyższego priorytetu. W szczególności wspomniano, że wszystkie wdrożenia HTTP / 2 MUSZĄ obsługiwać ( TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
Håkan Lindqvist,

1
Dziękuję za punkt wyjścia. Zaktualizowałem swoją odpowiedź, aby pokazać, co zadziałało.
NathanAldenSr

1
Uwaga: specyfikacja HTTP / 2 mówi, że jest to TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 z krzywą eliptyczną P-256 [FIPS186], co oznacza ciąg: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256dla systemu Windows.
Bart Verkoeijen,

2

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.


Dostosowanie zestawu szyfrów (być może tylko zamówienia) w celu spełnienia specyfikacji HTTP / 2 powinno rozwiązać problem poprawnie. (Patrz osobna odpowiedź)
Håkan Lindqvist

3
Wygląda na to, że musisz ponownie uruchomić system Windows, aby zmiany zostały wprowadzone. Samo dzwonienie iisresetnie pomogło mi.
Sebastian Krysmanski

-1

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.


1
Niestety to nie zadziała. Mam zautomatyzowane skrypty, które generują te certyfikaty zarówno dla środowisk lokalnych, jak i programistycznych, a każda stacja robocza programisty potrzebuje ich. Ponadto chcę, aby elastyczność mogła zmieniać nazwy hostów bez konieczności powrotu do strony trzeciej w celu uzyskania nowych certyfikatów.
NathanAldenSr,

@NathanAldenSr - Rozumiem. W przypadku procesu w pełni skryptowanego korzystamy z lokalnego wewnętrznego urzędu certyfikacji. Byłoby miło wiedzieć, czy makecert.exeproblemem są tworzone przez siebie certyfikaty. Nigdy nie korzystałem z makecert.exe, zawsze uważałem, że lokalny urząd certyfikacji jest znacznie czystszym rozwiązaniem.
Peter Hahndorf,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.