Comment configurer IIS 7.5 SSL \ TLS pour fonctionner avec iOS 9 ATS

Problème: notre application mobile ne peut plus établir de connexion sécurisée avec notre service Web, car iOS 9 utilise désormais ATS.

Contexte: iOS 9 introduit la sécurité du transport d'application

Configuration du serveur: Windows Server 2008 R2 SP1 (VM) IIS 7.5, certificats SSL de Digicert. Pare-feu Windows désactivé.

Clé RSA 2048 bits (e 65537)

Émetteur DigiCert SHA2 Secure Server CA

Algorithme de signature SHA512withRSA

Ce sont les exigences de sécurité du transport d'application:

Le serveur doit prendre en charge au moins le protocole TLS (Transport Layer Security) version 1.2. Les chiffrements de connexion sont limités à ceux qui fournissent le secret de retransmission (voir la liste des chiffrements ci-dessous.) Les certificats doivent être signés à l'aide d'un algorithme de hachage de signature SHA256 ou supérieur, avec une clé RSA de 2048 bits ou plus ou une clé elliptique de 256 bits ou plus. (ECC). Les certificats non valides entraînent une défaillance matérielle et aucune connexion. Ce sont les chiffres acceptés:

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

Ce qui a été essayé:

1. Ajouter des exceptions dans l'application mobile pour permettre à notre domaine de fonctionner, mais je ne veux pas utiliser cette méthode non sécurisée, je veux corriger notre SSL.
2. Utilisé IIS Crypto pour utiliser les «meilleures pratiques», essayé «pci» et les configurations personnalisées. J'ai même essayé de modifier la suite de chiffrement pour la liste ci-dessus et de la réorganiser. Après chaque tentative, le serveur est redémarré et SSL Labs a été exécuté (après avoir effacé le cache). J'ai réussi à passer d'une note F à une note A, voire A-, mais cela n'a permis qu'à iOS 8 et 9 de ne pas pouvoir établir de connexions sécurisées. (Code NSURLErrorDomain = -1200 et _kCFStreamErrorCodeKey = -9806)
3. VM restaurée et essayé un script powershell Configurer votre IIS pour SSL Perfect Forward Secrecy et TLS 1.2 J'ai même fait une deuxième tentative où j'ai édité les cyphers du script d'alimentation pour une liste minimale de ce qui est requis.

Résultats: Toujours similaires, notes de A ou A-. iOS8 et iOS9 ne peuvent pas négocier de connexion sécurisée. La simulation de prise de contact entraîne une «non-concordance de protocole ou de suite de chiffrement» pour les produits Safari et iOS.

MISE À JOUR Après avoir travaillé avec le support Apple, nous avons fait une capture de trace de paquet:

$ 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

Les trois premiers paquets sont la poignée de main classique à trois voies SYN - SYN-ACK - ACK qui établit la connexion TCP. Le quatrième paquet est iOS envoyant à votre serveur un message Bonjour client TLS, la première étape de la configuration d'une connexion TLS sur cette connexion TCP. J'ai séparé ce message et il semble assez raisonnable. Dans le cinquième paquet, le serveur abandonne simplement la connexion (en envoyant un RST).

Est-ce que quelqu'un sait pourquoi IIS 7.5 ferait un RST?

La question est ancienne, mais elle sera trouvée lors de la recherche. J'ai passé un peu de temps à trouver une solution au même problème. Je décide donc d'écrire la réponse pour partager mes résultats avec les autres.

Réponse courte: vous ne devez pas utiliser IIS Crypto pour spécifier l'ordre des suites de chiffrement. Je vous recommande de cliquer sur les boutons "Paramètres par défaut" pour supprimer l'ordre précédemment défini, puis d'utiliser la stratégie de groupe ("Configuration ordinateur" \ "Modèles d'administration" \ "Réseau" \ "Paramètres de configuration SSL") pour configurer les suites de chiffrement via la stratégie locale.

La raison de l'erreur "non-concordance du protocole ou de la suite de chiffrement" peut être l'une des suivantes :

• votre serveur prend en charge une "mauvaise suite de chiffrement"
• votre serveur ne prend pas en charge une suite de chiffrement, qui DOIT être prise en charge correspond à la spécification TLS.
• votre serveur prend en charge HTTP / 2 et il a certains protocoles de la liste noire au - dessus des autres protocoles, qui ne sont pas dans la liste . Il suffit généralement de modifier l'ordre des suites de chiffrement pour résoudre le problème.

La liste noire exacte peut être différente sur différents systèmes. Vous pouvez trouver sur Internet une liste noire. Par exemple, l' annexe A de la RFC 7540 (Hypertext Transfer Protocol Version 2 (HTTP / 2)) contient une liste. Les suites de chiffrement sont TLS_RSA_WITH_AES_128_CBC_SHAdestinées à TLS 1.2 (voir ici ) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256et TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256à TLS 1.3 (voir ici ). L' TLS_ECDHE_ECDSA_*important est seulement d'utiliser un certificat avec des courbes elliptiques. Une autre très bonne suite de chiffrement TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256n'est pas encore implémentée par Microsoft. En outre, vous pouvez envisager d'ajouter au moins TLS_ECDHE_RSA_WITH_AES_256_CBC_SHApour prendre en charge la connexion à partir d'anciens systèmes et TLS_RSA_WITH_AES_128_CBC_SHApour prendre en charge de très anciens systèmes (Android 2.3.7, Java 6u45, OpenSSL 0.9.8y) et TLS_RSA_WITH_3DES_EDE_CBC_SHAuniquement si vous avez besoin de la prise en charge IE 8 / XP. Ainsi, vous pouvez utiliser aujourd'hui, par exemple

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

avec TLS 1.0 désactivé, TLS 1.1 pour avoir une meilleure sécurité ou tout simplement

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

si vous avez besoin d'une bonne sécurité et des meilleures performances.

Vous pouvez par exemple définir l'ensemble court de suite de chiffrement suivant pour résoudre votre problème:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Ci-dessous, j'inclus un exemple de configuration sur Windows 10. J'ai configuré IIS 10 pour avoir une note A + de Qualys SSL Labs avec la clé RSA 2048 et un certificat SSL gratuit de Let's Encrypt .

J'ai désactivé 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 et TLS 1.0 / 1.1 manuellement dans le registre (voir KB245030 ). J'ai désactivé les protocoles TLS 1.0 et TLS 1.1 uniquement parce que TLS_FALLBACK_SCSV (attaque de rétrogradation) ne peut pas être empêché dans IIS jusqu'à présent, ce qui rend impossible d'obtenir la note A + de www.ssllabs.com . Je le vois comme un inconvénient, mais TLS 1.2 est actuellement pris en charge très largement. Par ailleurs, vous pouvez utiliser DisabledByDefault: 1, mais Enabled: 1pour TLS 1.0 et TLS 1.1. Il pourrait être utile d'exécuter SQL Server 2008/2012 sur l'ordinateur. Le serveur Web n'utilisera pas TLS 1.0 et TLS 1.1, mais SQL Server l'utilisera.

L'étape la plus importante, qui me demande beaucoup de temps et qui est votre principal problème a été la configuration des Cipher Suites. Je l'ai fait en utilisant gpedit.msc. J'ai choisi "Configuration ordinateur" \ "Modèles d'administration" \ "Réseau" \ "Paramètres de configuration SSL" et configuré la valeur "Ordre de la suite de chiffrement SSL" comme suit

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

L'ordre ci-dessus pourrait ne pas être optimal et je ne suis pas sûr que tous les protocoles ci-dessus soient pris en charge sur IIS 7.5 (j'ai utilisé IIS 10.0 à partir de Windows 10). Néanmoins, je suis sûr que votre problème est lié à la liste de la suite de chiffrement, car j'ai eu exactement le même problème que celui que vous avez décrit lors de mes expériences avec la liste de la suite de chiffrement.

De toute façon, après avoir configuré les paramètres ci-dessus dans Group Polity et redémarré l'ordinateur (cela gpupdate /force /target:computerne suffisait pas dans mes tests), j'obtiens des notes A + et la liste suivante des résultats des tests de la partie "Handshake Simulation":

On peut voir que iOS est pris en charge avec succès pour les clients suivants:

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

Les clients qui ne prennent pas en charge TLS 1.2 ne me semblent pas si importants maintenant et je pense que la configuration ci-dessus est un bon compromis entre la prise en charge des clients hérités et l'utilisation de protocoles sécurisés.

Si votre image Crypto IIS est récente, conservez les paramètres tels quels, mais activez SHA, Diffie-Hellman et PKCS. Cela vous donnera la note A mais permettra à iOS 8 et inférieur de se connecter.

J'ai lutté avec ça pendant quelques jours. En particulier, je me connectais depuis une application iOS utilisant Xamarin Forms PCL pour me connecter à un service de repos ASP.NET Web Api 2 avec l'authentification OAuth2 Bearer Token.

Ce qui a finalement fonctionné pour moi a été d'utiliser les meilleures pratiques d'IIS Crypto. Modifiez ensuite la clé de registre qu'elle a définie pour l'ordre de la suite de chiffrement:

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

J'ai réussi avec la valeur suivante:

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

Le dernier a été trouvé en utilisant Charles Proxy, qui a négocié automatiquement TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Ce qui m'a amené à cela, c'est que les connexions réussissaient avec Charles Proxy (avec les certificats du simulateur installés), mais ont échoué autrement. L'ajout de la suite utilisée dans la négociation a fait l'affaire. Il semble (?) Que le proxy renégociait avec mon service de repos avec quelque chose qui était pris en charge par mon serveur, mais pas le client iOS.

Notez que bon nombre des suites de chiffrement ont été obtenues à partir de la spécification de ssllabs des suites préférées pour divers appareils iOS / OSX. La valeur ci-dessus devrait être utilisée avec tout sauf IE 6 sur XP selon ssllabs, avec une note A.