Chrome melaporkan ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY terhubung ke server web lokal melalui HTTPS

20

Ringkasan

Chrome melaporkan ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYketika saya mencoba dan terhubung ke server web lokal saya melalui HTTPS. Saya hampir yakin masalah ini berkaitan dengan pemutakhiran Windows 10 baru-baru ini, tetapi saya tidak tahu bagaimana cara memperbaikinya.

Apa yang berhasil

Inilah rangkaian acara, dengan saya memasang Windows 8.1 Pro di awal:

  1. Menghasilkan sertifikat yang ditandatangani sendiri yang dimaksudkan untuk digunakan sebagai root CA tepercaya menggunakan perintah berikut: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
  2. Menghasilkan sertifikat khusus aplikasi dari root terpercaya 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. Menambahkan HOSTSentri file untuk myapp.localmenunjuk ke127.0.0.1
  4. Membuat aplikasi IIS 8.5 yang terikat pada myapp.localdomain dan mendengarkan permintaan HTTPS saja
  5. Menugaskan myapp.localsertifikat ke situs web

Dengan penyiapan ini, saya tidak mengalami kesulitan mengakses situs web lokal saya dari Chrome tanpa sertifikat atau peringatan keamanan. Browser menampilkan gembok hijau, seperti yang diharapkan.

Apa yang tidak berhasil?

Baru-baru ini, saya memutakhirkan ke Windows 10. Saya tidak tahu pada saat itu bahwa Windows 10 dikirimkan dengan IIS 10, yang mendukung HTTP / 2. Sekarang, ketika saya mencoba dan mengakses situs web lokal saya dengan Chrome, saya menerima ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYkesalahan. Saya harus mencatat bahwa permintaan yang sama yang dikirim dari Edge tidak menghasilkan kesalahan dan tidak menggunakan HTTP / 2 untuk koneksi. Pencarian Google sepintas tidak menghasilkan apa pun yang menjanjikan, kecuali untuk mengisyaratkan bahwa masalahnya mungkin HTTP / 2 atau Chrome ketat tentang cipher apa yang akan diterima dalam sertifikat SSL.

Berpikir itu mungkin masalah dengan cipher suites yang diaktifkan di Windows (tetapi tidak menjadi ahli dalam hal-hal seperti itu), saya mengunduh versi terbaru IIS Crypto . Saya mengklik tombol Praktik Terbaik, mengklik Terapkan, dan menyalakan kembali mesin saya.

IIS Crypto melaporkan pengaturan ini sebagai "praktik terbaik":

  • Protokol yang diaktifkan: TLS 1.0, TLS 1.1, TLS 1.2
  • Cipher diaktifkan: Triple DES 168, AES 128/128, AES 256/256
  • Hash yang diaktifkan: MD5, SHA, SHA 256, SHA 384, SHA 512
  • Pertukaran kunci yang diaktifkan: Diffie-Hellman, PKCS, ECDH
  • Pesanan rangkaian sandi 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

Saya juga akan menambahkan bahwa aplikasi browser yang saya kembangkan tidak harus dapat digunakan dari Windows XP. Saya tahu ada beberapa masalah tentang Windows XP yang tidak mendukung protokol yang lebih baru.

Informasi terperinci tentang negosiasi HTTPS

Saya memutuskan untuk menggunakan Fiddler untuk mencegat negosiasi HTTPS. Inilah yang Fiddler laporkan tentang permintaan:

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

dan jawabannya:

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

Apa yang bekerja

Berdasarkan jawaban Håkan Lindqvist, dan jawaban yang sangat terperinci dan tampaknya diteliti secara menyeluruh di sini , saya mengkonfigurasi ulang IIS Crypto dengan pengaturan berikut, yang menghilangkan kesalahan Chrome:

  • Protokol yang diaktifkan: TLS 1.0, TLS 2.0, TLS 3.0
  • Cipher diaktifkan: AES 128/128, AES 256/256
  • Hash yang diaktifkan: SHA, SHA 256, SHA 384, SHA 512
  • Pertukaran kunci yang diaktifkan: Diffie-Hellman, PKCS, ECDH
  • Pesanan rangkaian sandi 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_WIT___CL__S_BL__SCL__S_
    _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ...

NathanAldenSr
sumber
Sebelum ada yang menunjukkan yang jelas: Ya, saya sadar makecert.exesudah usang. Saya hanya menggunakannya untuk skenario pengembangan seperti ini karena ini adalah opsi termudah yang [dulu?] Berfungsi.
NathanAldenSr
Prehaps bukan cipher tetapi versi ssl / tls yang diaktifkan. Sudahkah Anda mengaktifkan tls v1.0 atau lebih rendah?
Drifter104
Saya memperbarui pertanyaan untuk memasukkan apa yang saya lakukan dengan IIS Crypto untuk mengontrol pengaturan tersebut. Apakah Anda tahu jika pengaturannya terlalu permisif untuk HTTP / 2 dan Chrome?
NathanAldenSr
stackoverflow.com/questions/31746620/… dapat membantu. Rupanya menonaktifkan sobat di browser adalah cara untuk pergi
Drifter104
1
IIS Crypto "Praktik Terbaik" di versi 2.0 memperbaiki kesalahan ini untuk saya. Saya mencoba menggunakan pesanan suite yang Anda tentukan tetapi tidak berpengaruh. Tampaknya sudah diperbaiki di Windows atau IIS Crypto di suatu tempat di sepanjang jalan. :)
ahwm

Jawaban:

21

Persyaratan Http / 2 sesuai https://http2.github.io/http2-spec/#rfc.section.9.2.2 :

9.2.2 TLS 1.2 Cipher Suites

Penyebaran HTTP / 2 di atas TLS 1.2 TIDAK HARUS menggunakan cipher suites yang tercantum dalam daftar hitam cipher suite ( Lampiran A ).

Endpoints MUNGKIN memilih untuk menghasilkan kesalahan koneksi (Bagian 5.4.1) dari tipe INADEQUATE_SECURITY jika salah satu suite sandi dari daftar hitam dinegosiasikan. Penempatan yang memilih untuk menggunakan cipher suite yang terdaftar hitam berisiko memicu kesalahan koneksi kecuali jika set rekan potensial diketahui menerima cipher suite tersebut.

Implementasi TIDAK HARUS menghasilkan kesalahan ini sebagai reaksi terhadap negosiasi cipher suite yang tidak ada dalam daftar hitam. Akibatnya, ketika klien menawarkan paket sandi yang tidak ada dalam daftar hitam, mereka harus siap untuk menggunakan paket sandi tersebut dengan HTTP / 2.

Daftar hitam termasuk suite sandi yang membuat TLS 1.2 wajib, yang berarti bahwa penyebaran TLS 1.2 dapat memiliki set suite sandi sandi yang tidak berpotongan. Untuk menghindari masalah ini yang menyebabkan kegagalan jabat tangan TLS, penggunaan HTTP / 2 yang menggunakan TLS 1.2 HARUS mendukung TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] dengan kurva elips P-256 [FIPS186].

Perhatikan bahwa klien dapat mengiklankan dukungan suite sandi yang ada dalam daftar hitam untuk memungkinkan koneksi ke server yang tidak mendukung HTTP / 2. Ini memungkinkan server untuk memilih HTTP / 1.1 dengan cipher suite yang ada di daftar hitam HTTP / 2. Namun, ini dapat mengakibatkan HTTP / 2 dinegosiasikan dengan cipher suite yang terdaftar hitam jika protokol aplikasi dan cipher suite dipilih secara independen.


Cipher Anda yang dinegosiasikan TLS_RSA_WITH_AES_128_GCM_SHA256ada dalam daftar hitam Http / 2 yang disebutkan di atas (dan ditautkan).

Saya yakin Anda akan ingin menyesuaikan suite sandi Anda (pemesanan?) Untuk memenuhi persyaratan di atas. Mungkin hanya menempatkan TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256dengan P-256kurva eliptik NIST (diidentifikasi sebagai TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256pada Windows) di bagian atas daftar, atau setidaknya sebelum apa pun yang termasuk dalam daftar hitam?

Håkan Lindqvist
sumber
Saya akan mencoba ini segera dan memberi tahu Anda bagaimana hasilnya. Terima kasih atas jawaban terinci! :) Jujur, sepertinya masalah cipher suite ini dapat membuat menggunakan HTTP / 2 pada saat yang sama dengan HTTP / 1.1 benar-benar rumit, jika bukan tidak mungkin, sampai browser dijamin dapat mengatasi ketidakkonsistenan. IPv4 / IPv6, ada yang?
NathanAldenSr
Saya membandingkan daftar cipher suite "best practices" IIS Crypto dengan daftar hitam. Apa yang saya temukan adalah bahwa semua TLS_RSAsuite sandi praktik terbaik ada di daftar hitam. Saya menonaktifkan semuanya dan reboot. Namun, sekarang saya tidak dapat membuat koneksi yang aman ke situs web lokal saya dengan browser apa pun . Saya baru saja mendapatkannya ERR_CONNECTION_RESET. Mungkinkah ini ada hubungannya dengan sertifikat itu sendiri?
NathanAldenSr
@NathanAldenSr Saya tidak berpikir Anda perlu menghapus cipher blacklisted (mereka mungkin berguna untuk tujuan kompatibilitas untuk klien HTTP / 1.x) selama cipher non-blacklist memiliki prioritas lebih tinggi. Khususnya yang disebutkan bahwa semua penyebaran HTTP / 2 HARUS mendukung ( TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
Håkan Lindqvist
1
Terima kasih atas titik awalnya. Saya telah memperbarui jawaban saya untuk menunjukkan apa yang berhasil untuk saya.
NathanAldenSr
1
Catatan, spesifikasi HTTP / 2 mengatakan TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 dengan kurva eliptik P-256 [FIPS186], artinya string: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256untuk Windows.
Bart Verkoeijen
2

Berikut ini beberapa PowerShell yang saya buat untuk menonaktifkan HTTP / 2 sementara di 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

Saya membuat jawaban ini karena menonaktifkan HTTP / 2 tampaknya menjadi satu-satunya "solusi" untuk masalah ini. Saya tidak akan menerimanya, karena saya benar-benar ingin menggunakan HTTP / 2 di IIS 10 andal dengan semua browser.

NathanAldenSr
sumber
Menyesuaikan suite sandi Anda (mungkin hanya pemesanan) untuk memenuhi spesifikasi Http / 2 harus menyelesaikan masalah dengan benar. (Lihat jawaban terpisah)
Håkan Lindqvist
3
Sepertinya Anda harus me - restart Windows agar perubahan ini berlaku. Hanya menelepon iisresetsaja tidak berhasil.
Sebastian Krysmanski
-1

Hanya dapatkan sertifikat dari CA yang tepat, ada yang gratis ( StartSSL ) dan tidak butuh waktu lebih lama untuk mendapatkannya.

Saat menggunakan sertifikat yang tepat, saya tidak punya masalah dengan menggunakan IIS 10 pada Windows 10 dan HTTP / 2 dengan Chrome.

Peter Hahndorf
sumber
1
Sayangnya, ini tidak berfungsi untuk saya. Saya memiliki skrip otomatis yang menghasilkan sertifikat ini untuk lingkungan lokal dan pengembangan, dan setiap workstation pengembang membutuhkannya. Selain itu, saya ingin fleksibilitas untuk dapat mengubah nama host tanpa harus kembali ke pihak ketiga untuk mendapatkan sertifikat baru.
NathanAldenSr
@NathanAldenSr - Saya mengerti. Untuk proses yang ditulis lengkap kami menggunakan CA internal lokal. Akan menyenangkan untuk mengetahui apakah makecert.exesertifikat yang dibuat sendiri adalah masalahnya. Saya tidak pernah menggunakan makecert.exe, saya selalu berpikir CA lokal adalah solusi yang jauh lebih bersih.
Peter Hahndorf