Cara mengkonfigurasi IIS 7.5 SSL \ TLS agar berfungsi dengan iOS 9 ATS

Masalah: Aplikasi seluler kami tidak lagi dapat membuat koneksi yang aman ke layanan web kami karena iOS 9 sekarang menggunakan ATS.

Latar Belakang: iOS 9 memperkenalkan Keamanan Transportasi Aplikasi

Pengaturan Server: Windows Server 2008 R2 SP1 (VM) IIS 7.5, sertifikat SSL dari digicert. Firewall Windows mati.

Kunci RSA 2048 bit (e 65537)

Penerbit DigiCert SHA2 Secure Server CA

Algoritma tanda tangan SHA512denganRSA

Ini adalah persyaratan Keamanan Transportasi Aplikasi:

Server harus mendukung setidaknya protokol Transport Layer Security (TLS) versi 1.2. Cipher koneksi terbatas pada yang memberikan kerahasiaan ke depan (lihat daftar cipher di bawah ini.) Sertifikat harus ditandatangani menggunakan SHA256 atau algoritma hash tanda tangan yang lebih baik, dengan kunci RSA 2048 bit atau lebih besar atau 256 bit atau lebih besar Elliptic-Curve (ECC). Sertifikat yang tidak valid mengakibatkan kegagalan yang berat dan tidak ada koneksi. Ini adalah sandi yang diterima:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Apa yang sudah dicoba:

1. Menambahkan pengecualian di aplikasi seluler agar domain kami berfungsi, tetapi saya tidak ingin menggunakan metode yang tidak aman ini, saya ingin memperbaiki SSL kami.
2. Digunakan IIS Crypto untuk menggunakan 'praktik terbaik', mencoba 'pci', dan pengaturan khusus. Bahkan mencoba memodifikasi suite crypto ke daftar di atas, dan memesan ulang. Setelah setiap upaya, server di-boot ulang, dan dan Lab SSL dijalankan (setelah membersihkan cache). Saya berhasil beralih dari peringkat F ke A, dan bahkan A-, tetapi ini hanya mengakibatkan iOS 8 dan 9 tidak dapat membuat koneksi yang aman. (NSURLErrorDomain Code = -1200 dan _kCFStreamErrorCodeKey = -9806)
3. Memulihkan VM dan mencoba skrip PowerShell. Mengatur IIS Anda untuk SSL Perfect Forward Secrecy dan TLS 1.2. Saya bahkan melakukan upaya kedua di mana saya mengedit cipher dari skrip daya ke daftar minimal apa yang diperlukan.

Hasil: Selalu serupa, peringkat A atau A-. iOS8 dan iOS9 tidak dapat menegosiasikan koneksi aman. Simulasi Jabat Tangan menghasilkan "Protokol atau ketidaksesuaian paket sandi" untuk produk Safari dan iOS.

PEMBARUAN Setelah bekerja dengan dukungan Apple, kami melakukan beberapa penangkapan jejak paket:

$ tcpdump -n -r trace.pcap
reading from file trace.pcap, link-type EN10MB (Ethernet)
client > server [S], seq 1750839998, win 65535, length 0
server > client [S.], seq 2461151276, ack 1750839999, win 8192, length 0
client > server [.], ack 1, win 4104, length 0
client > server [P.], seq 1:175, ack 1, win 4104, length 174
server > client [R.], seq 1, ack 175, win 0, length 0

Tiga paket pertama adalah SYH - SYN-ACK klasik - ACK handshake tiga arah yang mengatur koneksi TCP. Paket keempat adalah iOS mengirimkan server Anda pesan Halo Klien TLS, langkah pertama dalam menyiapkan koneksi TLS melalui koneksi TCP. Saya telah memisahkan pesan ini dan itu terlihat cukup masuk akal. Dalam paket kelima server cukup menjatuhkan koneksi (dengan mengirim RST).

Adakah yang tahu mengapa IIS 7.5 akan melakukan RST?

Pertanyaannya sudah lama, tetapi akan ditemukan selama pencarian. Saya menghabiskan waktu untuk mencari solusi untuk masalah yang sama. Jadi saya memutuskan untuk menulis jawaban untuk membagikan hasil saya dengan orang lain.

Jawaban singkat: Anda tidak boleh menggunakan IIS Crypto untuk menentukan urutan Cipher Suites. Saya sarankan Anda untuk mengklik tombol "Defaults" untuk menghapus pesanan yang telah ditetapkan sebelumnya dan kemudian menggunakan Kebijakan Grup ("Konfigurasi Komputer" \ "Template Administratif" \ "Jaringan" \ "Pengaturan Konfigurasi SSL") untuk mengonfigurasi Cipher Suites melalui kebijakan lokal.

Alasan kesalahan "protokol atau ketidaksesuaian paket sandi" bisa salah satu dari berikut :

• server Anda mendukung beberapa "suite sandi buruk"
• server Anda tidak mendukung beberapa paket sandi, yang HARUS didukung sesuai dengan spesifikasi TLS.
• server Anda mendukung HTTP / 2 dan memiliki beberapa protokol dari daftar hitam di atas protokol lain, yang tidak ada dalam daftar . Biasanya cukup mengubah urutan suite sandi untuk memperbaiki masalah.

Daftar hitam yang tepat dapat berbeda pada sistem yang berbeda. Anda dapat menemukan beberapa daftar hitam di Internet. Misalnya, Apendiks A dari RFC 7540 (Hypertext Transfer Protocol Version 2 (HTTP / 2)) berisi satu daftar. Suite sandi adalah TLS_RSA_WITH_AES_128_CBC_SHAuntuk TLS 1.2 (lihat di sini ) dan TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256dan TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256untuk TLS 1.3 (lihat di sini ). Yang TLS_ECDHE_ECDSA_*penting hanya Anda menggunakan sertifikat dengan kurva elips. Suite sandi yang sangat bagus lainnya TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256belum diterapkan oleh Microsoft. Selain itu Anda dapat mempertimbangkan untuk menambahkan setidaknya TLS_ECDHE_RSA_WITH_AES_256_CBC_SHAuntuk mendukung koneksi dari sistem lama dan TLS_RSA_WITH_AES_128_CBC_SHAuntuk mendukung sistem yang sangat lama (Android 2.3.7,, Java 6u45, OpenSSL 0.9.8y) dan TLS_RSA_WITH_3DES_EDE_CBC_SHAhanya jika Anda memerlukan dukungan IE 8 / XP. Dengan demikian Anda dapat menggunakan hari ini, misalnya

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

dengan TLS 1.0 yang dinonaktifkan, TLS 1.1 memiliki keamanan yang lebih baik atau adil

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

jika Anda perlu memiliki keamanan yang baik dan kinerja terbaik.

Anda dapat mengatur serangkaian cipher suite berikut sebagai contoh untuk menyelesaikan masalah Anda:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Di bawah ini saya menyertakan contoh konfigurasi pada Windows 10. Saya mengkonfigurasi IIS 10 untuk memiliki peringkat A + dari Qualys SSL Labs dengan kunci RSA 2048 dan sertifikat SSL gratis dari Let's Encrypt .

Saya menonaktifkan DES 56/56, RC2 128/128, RC2 40/128, RC2 56/128, RC4 128/128, RC4 40/128, RC4 56/128, RC4 64/128, Triple DES 168/168, NULL, MD5, Multi-Protokol Halo Terpadu, PCT 1.0, SSL 2.0, SSL 3.0 dan TLS 1.0 / 1.1 secara manual dalam registri (lihat KB245030 ). Saya menonaktifkan protokol TLS 1.0 dan TLS 1.1 hanya karena TLS_FALLBACK_SCSV (Downgrade attack) tidak dapat dicegah di IIS sampai sekarang, yang membuat tidak mungkin untuk mendapatkan peringkat A + dari www.ssllabs.com . Saya melihatnya sebagai kerugian, tetapi TLS 1.2 saat ini didukung sangat luas. Omong-omong, Anda bisa menggunakan DisabledByDefault: 1, tetapi Enabled: 1untuk TLS 1.0 dan TLS 1.1. Ini bisa membantu jika Anda menjalankan SQL Server 2008/2012 di komputer. Server web tidak akan menggunakan TLS 1.0 dan TLS 1.1, tetapi SQL Server menggunakannya.

Langkah paling penting, yang mendapatkan banyak waktu saya dan yang merupakan masalah utama Anda adalah konfigurasi Suites Cipher. Saya membuatnya menggunakan gpedit.msc. Saya memilih "Konfigurasi Komputer" \ "Template Administratif" \ "Jaringan" \ "Pengaturan Konfigurasi SSL" dan mengonfigurasi nilai "Urutan Cipher Suite SSL" sebagai berikut

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Urutan di atas mungkin tidak optimal dan saya tidak yakin, bahwa semua protokol di atas didukung pada IIS 7.5 (Saya menggunakan IIS 10.0 dari Windows 10). Namun demikian saya yakin bahwa masalah Anda terkait dengan daftar Suite Cipher, karena saya memiliki masalah yang sama persis seperti yang Anda jelaskan selama percobaan saya dengan daftar Suite Cipher.

Dengan cara apa pun, setelah mengonfigurasi pengaturan di atas dalam Group Polity dan me-reboot komputer ( gpupdate /force /target:computertidak cukup dalam pengujian saya), saya mendapatkan peringkat A + dan daftar hasil pengujian berikut dari bagian "Simulasi Jabat Tangan":

Orang dapat melihat bahwa iOS berhasil didukung untuk klien berikut:

Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9

Klien yang tidak mendukung TLS 1.2 tampaknya bagi saya sekarang tidak begitu penting dan saya pikir konfigurasi di atas adalah kompromi yang baik antara dukungan klien lama dan penggunaan protokol aman.

Jika gambar IIS Crypto Anda baru-baru ini simpan pengaturan sebagaimana adanya tetapi aktifkan SHA, Diffie-Hellman, dan PKCS. Ini akan memberi Anda peringkat A tetapi mengizinkan iOS 8 dan lebih rendah untuk terhubung.

Saya berjuang dengan ini selama beberapa hari. Secara khusus saya terhubung dari aplikasi iOS menggunakan Xamarin Forms PCL untuk terhubung ke layanan istirahat ASP.NET Web Api 2 dengan otentikasi OAuth2 Bearer Token.

Apa yang berhasil bagi saya pada akhirnya adalah menggunakan praktik terbaik IIS Crypto. Kemudian edit kunci registri yang ditetapkan untuk urutan cipher suite:

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Function

Saya sukses dengan nilai berikut:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 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_P384, 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_P384, 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_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_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, 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_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_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_128_CBC_SHA_P521, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_DES_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Yang terakhir ditemukan dengan menggunakan Proxy Charles, yang merundingkan TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 secara otomatis. Hal yang mengarahkan saya pada hal ini adalah bahwa koneksi berhasil dengan Charles Proxy aktif (dengan sertifikat simulator terpasang), tetapi gagal sebaliknya. Menambahkan suite yang digunakan dalam negosiasi berhasil. Tampaknya (?) Bahwa proxy sedang melakukan negosiasi ulang dengan layanan istirahat saya dengan sesuatu yang didukung oleh server saya, tetapi bukan klien iOS.

Catatan banyak cipher suite diperoleh dari spesifikasi ssllab tentang suite pilihan untuk berbagai perangkat iOS / OSX. Nilai di atas harus jabat tangan dengan segala sesuatu kecuali IE 6 pada XP menurut ssllab, dengan nilai A.