Как настроить IIS 7.5 SSL \ TLS для работы с iOS 9 ATS

Проблема: наше мобильное приложение больше не может устанавливать безопасное соединение с нашим веб-сервисом, поскольку iOS 9 теперь использует ATS.

Справочная информация: iOS 9 представляет App Transport Security

Настройка сервера: Windows Server 2008 R2 SP1 (VM) IIS 7.5, SSL-сертификаты от digicert. Брандмауэр Windows выключен.

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

Эмитент DigiCert SHA2 Secure Server CA

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

Это требования безопасности транспорта приложения:

Сервер должен поддерживать по крайней мере версию 1.2 протокола TLS. Шифры подключения ограничиваются теми, которые обеспечивают прямую секретность (см. Список шифров ниже.) Сертификаты должны быть подписаны с использованием алгоритма хеширования сигнатуры SHA256 или более высокого, с ключом RSA 2048 бит или более, или эллиптической кривой 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 Labs (после очистки кеша). Мне удалось перейти с F-рейтинга на A и даже A-, но это только привело к тому, что iOS 8 и 9 не смогли установить безопасные соединения. (NSURLErrorDomain Code = -1200 и _kCFStreamErrorCodeKey = -9806)
3. Восстановил виртуальную машину и попробовал сценарий powershell. Настройте IIS для SSL Perfect Forward Secrecy и TLS 1.2. Я даже предпринял вторую попытку, когда отредактировал шифры из сценария power для получения минимального списка того, что требуется.

Результаты: всегда одинаковые, оценки 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 - SYN-ACK - ACK, которое устанавливает соединение TCP. Четвертый пакет - iOS, отправляющая вашему серверу сообщение Hello TLS Client, первый шаг в настройке соединения TLS через это соединение TCP. Я разобрал это сообщение, и оно выглядит достаточно разумным. В пятом пакете сервер просто сбрасывает соединение (отправляя RST).

Кто-нибудь знает, почему IIS 7.5 будет делать RST?

Вопрос старый, но он будет найден при поиске. Я потратил некоторое время, чтобы найти решение той же проблемы. Поэтому я решил написать ответ, чтобы поделиться своими результатами с другими.

Краткий ответ: вам не следует использовать IIS Crypto для указания порядка Cipher Suites. Я рекомендую вам нажать кнопки «По умолчанию», чтобы удалить ранее установленный порядок, а затем использовать групповую политику («Конфигурация компьютера» \ «Административные шаблоны» \ «Сеть» \ «Настройки конфигурации SSL») для настройки Cipher Suites через локальную политику.

Причиной ошибки «несоответствие протокола или набора шифров» может быть одна из следующих причин :

• ваш сервер поддерживает "плохой набор шифров"
• ваш сервер не поддерживает какой-либо набор шифров, который ДОЛЖЕН поддерживаться, соответствует спецификации 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и TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256для TLS 1.3 (см. Здесь ). 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 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 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 его использует.

Самым важным этапом, который занимал у меня много времени и являлся вашей главной проблемой, была настройка Cipher Suites. Я сделал это с помощью gpedit.msc. Я выбрал «Конфигурация компьютера» \ «Административные шаблоны» \ «Сеть» \ «Настройки конфигурации SSL» и настроил значение «Порядок SSL Cipher Suite» для следующего

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, для меня сейчас не так важны, и я считаю, что приведенная выше конфигурация является хорошим компромиссом между поддержкой устаревших клиентов и использованием безопасных протоколов.

Если ваш IIS Crypto образ является последним, сохраните настройки, как они есть, но включите SHA, Diffie-Hellman и PKCS. Это даст вам рейтинг А, но позволит 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, с оценкой А.