Как настроить 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 2 048 битов (e 65537)
Выпускающий защищенный сервер DigiCert SHA2 CA
Алгоритм сигнатуры SHA512withRSA
Это Транспортные Требования к защите Приложения:
Сервер должен поддерживать, по крайней мере, версию протокола 1.2 Безопасности транспортного уровня (TLS). Шифры соединения ограничены теми, которые обеспечивают прямую секретность (см. список шифров ниже.) Сертификаты должны быть подписаны с помощью SHA256 или лучшего хеш-алгоритма подписи, или с 2 048 битами или с большим ключом 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_EC DHE_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
Что попробовали:
- При добавлении исключений в мобильном приложении для разрешения наших доменных работ но я не хочу идти с этим незащищенным методом, я хочу зафиксировать наш SSL.
- Используемый IIS Crypto для использования 'лучшей практики', попробованного 'PCI' и пользовательских установок. Даже испытанное изменение crypto комплекта только к списку выше, и переупорядочение. После каждой попытки сервер перезагружается, и и Labs SSL был, работал (за очищающимся кэшем). Я был успешен при движении от F, оценивающего к A и даже A-, но это только привело к iOS 8 и 9 неспособности установить безопасные соединения. (Код NSURLErrorDomain =-1200 и _kCFStreamErrorCodeKey =-9806)
- Восстановленный VM и попробованный powershell сценарий Установка Ваш IIS для Совершенной прямой секретности SSL и TLS 1.2, я даже предпринял вторую попытку, где я вырезал шифры от сценария питания до минимального списка того, что требуется.
Результаты: Всегда подобный, оценки A или A-. iOS8 и iOS9 не могут согласовать безопасное соединение. Результаты симуляции квитирования в "Комплекте протоколов или наборе шифров не сочетаются" для продуктов iOS и Safari. 
ОБНОВЛЕНИЕ После работы с поддержкой 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 - SYN-ACK - трехэтапное квитирование ACK, которое настраивает соединение TCP. Четвертый пакет является iOS, отправляющей Ваш сервер Клиентское Приветственное сообщение TLS, первый шаг в установке соединения TLS по тому соединению TCP. Я разделил это сообщение, и это выглядит достаточно разумным. В пятом пакете сервер просто отбрасывает соединение (путем отправки RST).
Кто-либо знает, почему IIS 7.5 сделал бы RST?
Если ваш IIS Crypto-образ последний, сохраните настройки как есть, но включите SHA, Diffie-Hellman и PKCS. Это даст вам оценку A, но позволит подключить iOS 8 и ниже.
.Вопрос старый, но он будет найден при поиске. Я потратил некоторое время, чтобы найти решение той же проблемы. Поэтому я решил написать ответ, чтобы поделиться своими результатами с другими.
Краткий ответ: вы не должны использовать IIS Crypto для указания порядка наборов шифров. Я рекомендую вам нажать кнопку «По умолчанию», чтобы удалить ранее установленный порядок, а затем использовать групповую политику («Конфигурация компьютера» \ «Административные шаблоны» \ «Сеть» \ «Параметры конфигурации SSL») для настройки наборов шифров с помощью локальной политики.
Причина ошибки «Несоответствие протокола или набора шифров» может быть следующей :
- ваш сервер поддерживает какой-то «плохой набор шифров»
- ваш сервер не поддерживает какой-то набор шифров, который ДОЛЖЕН поддерживаться в соответствии со спецификацией TLS.
- ваш сервер поддерживает HTTP / 2 и у него есть некоторые протоколы из черного списка выше других протоколов, которых нет в списке . Как правило, для решения проблемы достаточно изменить порядок комплектов шифров.
Точный черный список может отличаться в разных системах. Вы можете найти в Интернете какой-то черный список. Например, Приложение A к RFC 7540 (протокол передачи гипертекста версии 2 (HTTP / 2)) содержит один список. Наборы шифров: TLS_RSA_WITH_AES_128_CBC_SHA для TLS 1.2 (см. здесь ) и TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [115421215] [TLS_GCM_SHA256ES_AES_128_GCM_SHA256ES_AES_128_GCM_SHA256 [115421715] и [TLCM_SHA256] [115421715] здесь [TLCM_SHA256] [115421715] и [TLCM_SHA256ES_1151615] здесь [115421715] 1154219]). TLS_ECDHE_ECDSA _ * важны, только если вы используете сертификат с эллиптическими кривыми. Другой очень хороший набор шифров TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 еще не реализован Microsoft. Кроме того, вы можете добавить как минимум TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA для поддержки подключения из старых систем и TLS_RSA_WITH_AES_128_CBC_SHA для поддержки очень старых систем (Android 2.3.7, и Java 6u45y). 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 Labs с ключом 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 использует.
Самым важным шагом, на который я потратил много времени и который является вашей основной проблемой, была настройка наборов шифров. Я сделал это с помощью 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.
В любом случае, после настройки вышеуказанных параметров в Group Polity и перезагружая компьютер ( gpupdate / force / target: computer было недостаточно в моих тестах) я получаю оценки A + и следующий список результатов тестирования «Симуляции рукопожатия» "часть:
Видно, что iOS успешно поддерживается для следующих клиентов:
Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9
Клиенты, не поддерживающие TLS 1.2, теперь кажутся мне не столь важными, и я думаю, что приведенная выше конфигурация является хорошим компромиссом между поддержка устаревших клиентов и использование безопасных протоколов.
Я боролся с этим несколько дней. В частности, я подключался из приложения для 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
Последний был найден с помощью Чарльза Прокси, который вел переговоры TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 автоматически. Дело в том, что соединения с Чарльзом Прокси были успешными (с установленными сертификатами симулятора), но не успешными в противном случае. Добавление набора, который он использовал в переговорах, сделало трюк. Похоже(?), что прокси пересогласовывал со службой отдыха что-то, что поддерживалось моим сервером, но не клиентом iOS.
Обратите внимание, что многие наборы шифров были получены из спецификации ssllabs о предпочтительных наборах для различных iOS/OSX устройств. Значение выше должно быть квитировано со всем, кроме IE 6 на XP согласно ssllabs, со значением A.
.