Як налаштувати IIS 7.5 SSL \ TLS для роботи з iOS 9 ATS

Проблема: Наш мобільний додаток більше не може встановити захищене з'єднання з нашою веб-службою, оскільки iOS 9 зараз використовує ATS.

Передумови: iOS 9 представляє безпеку транспорту додатків

Налаштування сервера: Windows Server 2008 R2 SP1 (VM) IIS 7.5, сертифікати SSL від digicert. Брандмауер Windows вимкнено.

Ключові біти RSA 2048 (e 65537)

Емітент DigiCert SHA2 Secure Server CA

Алгоритм підпису SHA512зRSA

Ось такі вимоги щодо безпеки транспорту додатків:

Сервер повинен підтримувати принаймні протокол протоколу безпеки транспортного рівня (TLS) версії 1.2. Шифри підключення обмежуються тими, які забезпечують таємницю прямого перегляду (див. Перелік шифрів нижче.) Сертифікати повинні бути підписані за допомогою SHA256 або кращого алгоритму хешування підпису, або 2048 бітовим або більшим ключем RSA, або 256-бітовою або більшою еліптичною кривою (ECC). Недійсні сертифікати призводять до жорсткої несправності та відсутності з'єднання. Це прийняті шифри:

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

Що було випробувано:

1. Додавання винятків у програмі для мобільних пристроїв, щоб наш домен працював, але я не хочу використовувати цей незахищений метод, я хочу виправити наш SSL.
2. Використовував IIS Crypto, щоб використовувати "кращу практику", спробував "pci" та власні налаштування. Навіть спробував змінити набір криптовалют лише до переліку, наведеного вище, і переупорядкувати. Після кожної спроби сервер перезавантажується, і запускалися лабораторії SSL (після очищення кеша). Я мав успіх у переході від рейтингу F до рівня A і навіть A-, але це призвело лише до того, що iOS 8 і 9 не змогли встановити безпечні з'єднання. (NSURLErrorDomain Code = -1200 та _kCFStreamErrorCodeKey = -9806)
3. Відновлено VM та спробував скрипт повноважень. Налаштуйте свій IIS для SSL Perfect Forward Secrecy та TLS 1.2. Я навіть зробив другу спробу, коли я відредагував циферблатів із скрипту живлення до мінімального списку необхідного.

Результати: Завжди схожі, рейтинги A або A-. iOS8 та iOS9 не можуть узгодити безпечне з'єднання. Моделювання рукостискання призводить до "невідповідності протоколу чи шифру" для продуктів Safari та iOS.

ОНОВЛЕННЯ Після роботи з підтримкою Apple, ми зробили декілька заходів трасування пакетів:

$ 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

Перші три пакети - це класичне тристороннє рукостискання SYN-ACK - ACK, яке встановлює TCP-з'єднання. Четвертий пакет - iOS, що надсилає вашому серверу повідомлення клієнта TLS Привіт, перший крок у налаштуванні TLS-з'єднання через це TCP-з'єднання. Я розірвав це повідомлення, і воно виглядає досить розумно. У п'ятому пакеті сервер просто припиняє з'єднання (надсилаючи RST).

Хтось знає, чому IIS 7.5 буде робити RST?

Питання давнє, але воно буде знайдено під час пошуку. Я витратив деякий час, щоб знайти рішення тієї ж проблеми. Тому я вирішую написати відповідь, щоб поділитися своїми результатами з іншими.

Коротка відповідь: не слід використовувати криптовалюту IIS для визначення порядку Cipher Suites. Рекомендую натиснути на кнопки "За замовчуванням", щоб видалити раніше встановлений порядок, а потім скористатися груповою політикою ("Конфігурація комп'ютера" \ "Адміністративні шаблони" \ "Мережа" \ "Налаштування конфігурації SSL") для налаштування Cipher Suites за допомогою локальної політики.

Причиною помилки "невідповідність протоколу чи шифру" може бути одна знизу :

• ваш сервер підтримує деякий "поганий набір шифрів"
• ваш сервер не підтримує деякий набір шифрів, який ОБОВ'ЯЗКОВО повинен підтримуватися відповідає специфікації TLS.
• ваш сервер підтримує HTTP / 2, і він має деякі протоколи із чорного списку над іншими протоколами, яких немає у списку . Зазвичай достатньо змінити порядок набору шифрів, щоб вирішити проблему.

Точний чорний список може бути різним у різних системах. Ви можете знайти в Інтернеті якийсь чорний список. Наприклад, Додаток А до RFC 7540 (протокол передачі гіпертексту, версія 2 (HTTP / 2)) містить один список. Набір шифрів призначений TLS_RSA_WITH_AES_128_CBC_SHAдля TLS 1.2 (див. Тут ) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256та TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256для TLS 1.3 (див. Тут ). TLS_ECDHE_ECDSA_*Важливо тільки використовувати сертифікат з еліптичними кривими. Інший дуже хороший набір шифрів TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256Microsoft ще не реалізує. Крім того, ви можете розглянути можливість додавати принаймні TLS_ECDHE_RSA_WITH_AES_256_CBC_SHAдо підтримки з'єднання зі старими системами та TLS_RSA_WITH_AES_128_CBC_SHAпідтримувати дуже старі системи (Android 2.3.7,, Java 6u45, OpenSSL 0.9.8y), і TLS_RSA_WITH_3DES_EDE_CBC_SHAлише якщо вам потрібна підтримка IE 8 / XP. Таким чином, ви можете використовувати сьогодні, наприклад

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

з відключеним TLS 1.0, TLS 1.1 для покращення безпеки або просто

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

якщо вам потрібна хороша безпека та найкраща ефективність.

Ви можете встановити наступний короткий набір шифрового набору, наприклад, щоб вирішити вашу проблему:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Нижче я прикладаю приклад конфігурації в Windows 10. Я сконфігурував IIS 10, щоб він мав оцінку A + від лабораторій Qualys SSL з ключем RSA 2048 та безкоштовний сертифікат SSL від Let’s Encrypt .

Я відключив 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-Protocol Unified Hello, PCT 1.0, SSL 2.0, SSL 3.0 та TLS 1.0 / 1.1 вручну в реєстрі (див. KB245030 ). Я відключив протоколи TLS 1.0 та TLS 1.1 лише тому, що TLS_FALLBACK_SCSV (атака пониження) досі не можна запобігти в IIS, що унеможливлює отримання A + рейтингу www.ssllabs.com . Я вважаю це недоліком, але TLS 1.2 зараз підтримується дуже широко. До речі, ви можете використовувати DisabledByDefault: 1, але Enabled: 1для TLS 1.0 і TLS 1.1. Це може бути корисно, якщо ви запустили SQL Server 2008/2012 на комп’ютері. Веб-сервер не використовуватиме TLS 1.0 та TLS 1.1, але використовує SQL Server.

Найважливішим кроком, на який я забираю багато часу, і який є вашою основною проблемою, була конфігурація Cipher Suites. Я зробив це за допомогою gpedit.msc. Я вибрав значення "Конфігурація комп'ютера" \ "Адміністративні шаблони" \ "Мережа" \ "Налаштування конфігурації SSL" та налаштував значення "Порядок пакетних пакетів SSL" на таке

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Вищезазначений порядок може бути не оптимальним, і я не впевнений, що всі вищезазначені протоколи підтримуються на IIS 7.5 (я використовував IIS 10.0 з Windows 10). Тим не менш, я впевнений, що ваша проблема пов'язана зі списком програми Cipher Suite, оскільки у мене була точно така ж проблема, як ви описані під час моїх експериментів зі списком Cipher Suite.

У будь-якому випадку, після налаштування вищезазначених параметрів у груповій політиці та перезавантаження комп'ютера ( gpupdate /force /target:computerу моїх тестах цього було недостатньо) я отримую оцінки А + та наступний список результатів тестування частини "Моделювання рукостискання":

Видно, що iOS успішно підтримується для таких клієнтів:

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

Клієнти, які не підтримують TLS 1.2, мені здаються зараз не такими важливими, і я вважаю, що наведена вище конфігурація є хорошим компромісом між підтримкою застарілих клієнтів та використанням безпечних протоколів.

Якщо криптовалюта IIS нещодавно збережіть налаштування такими, які вони є, але ввімкніть SHA, Diffie-Hellman та PKCS. Це дасть вам оцінку A, але дозволить iOS 8 і нижче підключитися.

Я боровся з цим кілька днів. Зокрема, я підключався через додаток для iOS за допомогою Xamarin Forms PCL для підключення до сервісу відпочинку ASP.NET Web Api 2 з аутентифікацією OAuth2 Bearer Token.

Зрештою, для мене спрацювало використання кращих практик IIS Crypto. Потім відредагуйте ключ реєстру, який він встановив для порядку набору шифрів:

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

Я мав успіх у наступному значенні:

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

Останнє було знайдено за допомогою Charles Proxy, який автоматично узгоджував TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Мене це призвело до того, що з'єднання були успішними з Charles Proxy (із встановленими сертифікатами симулятора), але не вдалося інакше. Додавання пакету, який він використовував у переговорах, зробив свою справу. Здається (про), що проксі переговорився з моєю службою відпочинку з тим, що підтримував мій сервер, але не клієнт iOS.

Зауважимо, що багато шифрових наборів були отримані з специфікації переважних наборів ssllabs для різних пристроїв iOS / OSX. Вищенаведене значення повинно вручатися всім, крім IE 6 на XP відповідно до ssllabs, з рейтингом A.