web-dev-qa-db-fra.com

Téléchargement de l'application iOS 9 à partir d'une erreur SSL d'Amazon S3: prise en charge de TLS 1.2

Je reçois

Une erreur SSL s'est produite et une connexion sécurisée au serveur ne peut pas être établie.

sur iOS 9 si j'essaie de télécharger un fichier depuis Amazon s3: https://s3.amazonaws.com/xyz/qer/IMG_0001.JPG

D'après ce que je comprends, Amazon s3 prend en charge TLS 1.2, voir: https://forums.aws.Amazon.com/thread.jspa?threadID=192512

S3 et Kinesis prennent actuellement en charge TLS 1.2 . enter image description here

"S3 et Kinesis prennent actuellement en charge TLS 1.2." 23 août 2015 21:19

Je ne sais pas pourquoi je reçois cette erreur SSL. Le compte doit être configuré pour tirer parti de TLS 1.2? J'aurais deviné que cela devrait être activé par défaut.

Je ne veux pas mettre ce domaine sur la liste d'informations.

EDIT: j'ai fini par utiliser

<key>NSAppTransportSecurity</key> 
<dict> 
  <key>NSExceptionDomains</key> 
  <dict> 
    <key>s3.amazonaws.com</key> 
    <dict> 
      <key>NSExceptionRequiresForwardSecrecy</key> 
        <false/> 
      <key>NSIncludesSubdomains</key> 
        <true/> 
    </dict> 
  </dict> 
</dict>
sslios9tls1.2
42
Zsolt

Edit 2016-01-03: Le certificat renouvelé pour s3.amazonaws.com utilise l'algorithme SHA256 et est conforme aux exigences ATS.

Réponse originale: s3.amazonaws.com utilise un certificat SHA1 qui ne répond pas aux exigences ATS, ce qui entraîne une défaillance grave. Selon App Transport Security Technote , ATS dans iOS9 a les exigences suivantes:

  1. Le serveur doit prendre en charge au moins la version 1.2 du protocole TLS (Transport Layer Security).

  2. Les chiffrements de connexion sont limités à ceux qui fournissent le secret de retransmission, à savoir,

    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

  3. 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é ECC (Elliptic-Curve) de 256 bits ou plus.

Les certificats non valides entraînent une défaillance matérielle et aucune connexion.

Le test du serveur SSL de SSL Labs ( https://www.ssllabs.com/ssltest/analyze.html?d=s3.amazonaws.com ) comprend une simulation de prise de contact pour ATS dans iOS 9 qui indique un échec pour s3.amazonaws.com.

Dev SSL Labs

39
Anand Bhat

Vous avez besoin de deux choses pour que l'application iOS 9 atteigne avec succès le point de terminaison SSL (S3 n'est qu'un exemple):

  • Forward Secrecy ( https://www.wikiwand.com/en/Forward_secrecy ) activé sur le serveur.

    Cette fonctionnalité n'est actuellement pas prise en charge par AWS S3 . La solution de contournement est que vous pouvez configurer le service AWS CloudFront (qui prend en charge FS) devant votre compartiment S3. L'installation est assez simple. Si vous utilisez CORS, n'oubliez pas que les en-têtes appropriés doivent être transmis via le proxy CloudFront.

  • Certificat SSL protégé SHA-256 sur le serveur.

    Une fois que vous aurez vos fichiers disponibles via Cloudfront, lorsque vous frappez l'URL ( https://somethinghashed1234wasdfawer421.cloudfront.net ) vous remarquerez que le certificat SSL là-bas utilise SHA-1. Comme c'est mauvais ... La solution pour cela est de protéger cela avec votre certificat SSL SHA-256 privé. Pour ce faire, vous devez spécifier CNAME pour le point de terminaison Cloudfront dans votre domaine. Cela vous permettra de sécuriser le compartiment avec votre propre certificat SSL. Configurez simplement votre DNS pour que l'entrée pointe vers cloudfront-bucket.mydomain.com vers ce vilain quelque chose de haché1234wasdfawer421.cloudfront.net. Téléchargez votre certificat SSL sur Amazon et définissez la protection SSL dans les paramètres de distribution Cloudfront. Voila!

Toutes les choses mentionnées sont facilement cliquables à partir de la console AWS (à l'exception du téléchargement du certificat SSL, qui doit être effectué via l'AWS CLI).

12
mieciu

Étant donné que S3 n'est pas actuellement entièrement conforme, selon cet article sur le blog AWS, leur recommandation officielle est d'exclure S3 d'App Transport Security en ajoutant cet ensemble de clés à votre Info.plist:

<key>NSAppTransportSecurity</key>
<dict>
      <key>NSExceptionDomains</key>
      <dict>
            <key>amazonaws.com</key>
            <dict>
                  <key>NSThirdPartyExceptionMinimumTLSVersion</key>
                  <string>TLSv1.0</string>
                  <key>NSThirdPartyExceptionRequiresForwardSecrecy</key>
                  <false/>
                  <key>NSIncludesSubdomains</key>
                  <true/>
            </dict>
            <key>amazonaws.com.cn</key>
            <dict>
                  <key>NSThirdPartyExceptionMinimumTLSVersion</key>
                  <string>TLSv1.0</string>
                  <key>NSThirdPartyExceptionRequiresForwardSecrecy</key>
                  <false/>
                  <key>NSIncludesSubdomains</key>
                  <true/>
            </dict>
      </dict>
</dict>

MISE À JOUR 27/10/15: Comme le souligne Pol dans les commentaires, même s'il s'agit d'une réponse officielle d'AWS, un Apple Engineer in les forums de support dit que c'est en fait un bug:

Il s'avère que le fait que NSExceptionRequiresForwardSecrecy assouplit l'exigence SHA-2/256 est un bogue; le comportement prévu de NSExceptionRequiresForwardSecrecy est le comportement documenté dans l'App Transport Security Technote, à savoir qu'il doit simplement activer des suites de chiffrement spécifiques.

Notre plan est de corriger ce bogue à un moment donné dans le futur. Nous nous attendons à résoudre ce problème d'une manière compatible, donc les gens qui ont utilisé par erreur NSExceptionRequiresForwardSecrecy pour désactiver l'exigence SHA-2/256 ne seront pas rompus . Cependant, prédire l'avenir est toujours un défi. Ce qui nous amène à ce que vous devez faire dès maintenant. [Une version précédente de cet article a donné des conseils moins concrets. Ce qui suit est une mise à jour qui resserre les choses.] Après en avoir discuté avec ATS Engineering, nos recommandations sont les suivantes:

Si vous utilisez un service d'hébergement spécifique, vous devriez consulter votre service d'hébergement pour obtenir les derniers conseils.

Dans des situations comme celle-ci, où le serveur est entièrement compatible avec ATS, à l'exception de l'exigence de signature de certificat SHA-2/256, nous vous recommandons de documenter précisément cet état de choses en utilisant NSExceptionAllowsInsecureHTTPLoads.

Vous devez essayer de rendre votre serveur entièrement compatible avec ATS dès que possible.

Lorsque cela se produit, vous devez mettre à jour votre application avec les paramètres ATS les plus sécurisés.

Je dois souligner que NSExceptionAllowsInsecureHTTPLoads n'est pas réellement non sécurisé. Il est tout aussi sécurisé que votre application actuellement lorsqu'elle est exécutée sur iOS 8. Cela signifie plutôt que votre application ne bénéficie pas de la sécurité supplémentaire fournie par ATS. Partagez et profitez

Je souligne. Notez que le plan actuel consiste à corriger le bogue d'une manière qui ne cassera pas le comportement des personnes qui ont utilisé NSExceptionRequiresForwardSecrecy pour résoudre ce problème, donc ce qui précède est toujours une réponse viable.

11
markquezada

Juste pour signaler que le problème avec les certificats d'Amazon est qu'ils utilisent SHA-1 et que la sécurité du transport d'application nécessite SHA-2/256.

Le fait que NSExceptionRequiresForwardSecrecy fonctionne est un bogue documenté ici sur forums de développement Apple . Selon la documentation et un ingénieur Apple dans le thread lié, une "meilleure" solution serait

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>s3.amazonaws.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
        </dict> 
    </dict> 
</dict>

J'utilise le terme "mieux" de façon très lâche et ne signifie qu'une solution qui n'exerce pas un bogue qui Apple va éventuellement corriger. Maintenant, c'est un correctif pour le problème de certificat uniquement :)

6
tmeisenh

Jusqu'à ce qu'Amazon tire la tête de ses * ss sur celui-ci, comme @Zsolt a suggéré d'insérer les clés et la valeur suivantes dans votre fichier plist.

MAIS assurez-vous de définir le NSExceptionDomain sur amazonaws.com au lieu de s3.amazonaws.com, en fonction de la façon dont vos actifs sont servis et de la région d'Amazon qui peut les servir, par exemple s3-us-west-1.amazonaws.com, donc ne pas définir explicitement le sous-domaine permettra aux ressources d'être correctement servies à partir de n'importe quel identifiant de région AWS.

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>amazonaws.com</key>
        <dict>
            <key>NSExceptionRequiresForwardSecrecy</key>
            <false/>
            <key>NSIncludesSubdomains</key>
            <true/>
        </dict>
    </dict>
</dict>
1
heading_to_tahiti