streszczenie
Chrome zgłasza, ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY
gdy 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:
- 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
- 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
- Dodano
HOSTS
wpis pliku dlamyapp.local
tych punktów127.0.0.1
- Utworzono aplikację IIS 8.5, która jest powiązana z
myapp.local
domeną i nasłuchuje tylko żądań HTTPS - Przypisał
myapp.local
certyfikat 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_SECURITY
błą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
źródło
makecert.exe
jest przestarzałe. Używam go tylko w takich scenariuszach programistycznych, ponieważ jest to najłatwiejsza opcja, która [przywykła?] Działa.Odpowiedzi:
Wymagania HTTP / 2 zgodnie z https://http2.github.io/http2-spec/#rfc.section.9.2.2 :
Twój wynegocjowany szyfr
TLS_RSA_WITH_AES_128_GCM_SHA256
znajduje 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_SHA256
NISTP-256
(oznaczonej jakoTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256
Windows) na górze listy, a przynajmniej przed czymkolwiek znajdującym się na czarnej liście?źródło
TLS_RSA
zestawy 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 rozumiemERR_CONNECTION_RESET
. Czy to może mieć coś wspólnego z samymi certyfikatami?TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
).TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256
dla systemu Windows.Oto niektóre PowerShell, które utworzyłem, aby tymczasowo wyłączyć HTTP / 2 w IIS:
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.
źródło
iisreset
nie pomogło mi.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.
źródło
makecert.exe
problemem 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.