Como configurar o IIS 7.5 SSL \ TLS para funcionar com o iOS 9 ATS

Problema: nosso aplicativo móvel não pode mais estabelecer uma conexão segura com nosso serviço da Web, já que o iOS 9 agora usa o ATS.

Plano de fundo: iOS 9 apresenta App Transport Security

Configuração do servidor: Windows Server 2008 R2 SP1 (VM) IIS 7.5, certificados SSL da digicert. Firewall do Windows desativado.

Chave RSA 2048 bits (e 65537)

Emissor DigiCert SHA2 Secure Server CA

Algoritmo de assinatura SHA512comRSA

Estes são os requisitos de segurança de transporte de aplicativos:

O servidor deve suportar pelo menos a versão 1.2 do protocolo TLS (Transport Layer Security). As cifras de conexão são limitadas àquelas que fornecem sigilo direto (consulte a lista de cifras abaixo.) Os certificados devem ser assinados usando um algoritmo de hash de assinatura SHA256 ou melhor, com uma chave RSA de 2048 bits ou mais ou uma curva elíptica de 256 bits ou mais. (ECC). Certificados inválidos resultam em falha grave e sem conexão. Estas são as cifras aceitas:

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

O que foi tentado:

1. Adicionando exceções no aplicativo móvel para permitir que nosso domínio funcione, mas não quero seguir esse método não seguro, quero corrigir nosso SSL.
2. Utilizou o IIS Crypto para usar 'melhores práticas', 'pci' e configurações personalizadas. Até tentou modificar o conjunto de criptografia para apenas a lista acima e reordenar. Após cada tentativa, o servidor é reiniciado e o SSL Labs foi executado (após a limpeza do cache). Consegui passar de uma classificação F para A e até A-, mas isso só resultou no iOS 8 e 9 não conseguirem estabelecer conexões seguras. (Código NSURLErrorDomain = -1200 e _kCFStreamErrorCodeKey = -9806)
3. VM restaurada e tentei um script do PowerShell Configure o IIS para SSL Perfect Forward Secrecy e TLS 1.2 Até fiz uma segunda tentativa em que editei os códigos do script de energia para uma lista mínima do que é necessário.

Resultados: sempre similares, classificações de A ou A-. O iOS8 e o iOS9 não podem negociar conexão segura. A Simulação de handshake resulta em "Incompatibilidade de protocolo ou conjunto de cifras" para produtos Safari e iOS.

ATUALIZAÇÃO Depois de trabalhar com o suporte da Apple, fizemos algumas capturas de rastreamento de pacotes:

$ 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

Os três primeiros pacotes são o handshake de três vias clássico SYN - SYN-ACK - ACK que configura a conexão TCP. O quarto pacote é o iOS, enviando ao servidor uma mensagem TLS Client Hello, a primeira etapa na configuração de uma conexão TLS por essa conexão TCP. Separamos esta mensagem e ela parece bastante razoável. No quinto pacote, o servidor simplesmente interrompe a conexão (enviando um RST).

Alguém sabe por que o IIS 7.5 estaria fazendo um RST?

A pergunta é antiga, mas será encontrada durante a pesquisa. Passei algum tempo para encontrar a solução para o mesmo problema. Assim, decido escrever a resposta para compartilhar meus resultados com outras pessoas.

Resposta curta: você não deve usar o IIS Crypto para especificar a ordem dos Cipher Suites. Eu recomendo que você clique nos botões "Padrões" para remover a ordem anteriormente definida e use a Diretiva de Grupo ("Configuração do Computador" \ "Modelos Administrativos" \ "Rede" \ "Definições de Configuração SSL") para configurar os Cipher Suites por meio da política local.

O motivo do erro "incompatibilidade de protocolo ou conjunto de cifras" pode ser um dos seguintes :

• seu servidor suporta alguns "pacotes de cifras ruins"
• seu servidor não suporta algum conjunto de cifras, que DEVE ser suportado corresponde à especificação TLS.
• seu servidor suporta HTTP / 2 e possui alguns protocolos da lista negra acima dos outros protocolos, que não estão na lista . Normalmente, basta alterar a ordem dos conjuntos de cifras para corrigir o problema.

A lista negra exata pode ser diferente em diferentes sistemas. Você pode encontrar na Internet alguma lista negra. Por exemplo, o apêndice A da RFC 7540 (Hypertext Transfer Protocol versão 2 (HTTP / 2)) contém uma lista. Os conjuntos de cifras são TLS_RSA_WITH_AES_128_CBC_SHApara o TLS 1.2 (veja aqui ) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256e TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256para o TLS 1.3 (veja aqui ). O TLS_ECDHE_ECDSA_*importante é apenas usar certificado com curvas elípticas. Outro conjunto de cifras muito bom TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256ainda não foi implementado pela Microsoft. Além disso, você pode considerar adicionar pelo menos TLS_ECDHE_RSA_WITH_AES_256_CBC_SHApara oferecer suporte à conexão de sistemas antigos e TLS_RSA_WITH_AES_128_CBC_SHAoferecer suporte a sistemas muito antigos (Android 2.3.7, Java 6u45, OpenSSL 0.9.8y) e TLS_RSA_WITH_3DES_EDE_CBC_SHAapenas se precisar de suporte ao IE 8 / XP. Assim, você pode usar hoje, por exemplo

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

com TLS 1.0 desabilitado, TLS 1.1 para ter melhor segurança ou apenas

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

se você precisa ter boa segurança e o melhor desempenho.

Você pode definir o seguinte conjunto curto de conjunto de cifras, por exemplo, para resolver seu problema:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Abaixo, incluí um exemplo de configuração no Windows 10. Configurei o IIS 10 para ter uma classificação A + do Qualys SSL Labs com chave RSA 2048 e certificado SSL gratuito da Let's Encrypt .

Desativei 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, Olá unificado MD5, multiprotocolo, PCT 1.0, SSL 2.0, SSL 3.0 e TLS 1.0 / 1.1 manualmente no registro (consulte KB245030 ). Desabilitei os protocolos TLS 1.0 e TLS 1.1 apenas porque TLS_FALLBACK_SCSV (ataque de downgrade) não pode ser evitado no IIS até agora, o que torna impossível obter a classificação A + de www.ssllabs.com . Eu vejo isso como uma desvantagem, mas o TLS 1.2 é suportado atualmente muito amplo. A propósito, você pode usar DisabledByDefault: 1, mas Enabled: 1para TLS 1.0 e TLS 1.1. Poderia ser útil se você executasse o SQL Server 2008/2012 no computador. O servidor da Web não usará o TLS 1.0 e o TLS 1.1, mas o SQL Server usará.

O passo mais importante, que me deixa muito tempo e qual é o seu principal problema, foi a configuração do Cipher Suites. Eu fiz isso usando gpedit.msc. Eu escolhi "Configuração do computador" \ "Modelos administrativos" \ "Rede" \ "Definições de configuração SSL" e configurei o valor "Ordem do conjunto de criptografia SSL" para o seguinte

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

A ordem acima pode não ser ótima e não tenho certeza de que todos os protocolos acima sejam suportados no IIS 7.5 (usei o IIS 10.0 no Windows 10). No entanto, tenho certeza de que seu problema está relacionado à lista do Cipher Suite, porque tive exatamente o mesmo problema que você descreveu durante meus experimentos com a lista do Cipher Suite.

De qualquer forma, depois de definir as configurações acima no Group Polity e reiniciar o computador ( gpupdate /force /target:computernão foi suficiente nos meus testes), recebo classificações A + e a seguinte lista de resultados de testes da parte "Simulação de handshake":

Pode-se ver que o iOS é suportado com êxito para os seguintes clientes:

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

Os clientes que não oferecem suporte ao TLS 1.2 agora não me parecem tão importantes e acho que a configuração acima é um bom compromisso entre o suporte de clientes herdados e o uso de protocolos seguros.

Se sua imagem do IIS Crypto for recente, mantenha as configurações como estão, mas ative SHA, Diffie-Hellman e PKCS. Você receberá a classificação A, mas permitirá a conexão do iOS 8 e inferior.

Eu lutei com isso por alguns dias. Em particular, eu estava me conectando a partir de um aplicativo iOS usando o Xamarin Forms PCL para conectar-se a um serviço de descanso ASP.NET Web Api 2 com autenticação OAuth2 Bearer Token.

O que funcionou para mim no final foi usar as práticas recomendadas do IIS Crypto. Em seguida, edite a chave do registro que configurou para a ordem do conjunto de criptografia:

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

Tive sucesso com o seguinte valor:

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

O último foi encontrado usando o Charles Proxy, que negociou o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 automaticamente. O que me levou a isso foi que as conexões foram bem-sucedidas com o Charles Proxy ativado (com certificados de simulador instalados), mas falharam em contrário. Adicionar o pacote usado na negociação fez o truque. Parece (?) Que o proxy estava renegociando meu serviço de descanso com algo que era suportado pelo meu servidor, mas não pelo cliente iOS.

Observe que muitos dos conjuntos de cifras foram obtidos a partir da especificação de conjuntos preferenciais da ssllabs para vários dispositivos iOS / OSX. O valor acima deve ser um handshake com tudo, exceto o IE 6 no XP, de acordo com o ssllabs, com uma classificação A.