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.
Antecedentes: iOS 9 presenta App Transport Security
Configuración del servidor: Windows Server 2008 R2 SP1 (VM) IIS 7.5, certificados SSL de digicert. Firewall de Windows desactivado.
Clave RSA 2048 bits (e 65537)
Emisor DigiCert SHA2 Secure Server CA
Algoritmo de firma SHA512 con RSA
Estos son los requisitos de seguridad de transporte de aplicaciones:
El servidor debe admitir al menos la versión 1.2 del protocolo de Seguridad de la capa de transporte (TLS). Los cifrados de conexión están limitados a aquellos que brindan confidencialidad directa (consulte la lista de cifrados a continuación). Los certificados deben firmarse utilizando un SHA256 o un algoritmo hash de firma mejor, con una clave RSA de 2048 bits o más o una curva elíptica de 256 bits o más Tecla (ECC). Los certificados no válidos provocan un fallo grave y no hay conexión. Estas son las cifras aceptadas:
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
Lo que se ha intentado:
- Agregando excepciones en la aplicación móvil para permitir que nuestro dominio funcione, pero no quiero seguir con este método no seguro, quiero arreglar nuestro SSL.
- Usé IIS Crypto para usar 'mejores prácticas', probé 'pci' y configuraciones personalizadas. Incluso intenté modificar la suite de cifrado solo para la lista anterior y reordenar. Después de cada intento, se reinicia el servidor y se ejecuta SSL Labs (después de borrar la memoria caché). Tuve éxito al pasar de una calificación F a una A, e incluso A-, pero esto solo resultó en que iOS 8 y 9 no pudieron establecer conexiones seguras. (Código de dominio NSURLError = -1200 y _kCFStreamErrorCodeKey = -9806)
- Restablecí la máquina virtual y probé un script de PowerShell. Configure su IIS para SSL Perfect Forward Secrecy y TLS 1.2 . Incluso hice un segundo intento en el que edité los cifrados del script de poder en 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 apretón de manos da como resultado una "discrepancia de protocolo o conjunto de cifrado" para productos Safari e iOS.
ACTUALIZACIÓN Después de trabajar con el soporte de Apple, hicimos algunas capturas de rastreo 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 apretón de manos de tres vías SYN - SYN-ACK - ACK que configura la conexión TCP. El cuarto paquete es iOS enviando a su servidor un mensaje de saludo de 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 desconecta la conexión (enviando un RST).
¿Alguien sabe por qué IIS 7.5 estaría haciendo un RST?
Respuestas:
La pregunta es antigua, pero se encontrará durante la búsqueda. Pasé algún tiempo para encontrar la solución al mismo problema. Por lo tanto, decido escribir la respuesta para compartir mis resultados con otros.
Respuesta corta: no debe usar IIS Crypto para especificar el orden de Cipher Suites. Le recomiendo que haga clic en los botones "Predeterminados" para eliminar el orden previamente establecido y luego use la Política de grupo ("Configuración del equipo" \ "Plantillas administrativas" \ "Red" \ "Configuración de configuración SSL") para configurar Cipher Suites a través de la política local.
La razón del error "incompatibilidad de protocolo o conjunto de cifrado" puede ser una de las siguientes :
La lista negra exacta podría ser diferente en diferentes sistemas. Puedes encontrar en Internet alguna lista negra. Por ejemplo, el Apéndice A de 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_SHA
para TLS 1.2 (ver aquí )TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
yTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
para TLS 1.3 (ver aquí ). ElTLS_ECDHE_ECDSA_*
sólo son importantes es que el uso de certificados con curvas elípticas.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Microsoft aún no ha implementado otro conjunto de cifrado muy bueno . Además, puede considerar agregar al menosTLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
para admitir la conexión desde sistemas antiguos yTLS_RSA_WITH_AES_128_CBC_SHA
admitir sistemas muy antiguos (Android 2.3.7, Java 6u45, OpenSSL 0.9.8y) yTLS_RSA_WITH_3DES_EDE_CBC_SHA
solo si necesita soporte para IE 8 / XP. Así puedes usar hoy, por ejemplocon TLS 1.0 deshabilitado, TLS 1.1 para tener una mejor seguridad o simplemente
si necesita tener buena seguridad y el mejor rendimiento.
Puede configurar el siguiente conjunto corto de conjunto de cifrado, por ejemplo, para resolver su problema:
A continuación, incluyo un ejemplo de configuración en Windows 10. Configuré IIS 10 para tener una calificación A + de Qualys SSL Labs con la clave RSA 2048 y un certificado SSL gratuito de Let's Encrypt .
Deshabilité 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, Saludo unificado multiprotocolo, PCT 1.0, SSL 2.0, SSL 3.0 y TLS 1.0 / 1.1 manualmente en el registro (consulte KB245030 ). Deshabilité los protocolos TLS 1.0 y TLS 1.1 solo porque TLS_FALLBACK_SCSV (ataque de degradación) no se puede evitar en IIS hasta ahora, lo que hace imposible obtener la calificación A + de www.ssllabs.com . Lo veo como una desventaja, pero TLS 1.2 es compatible actualmente muy amplio. Por cierto, puede usar
DisabledByDefault: 1
, peroEnabled: 1
para TLS 1.0 y TLS 1.1. Podría ser útil si ejecuta SQL Server 2008/2012 en la computadora. El servidor web no usará TLS 1.0 y TLS 1.1, pero SQL Server sí lo hará.El paso más importante, que me da mucho tiempo y que es su principal problema, fue la configuración de Cipher Suites. Lo hice usando
gpedit.msc
. Elegí "Configuración del equipo" \ "Plantillas administrativas" \ "Red" \ "Configuración de configuración SSL" y configuré el valor "Orden de SSL Cipher Suite" para lo siguienteEl orden anterior podría no ser óptimo y no estoy seguro de que todos los protocolos anteriores sean compatibles con IIS 7.5 (utilicé 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 y reiniciar la computadora (
gpupdate /force /target:computer
no fue suficiente en mis pruebas), obtengo calificaciones A + y la siguiente lista de resultados de pruebas de la parte "Simulación de apretón de manos":Se puede ver que iOS es exitosamente compatible con los siguientes clientes:
Los clientes que no son compatibles con TLS 1.2 ahora no me parecen tan importantes y creo que la configuración anterior es un buen compromiso entre el soporte de clientes heredados y el uso de protocolos seguros.
fuente
Si su imagen de 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 inferiores.
fuente
Luché con esto por 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 OAuth2 Bearer Token.
Lo que funcionó para mí al final fue usar las mejores prácticas de IIS Crypto. Luego edite la clave de registro que estableció para el orden de la suite de cifrado:
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_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
El último se encontró usando Charles Proxy, que negoció TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 automáticamente. Lo que me llevó a esto fue que las conexiones estaban teniendo éxito con Charles Proxy activado (con certificados de simulador instalados), pero fallaron de otra manera. Agregar la suite que usó en la negociación hizo el truco. 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 muchas de las suites de cifrado se obtuvieron de la especificación de ssllabs de suites preferidas para varios dispositivos iOS / OSX. El valor anterior debería ser un apretón de manos con todo, excepto IE 6 en XP de acuerdo con ssllabs, con una calificación de A.
fuente