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. Створено специфічний для програми сертифікат із довіреного кореня CA: 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
• Увімкнено обмін ключами: Diffie-Hellman, 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. Ось що повідомив 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:

• Увімкнено протоколи: TLS 1.0, TLS 2.0, TLS 3.0
• Увімкнено шифри: AES 128/128, AES 256/256
• Увімкнено хеші: SHA, SHA 256, SHA 384, SHA 512
• Увімкнено обмін ключами: Diffie-Hellman, 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

Розгортання 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.