Chrome сообщает об ошибке ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY, подключенной к локальному веб-серверу по протоколу HTTPS.

Резюме

Chrome сообщает, ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYкогда я пытаюсь подключиться к локальному веб-серверу по протоколу HTTPS. Я почти уверен, что эта проблема связана с моим недавним обновлением до Windows 10, но я не знаю, как это исправить.

Что сработало

Вот цепочка событий, у меня с самого начала установлена ​​Windows 8.1 Pro:

1. Сгенерировал самозаверяющий сертификат, предназначенный для использования в качестве доверенного корневого ЦС, с помощью следующей команды: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
2. Создан сертификат для конкретного приложения из доверенного корневого центра сертификации: 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. Добавлена HOSTSзапись для файла, myapp.localкоторый указывает на127.0.0.1
4. Создано приложение IIS 8.5, которое привязано к myapp.localдомену и прослушивает только HTTPS-запросы
5. Назначен myapp.localсертификат на веб-сайт

С этой настройкой у меня не было проблем с доступом к моему локальному веб-сайту из Chrome без каких-либо сертификатов или предупреждений безопасности. Браузер отобразил зеленый замок, как и ожидалось.

Что не работает

Недавно я обновился до Windows 10. В то время я не знал, что Windows 10 поставляется с IIS 10, который поддерживает HTTP / 2. Теперь, когда я пытаюсь получить доступ к своим локальным веб-сайтам с помощью Chrome, я получаю сообщение ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYоб ошибке. Я должен отметить, что тот же запрос, отправленный из Edge, не приводит к ошибке и использует HTTP / 2 для соединения. Беглый поиск в Google не дал ничего обещающего, кроме намека на то, что проблема может заключаться в том, что HTTP / 2 или Chrome строго следят за тем, какие шифры он будет принимать в SSL-сертификатах.

Подумав, что это может быть проблемой с включенными комплектами шифров в Windows (но не будучи экспертом в таких вещах), я скачал последнюю версию IIS Crypto . Я нажал кнопку «Рекомендации», нажал «Применить» и перезагрузил компьютер.

IIS Crypto сообщает об этих настройках как «лучшие практики»:

• Включенные протоколы: TLS 1.0, TLS 1.1, TLS 1.2
• Включенные шифры: Тройной DES 168, AES 128/128, AES 256/256
• Включенные хэши: MD5, SHA, SHA 256, SHA 384, SHA 512
• Включены обмены ключами: Диффи-Хеллман, PKCS, ECDH

• Порядок набора 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

Я также добавлю, что разрабатываемое браузерное приложение не нужно использовать в Windows XP. Я знаю, что есть некоторые проблемы, связанные с тем, что Windows XP не поддерживает новые протоколы.

Подробная информация о переговорах по HTTPS

Я решил использовать Fiddler для перехвата HTTPS-переговоров. Вот что Фиддлер сообщил о запросе:

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

и ответ:

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

Что работает

Основываясь на ответе Хокана Линдквиста и очень подробном и, по-видимому, тщательно изученном ответе здесь , я перенастроил IIS Crypto со следующими настройками, которые устранили ошибку Chrome:

• Включенные протоколы: TLS 1.0, TLS 2.0, TLS 3.0
• Включенные шифры: AES 128/128, AES 256/256
• Включенные хэши: SHA, SHA 256, SHA 384, SHA 512
• Включены обмены ключами: Диффи-Хеллман, PKCS, ECDH

• Порядок набора 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

Требования Http / 2 согласно https://http2.github.io/http2-spec/#rfc.section.9.2.2 :

9.2.2 TLS 1.2 Cipher Suite

Развертывание HTTP / 2 поверх TLS 1.2 НЕ ДОЛЖНО использовать наборы шифров, перечисленные в черном списке наборов шифров ( Приложение A ).

Конечные точки МОГУТ выбрать генерацию ошибки соединения (раздел 5.4.1) типа INADEQUATE_SECURITY, если согласован один из наборов шифров из черного списка. Развертывание, которое выбирает использование набора шифров из черного списка, может вызвать ошибку соединения, если известно, что набор потенциальных одноранговых узлов не принимает этот набор шифров.

Реализации НЕ ДОЛЖНЫ генерировать эту ошибку в ответ на согласование набора шифров, которого нет в черном списке. Следовательно, когда клиенты предлагают набор шифров, которого нет в черном списке, они должны быть готовы использовать этот набор шифров с HTTP / 2.

Черный список включает набор шифров, который TLS 1.2 делает обязательным, что означает, что развертывания TLS 1.2 могут иметь непересекающиеся наборы разрешенных наборов шифров. Чтобы избежать этой проблемы, приводящей к сбоям рукопожатия TLS, развертывания HTTP / 2, использующие TLS 1.2, ДОЛЖНЫ поддерживать TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] с эллиптической кривой P-256 [FIPS186].

Обратите внимание, что клиенты могут объявлять о поддержке наборов шифров, которые находятся в черном списке, чтобы разрешить подключение к серверам, которые не поддерживают HTTP / 2. Это позволяет серверам выбирать HTTP / 1.1 с набором шифров, который находится в черном списке HTTP / 2. Однако это может привести к согласованию HTTP / 2 с набором шифров из черного списка, если протокол приложения и набор шифров выбраны независимо.

Ваш согласованный шифр TLS_RSA_WITH_AES_128_GCM_SHA256находится в вышеупомянутом (и связанном) черном списке Http / 2.

Я полагаю, что вы захотите настроить свои комплекты шифров (заказывать?), Чтобы они соответствовали вышеуказанным требованиям. Может быть, просто поместив эллиптическую кривую TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256NIST P-256(обозначенную как TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256в Windows) вверху списка, или, по крайней мере, перед тем, как что-либо включить в черный список?

Вот некоторые PowerShell, которые я создал для временного отключения HTTP / 2 в 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

Я делаю это ответ, так как отключение HTTP / 2, кажется, единственное «решение» проблемы. Я не приму это, так как я действительно хотел бы использовать HTTP / 2 в IIS 10 надежно со всеми браузерами.

Просто получите сертификат от надлежащего центра сертификации, есть бесплатные ( StartSSL ), и его получение не займет много времени.

При использовании надлежащего сертификата у меня не было проблем с использованием IIS 10 в Windows 10 и HTTP / 2 с Chrome.