Problema:Nuestra aplicación móvil ya no puede establecer una conexión segura con nuestro servicio web ya que iOS 9 ahora usa ATS.
Fondo: iOS 9 presenta la seguridad del transporte de aplicaciones
Configuración del servidor:Windows Server 2008 R2 SP1 (VM) IIS 7.5, certificados SSL de digicert. Cortafuegos de Windows desactivado.
Clave RSA 2048 bits (e 65537)
Emisor DigiCert SHA2 Secure Server CA
Algoritmo de firma SHA512conRSA
Estos son los requisitos de seguridad del transporte de aplicaciones:
El servidor debe admitir al menos la versión 1.2 del protocolo Transport Layer Security (TLS). Los cifrados de conexión se limitan a aquellos que proporcionan secreto directo (consulte la lista de cifrados a continuación). Los certificados deben firmarse utilizando un algoritmo hash de firma SHA256 o superior, con una clave RSA de 2048 bits o superior o una curva elíptica de 256 bits o superior. (ECC) clave. Los certificados no válidos provocan una falla grave y no hay conexión. Estos son los cifrados aceptados:
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 _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
Lo que se ha probado:
- Agregar excepciones en la aplicación móvil para permitir que nuestro dominio funcione, pero no quiero utilizar este método no seguro, quiero arreglar nuestro SSL.
- UsadoCripto IISutilizar 'mejores prácticas', probar 'pci' y configuraciones personalizadas. Incluso intenté modificar el paquete de cifrado solo a la lista anterior y reordenarlo. Después de cada intento, el servidor se reinicia yLaboratorios SSLse ejecutó (después de borrar el caché). Logré pasar de una calificación F a A, e incluso A-, pero esto solo resultó en que iOS 8 y 9 no pudieran establecer conexiones seguras. (Código NSURLErrorDomain=-1200 y _kCFStreamErrorCodeKey=-9806)
- VM restaurada y probé un script de PowerShellConfigure su IIS para SSL Perfect Forward Secrecy y TLS 1.2Incluso hice un segundo intento en el que edité los cifrados del script de energía para obtener una lista mínima de lo que se requiere.
Resultados:Siempre similares, calificaciones de A o A-. iOS8 e iOS9 no pueden negociar una conexión segura. La simulación de protocolo de enlace genera una "no coincidencia de protocolo o conjunto de cifrado" para los productos Safari e iOS.
ACTUALIZARDespués de trabajar con el soporte de Apple, realizamos una captura de seguimiento de paquetes:
$ 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
Los primeros tres paquetes son el clásico protocolo de enlace de tres vías SYN - SYN-ACK - ACK que configura la conexión TCP. El cuarto paquete es que iOS envía a su servidor un mensaje de saludo del cliente TLS, el primer paso para configurar una conexión TLS a través de esa conexión TCP. He separado este mensaje y parece bastante razonable. En el quinto paquete, el servidor simplemente interrumpe la conexión (enviando un RST).
¿Alguien sabe por qué IIS 7.5 haría un RST?
Respuesta1
La pregunta es antigua, pero se encontrará durante la búsqueda. Pasé algún tiempo para encontrar una solución al mismo problema. Por eso decido escribir la respuesta para compartir mis resultados con otros.
Respuesta corta: no debe utilizar IIS Crypto para especificar el orden de Cipher Suites. Le recomiendo que haga clic en los botones "Valores predeterminados" para eliminar el orden establecido previamente y luego use la Política de grupo ("Configuración de computadora" \ "Plantillas administrativas" \ "Red" \ "Configuración SSL") para configurar Cipher Suites a través de la política local.
El motivo del error "no coincide el protocolo o el conjunto de cifrado" puede ser uno de los siguientes:
- su servidor admite algún "conjunto de cifrado incorrecto"
- su servidor no admite algún conjunto de cifrado, que DEBE ser compatible y corresponde a la especificación TLS.
- su servidor soporta HTTP/2 y tiene algunos protocolos della lista negra arribalos demás protocolos, que no están en la lista. Normalmente basta con cambiar el orden de los conjuntos de cifrado para solucionar el problema.
La lista negra exacta podría ser diferente en diferentes sistemas. Puedes encontrar en Internet alguna lista negra. Por ejemplo,Apéndice Ade RFC 7540 (Protocolo de transferencia de hipertexto versión 2 (HTTP/2)) contiene una lista. Los conjuntos de cifrado son TLS_RSA_WITH_AES_128_CBC_SHApara TLS 1.2 (consulteaquí) y TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256para TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS 1.3 (consulteaquí). Lo TLS_ECDHE_ECDSA_*único importante es que utilice un certificado con curvas elípticas. TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256Microsoft aún no ha implementado otro conjunto de cifrado muy bueno . Además, puede considerar agregar al menos TLS_ECDHE_RSA_WITH_AES_256_CBC_SHAcompatibilidad con conexión desde sistemas antiguos y TLS_RSA_WITH_AES_128_CBC_SHAcompatibilidad con sistemas muy antiguos (Android 2.3.7, Java 6u45, OpenSSL 0.9.8y) y TLS_RSA_WITH_3DES_EDE_CBC_SHAsolo si necesita compatibilidad con IE 8/XP. Así puedes utilizar hoy, por ejemplo.
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
con TLS 1.0, TLS 1.1 deshabilitadopara tener mayor seguridad o simplemente
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
si necesitas tener buena seguridad y el mejor rendimiento.
Puede configurar el siguiente conjunto breve de conjunto de cifrado, por ejemplo, para resolver su problema:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
A continuación incluyo un ejemplo de configuración en Windows 10. Configuré IIS 10 para tenerCalificación A+ de Qualys SSL Labs con clave RSA 2048 y certificado SSL gratuito de Let's Encrypt.
Desactivé 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, Hola unificado multiprotocolo, PCT 1.0, SSL 2.0, SSL 3.0 y TLS 1.0/1.1manualmente en el registro(verKB245030). Deshabilité los protocolos TLS 1.0 y TLS 1.1 solo porque TLS_FALLBACK_SCSV (ataque de degradación) no se puede prevenir en IIS hasta ahora, lo que hace imposible obtener la calificación A+ dewww.ssllabs.com. Lo veo como una desventaja, pero actualmente TLS 1.2 tiene un soporte muy amplio. Por cierto, puedes usar DisabledByDefault: 1, pero Enabled: 1para TLS 1.0 y TLS 1.1. Podría resultar útil ejecutar SQL Server 2008/2012 en la computadora. El servidor web no utilizará TLS 1.0 y TLS 1.1, pero sí SQL Server.
El paso más importante, que me quita mucho tiempo y que es su principal problema, fue la configuración de Cipher Suites.Lo hice usando gpedit.msc. Elegí "Configuración de computadora" \ "Plantillas administrativas" \ "Red" \ "Configuración SSL" y configuré el valor "Orden de conjunto de cifrado SSL" con el siguiente
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
El orden anterior podría no ser óptimo y no estoy seguro de que todos los protocolos anteriores sean compatibles con IIS 7.5 (usé IIS 10.0 de Windows 10). Sin embargo, estoy seguro de que su problema está relacionado con la lista de Cipher Suite, porque tuve exactamente el mismo problema que usted describió durante mis experimentos con la lista de Cipher Suite.
De cualquier manera, después de configurar los ajustes anteriores en Group Polity yreiniciando la computadora( gpupdate /force /target:computerno fue suficiente en mis pruebas) Obtuve calificaciones A+ y la siguiente lista de resultados de las pruebas de la parte "Simulación de apretón de manos":
Se puede ver que iOS es compatible con éxito con los siguientes clientes:
Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9
Los clientes que no soportan TLS 1.2 no me parecen tan importantes ahora y creo que la configuración anterior es un buen compromiso entre el soporte de clientes heredados y el uso de protocolos seguros.
Respuesta2
Si su imagen IIS Crypto es reciente, mantenga la configuración como está pero habilite SHA, Diffie-Hellman y PKCS. Esto le dará la calificación A pero permitirá que se conecte iOS 8 y versiones anteriores.
Respuesta3
Luché con esto durante unos días. En particular, me estaba conectando desde una aplicación de iOS usando Xamarin Forms PCL para conectarme a un servicio de descanso ASP.NET Web Api 2 con autenticación de token de portador OAuth2.
Lo que funcionó para mí al final fue utilizar las mejores prácticas de IIS Crypto. Luego edite la clave de registro que configuró para el orden del conjunto de cifrado:
KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Function
Tuve éxito con el siguiente 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_P 256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_ SHA256_P384,TLS_ECDHE_RSA_CON_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_CON_AES_1 28_CBC_SHA_P521,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_RSA_CON_AES_256_GCM_SHA384,TLS_RSA_CON_AES_128_GCM_SHA 256,TLS_RSA_CON_AES_256_CBC_SHA256,TLS_RSA_CON_AES_256_CBC_SHA,TLS_RSA_CON_AES _128_CBC_SHA256,TLS_RSA_CON_AES_128_CBC_SHA,TLS_RSA_CON_3DES_EDE_CBC_SHA,TLS_EC DHE_ECDSA_CON_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_CON_AES_256_GCM_SHA384_P 384,TLS_ECDHE_ECDSA_CON_AES_128_GCM_SHA256_P521,TLS_ECDHE_ECDSA_CON_AES_128_GCM _SHA256_P384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_25 6_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES _256_CBC_SHA_P256,TLS_ECDHE_ECDSA_CON_AES_128_CBC_SHA256_P521,TLS_ECDHE_ECDSA_WI TH_AES_128_CBC_SHA256_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_CON_AES_128_CBC_SHA_P521,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TL S_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_DS S_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 _CON_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_CON_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WI TH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_CON_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_CON_A ES_256_CBC_SHA, TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_DES_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
El último se encontró utilizando Charles Proxy, que negoció TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 automáticamente. Lo que me llevó a esto fue que las conexiones se realizaban correctamente con Charles Proxy activado (con los certificados del simulador instalados), pero por lo demás fallaban. Agregar la suite que utilizó en la negociación funcionó. Parece (?) que el proxy estaba renegociando con mi servicio de descanso con algo que era compatible con mi servidor, pero no con el cliente iOS.
Tenga en cuenta que muchos de los conjuntos de cifrado se obtuvieron de la especificación de conjuntos preferidos de ssllabs para varios dispositivos iOS/OSX. El valor anterior debería funcionar con todo menos con IE 6 en XP.según ssllabs, con calificación A.