IIS 7.5 SSL \ TLS'yi iOS 9 ATS ile çalışacak şekilde yapılandırma

Sorun: iOS 9 artık ATS kullandığından, mobil uygulamamız artık web servisimizle güvenli bir bağlantı kuramıyor.

Arka plan: iOS 9, Uygulama Aktarım Güvenliği'ni sunar

Sunucu Kurulumu: Windows Server 2008 R2 SP1 (VM) IIS 7.5, digicert'ten SSL sertifikaları. Windows güvenlik duvarı kapalı.

Anahtar RSA 2048 bit (e 65537)

Sertifikayı Veren DigiCert SHA2 Güvenli Sunucu CA

RSA ile imza algoritması SHA512

Bunlar, Uygulama Aktarımı Güvenliği gereksinimleridir:

Sunucunun en azından Aktarım Katmanı Güvenliği (TLS) protokolü 1.2 sürümünü desteklemesi gerekir. Bağlantı şifreleri, ileri gizlilik sağlayanlarla sınırlıdır (aşağıdaki şifreleme listesine bakın.) Sertifikalar, 2048 bit veya daha büyük bir RSA anahtarı veya 256 bit veya daha büyük Eliptik Eğri ile SHA256 veya daha iyi bir imza karma algoritması kullanılarak imzalanmalıdır. (ECC) tuşuna basın. Geçersiz sertifikalar sabit bir arızaya neden olur ve bağlantı olmaz. Bunlar kabul edilen şifrelerdir:

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

Ne denendi:

1. Etki alanımızın çalışmasına izin vermek için mobil uygulamaya istisnalar ekliyor, ancak bu güvenli olmayan yöntemle gitmek istemiyorum, SSL'imizi düzeltmek istiyorum.
2. Kullanılan IIS Kripto 'en iyi uygulama', denenmiş 'pci' ve bazı özel ayarlar kullanmak. Hatta kripto paketini sadece yukarıdaki listeye değiştirmeyi ve yeniden sıralamayı denedi. Her denemeden sonra sunucu yeniden başlatılır ve SSL Labs çalıştırılır (önbellek temizlendikten sonra). F derecelendirmesinden A'ya ve hatta A-'ya geçmeyi başardım, ancak bu sadece iOS 8 ve 9'un güvenli bağlantılar kuramamalarına neden oldu. (NSURLErrorDomain Kodu = -1200 ve _kCFStreamErrorCodeKey = -9806)
3. VM'yi geri yükledi ve bir powershell betiği denedi SSL'nizi SSL için Mükemmel İletme Gizliliği ve TLS 1.2 Kurun Hatta, güç komut dosyasından gerekli olanları en az bir listeye siberleri düzenlediğim ikinci bir girişimde bulundum.

Sonuçlar: Her zaman benzer, A veya A- dereceleri. iOS8 ve iOS9 güvenli bağlantı üzerinde anlaşamaz. El Sıkışma Simülasyonu, Safari ve iOS ürünleri için "Protokol veya şifre takımı uyuşmazlığı" ile sonuçlanır.

GÜNCELLEME Apple desteği ile çalıştıktan sonra bazı paket izleme yakalamaları yaptık:

$ 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

İlk üç paket, TCP bağlantısını kuran klasik SYN - SYN-ACK - ACK üç yollu el sıkışmasıdır. Dördüncü paket iOS'a sunucunuza bir TLS İstemcisi Merhaba mesajı gönderir, bu TCP bağlantısı üzerinden bir TLS bağlantısı kurmanın ilk adımıdır. Bu mesajı ayırdım ve yeterince makul görünüyor. Beşinci pakette sunucu sadece bağlantıyı keser (bir RST göndererek).

IIS 7.5'in neden bir RST yapacağını bilen var mı?

Soru eski, ama arama sırasında bulunacak. Aynı soruna çözüm bulmak için biraz zaman harcadım. Böylece sonuçlarımı başkalarıyla paylaşmak için cevabı yazmaya karar verdim.

Kısa yanıt: Cipher Suites'in sırasını belirlemek için IIS Kripto kullanmamalısınız. Önceden ayarlanmış siparişi kaldırmak için "Varsayılanlar" düğmelerini tıklamanızı ve ardından Cipher Suites'i yerel ilke aracılığıyla yapılandırmak için Grup İlkesi'ni ("Bilgisayar Yapılandırması" \ "Yönetim Şablonları" \ "Ağ" \ "SSL Yapılandırma Ayarları") kullanmanızı öneririm.

"Protokol veya şifre takımı uyumsuzluğu" hatasının nedeni aşağıdakilerden biri olabilir :

• sunucunuz bazı "kötü şifre paketlerini" destekliyor
• sunucunuz, TLS belirtimine karşılık gelen desteklenmesi GEREKEN bazı şifre paketlerini desteklemiyor.
• sunucunuz HTTP / 2'yi destekler ve listede yer almayan diğer protokollerin üzerindeki kara listeden bazı protokollere sahiptir . Sorunu çözmek için tipik olarak şifre paketlerinin sırasını değiştirmek yeterlidir.

Tam kara liste farklı sistemlerde farklı olabilir. İnternette bazı kara listeler bulabilirsiniz. Örneğin, RFC 7540 (Köprü Metni Aktarım Protokolü Sürüm 2 (HTTP / 2)) Ek A bir liste içerir. Şifre suit TLS_RSA_WITH_AES_128_CBC_SHATLS 1.2 (bkz için buraya ) ve TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256ve TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS 1.3 için (bkz burada ). TLS_ECDHE_ECDSA_*Yalnızca eliptik eğrileri ile sertifika kullanmak olduğunu önemlidir. Diğer çok iyi şifre takımı TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256henüz Microsoft tarafından uygulanmadı. Ayrıca, en azından TLS_ECDHE_RSA_WITH_AES_256_CBC_SHAeski sistemlerden bağlantıyı ve TLS_RSA_WITH_AES_128_CBC_SHAçok eski sistemleri (Android 2.3.7,, Java 6u45, OpenSSL 0.9.8y) ve TLS_RSA_WITH_3DES_EDE_CBC_SHAyalnızca IE 8 / XP'yi desteklemeniz gerekiyorsa desteklemeyi eklemeyi düşünebilirsiniz . Böylece bugün kullanabilirsiniz, örneğin

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

daha iyi bir güvenlik için TLS 1.0, TLS 1.1

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

iyi bir güvenlik ve en iyi performansa ihtiyacınız varsa.

Sorununuzu çözmek için aşağıdaki kısa şifre setini ayarlayabilirsiniz:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Aşağıda, Windows 10'da bir yapılandırma örneği ekledim. IIS 10'u , RSA 2048 anahtarlı Qualys SSL Labs'tan A + derecesine ve Let's Encrypt'ten ücretsiz SSL sertifikasına sahip olacak şekilde yapılandırdım .

DES 56/56, RC2 128/128, RC2 40/128, RC2 56/128, RC4 128/128, RC4 40/128, RC4 56/128, RC4 64/128, Üçlü DES 168/168, NULL, MD5, Çok Protokollü Birleştirilmiş Merhaba, PCT 1.0, SSL 2.0, SSL 3.0 ve TLS 1.0 / 1.1 kayıt defterinde manuel olarak (bkz. KB245030 ). TLS 1.0 ve TLS 1.1 protokollerini devre dışı bıraktım çünkü TLS_FALLBACK_SCSV (Sürüm düşürme saldırısı) IIS'de şu ana kadar önlenemiyor, bu da www.ssllabs.com'un A + puanını almayı imkansız hale getiriyor . Bunu bir dezavantaj olarak görüyorum, ancak TLS 1.2 şu anda çok geniş bir şekilde destekleniyor. Bu arada kullanabilirsiniz DisabledByDefault: 1, ancak Enabled: 1TLS 1.0 ve TLS 1.1 için. Bilgisayarda SQL Server 2008/2012 çalıştırırsanız yardımcı olabilir. Web sunucusu TLS 1.0 ve TLS 1.1 kullanmaz, ancak SQL Server kullanır.

Zamanımın çoğunu alan ve asıl probleminiz olan en önemli adım, Cipher Suites'in yapılandırılmasıydı. Bunu kullanarak yaptım gpedit.msc. "Bilgisayar Yapılandırması" \ "Yönetim Şablonları" \ "Ağ" \ "SSL Yapılandırma Ayarları" nı seçtim ve "SSL Şifreleme Paketi Siparişi" değerini aşağıdaki şekilde yapılandırdım

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Yukarıdaki sıra en uygun olmayabilir ve emin değilim, yukarıdaki tüm protokollerin IIS 7.5'te desteklendiğinden eminim (Windows 10'dan IIS 10.0 kullandım). Yine de, sorunun Cipher Suite listesiyle ilişkili olduğundan eminim, çünkü Cipher Suite listesiyle yaptığım deneyler sırasında tarif ettiğiniz gibi tamamen aynı sorunu yaşadım.

Herhangi bir şekilde, Grup Yönetimi'nde yukarıdaki ayarları yapılandırdıktan ve bilgisayarı yeniden başlattıktan sonra ( gpupdate /force /target:computertestlerimde yeterli değildi) A + puanları ve "El Sıkışma Simülasyonu" bölümünün aşağıdaki test sonuçları listesini aldım:

İOS'un aşağıdaki istemciler için başarıyla desteklendiğini görebilirsiniz:

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

TLS 1.2'yi desteklemeyen müşteriler artık benim için çok önemli değil ve yukarıdaki yapılandırmanın eski istemcilerin desteği ile güvenli protokollerin kullanımı arasında iyi bir uzlaşma olduğunu düşünüyorum.

IIS Kripto resminiz yakınsa ayarları olduğu gibi tutun ancak SHA, Diffie-Hellman ve PKCS'yi etkinleştirin. Bu size A derecesini alır, ancak iOS 8 ve daha düşük sürümlerin bağlanmasına izin verir.

Birkaç gün bununla mücadele ettim. Özellikle, OAuth2 Taşıyıcı Jetonu kimlik doğrulaması ile bir ASP.NET Web Api 2 dinlenme hizmetine bağlanmak için Xamarin Forms PCL kullanarak bir iOS uygulamasından bağlanıyordum.

Sonunda benim için işe yarayan şey, IIS Kripto'nun En İyi uygulamalarını kullanmaktı. Ardından şifre paketi sırası için ayarladığı kayıt defteri anahtarını düzenleyin:

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

Aşağıdaki değerle başarılı oldum:

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

Sonuncusu, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ile otomatik olarak müzakere eden Charles Proxy kullanılarak bulundu. Beni buna yönlendiren şey, bağlantıların Charles Proxy ile başarılı olmasıydı (simülatör sertifikaları yüklendiğinde), ancak aksi halde başarısız oldu. Müzakere sırasında kullanılan paketi eklemek hile yaptı. Proxy'nin sunucum tarafından desteklenen bir şeyle dinlenme servisimle yeniden görüştüğü anlaşılıyor, ancak iOS istemcisi değil.

Şifreli paketlerin çoğunun, çeşitli iOS / OSX cihazları için ssllabs'ın tercih edilen paketleri belirtmesinden elde edildiğine dikkat edin. Yukarıdaki değer , ssllabs'a göre XP'de IE 6 hariç her şeyle, A dereceli bir el sıkışma olmalıdır .