Назад | Перейти на главную страницу

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 сообщает эти настройки как «лучшие практики»:

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

Подробная информация о согласовании HTTPS

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

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:

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

9.2.2 Наборы шифров TLS 1.2

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

Конечные точки МОГУТ выбрать создание ошибки соединения (раздел 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_SHA256 с NIST 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.