Le Secure Sockets Layer (SSL)—maintenant techniquement connu sous le nom de Transport Layer Security(TLS)—est un bloc de construction commun pour les communications cryptées entre les clients et les serveurs. Il est possible qu’une application utilise SSL de manière incorrecte, de sorte que des entités malveillantes puissent intercepter les données d’une application sur le réseau., Pour vous aider à vous assurer que cela ne se produitpour votre application, Cet article met en évidence les pièges courants lors de l’utilisation de protocoles réseau sécurisés et répond à certaines préoccupations plus importantes concernant l’utilisation de L’Infrastructure à clé publique (PKI).
Vous devriez également lire AndroidSecurity Overview ainsi que PermissionsOverview.
Concepts
dans un scénario D’utilisation SSL typique, un serveur est configuré avec un certificat contenant la clé apublic ainsi qu’une clé privée correspondante., Dans le cadre de la prise de contact entre un client SSL et un serveur, le serveur prouve qu’il possède la clé privée en signant son certificat avec la cryptographie à clé publique.
cependant, n’importe qui peut générer son propre certificat et sa propre Clé privée, donc une simple poignée de main ne prouve rien sur le serveur autre que le fait que le serveur connaît la clé privée qui correspond à la clé publique du certificat. Une façon de résoudre ce problème, les clienthave un ensemble d’un ou de plusieurs certificats approuvés. Si le certificat n’est pas dans l’ensemble, le serveur ne doit pas être approuvé.,
Il y a plusieurs inconvénients à cette approche simple. Les serveurs devraient pouvoir passer à des clés plus fortes au fil du temps (« rotation des clés »), ce qui remplace la clé publique dans le certificat par une nouvelle. Malheureusement, l’application client doit maintenant être mise à jour en raison de ce qui est essentiellement un changement de configuration du serveur. Cela est particulièrement problématique si le serveurest pas sous le contrôle du développeur de l’application, par exemple s’il s’agit d’un service web tiers. Thisapproach a également des problèmes si l’application doit parler à des serveurs arbitraires tels qu’un navigateur web ou une application de messagerie.,
afin de remédier à ces inconvénients, les serveurs sont généralement configurés avec des certificats d’émetteurs bien connus appelés Autorités de certification (CAs).La plate-forme hôte contient généralement une liste de CAs bien connus qu’il trusts.As d’Android 4.2 (Jelly Bean), Android contient actuellement plus de 100 CAs qui sont mis à jour dans chaque version. Semblable à un serveur, une autorité de certification a un certificat et une clé privée. Lors de l’émission d’un certificat pour un serveur, L’autorité de certification signe le certificat du serveur à l’aide de sa clé privée. Theclient peut alors vérifier que le serveur dispose d’un certificat émis par une autorité de certification connue de la plateforme.,
cependant, tout en résolvant certains problèmes, l’utilisation de CAs En introduit un autre. Parce que L’autorité de certification émet des certificats pour de nombreux serveurs, vous avez toujours besoin d’un moyen de vous assurer que vous parlez au serveur que vous voulez. Pour résoudre ce problème, le certificat délivré par L’autorité de certification identifie le servereither avec un nom spécifique tel que gmail.com ou un ensemble wildcarded ofhosts tel que *.google.com.
L’exemple suivant rendra ces concepts un peu plus concrets., Dans l’extrait ci-dessous à partir d’une ligne de commande, la commande opensslde l’outil s_client examine les informations de certificat de serveur de Wikipedia. Itspecifie le port 443 car C’est la valeur par défaut pour HTTPS. La commande envoie la sortie de openssl s_client à openssl x509, qui formate les informations sur les certificats selon la norme X. 509. Plus précisément, la commande demande le sujet, qui contient les informations sur le nom du serveur, et l’émetteur, qui identifie L’autorité de certification.,
Vous pouvez voir que le certificat a été émis pour les serveurs correspondant à *.wikipedia.org par les RapidSSL ca.
un exemple HTTPS
En supposant que vous ayez un serveur web avec un acertificate émis par une autorité de certification bien connue, vous pouvez faire une demande sécurisée avec du code assimple ceci:
Oui, cela peut vraiment être aussi simple. Si vous souhaitez personnaliser la requête HTTP, vous pouvez convertir toan HttpURLConnection., La documentation Android pour HttpURLConnection contient d’autres exemples sur la façon de traiter les en-têtes de réponse requestand, de publier du contenu, de gérer les cookies, d’utiliser des proxys, de mettre en cache les réponses,etc. Mais en termes de détails pour vérifier les certificats et les noms d’hôte, Androidframework s’en charge pour vous via ces API.C’est là que vous voulez être si possible. Cela dit, voici quelques autres considérations.,
problèmes courants de vérification des certificats de serveur
supposons qu’au lieu de recevoir le contenu de getInputStream(), il lève une exception:
cela peut se produire pour plusieurs raisons, notamment:
- l’autorité de certification qui a émis le certificat de serveur était inconnue
- Le intermédiaire CA
les sections suivantes expliquent comment résoudre ces problèmes tout en assurant la sécurité de votre connexion au serveur.,
autorité de certification inconnue
dans ce cas,SSLHandshakeException se produit parce que vous avez une autorité de certification qui n’est pas approuvée par le système. Cela peut être dû au fait que vous avez un certificat d’une nouvelle autorité de certification qui n’est pas encore approuvé par Android ou que votre application fonctionne sur une ancienne version sans L’autorité de certification. Le plus souvent, une CA est inconnue parce qu’il ne s’agit pas d’une CA publique, mais d’une CA privée émise par un organisme tel qu’un gouvernement,une société ou un établissement d’enseignement pour leur propre usage.
heureusement, vous pouvez apprendre à HttpsURLConnection à faire confiance à un ensemble spécifique de CAs., Le procedurecan être un peu compliquée, donc, ci-dessous est un exemple qui prend une autorité de certification spécifique froman InputStream, il l’utilise pour créer un KeyStore,qui est ensuite utilisé pour créer et initialiser unTrustManager. Un TrustManager est ce que le système utilise pour valider les certificats du serveur et—en en créant un à partir d’un KeyStore avec un ou plusieurs CAs—ceux-ci seront les seuls CAs approuvés par ce TrustManager.,
compte tenu de la nouvelle TrustManager,l’exemple initialise une nouvelle balise SSLContext qui providesan SSLSocketFactory vous pouvez utiliser pour remplacer la valeur par défautSSLSocketFactory à partir deHttpsURLConnection. De cette façon, theconnection utilisera votre CAs pour la validation du certificat.
Voici l’exemple en utilisant une autorité de certification organisationnelle de L’Université de Washington:
avec unTrustManager personnalisé qui connaît votre autorité de certification,le système est capable de valider que votre certificat de serveur provient d’un émetteur de confiance.,
attention: de nombreux sites Web décrivent une mauvaise solution alternative qui consiste à installer unTrustManager qui ne fait rien. Si vous faites cela, vous pourriez aussi bien notbe chiffrer votre communication, parce que n’importe qui peut attaquer vos utilisateurs à un point d’accès Wi-Fi public en utilisant des astuces DNS pour envoyer vos utilisateurs ‘ trafic via un proxy de leur propre qui prétend être votre serveur. L’attaquant peut ensuite enregistrer des mots de passe et d’autres données personnelles., Cela fonctionne parce que l’attaquant peut générer acertificate et-sans un TrustManager qui valorise en fait que le certificat provient d’une trustedsource—votre application pourrait parler à n’importe qui. Alors ne faites pas cela, même pas Temporairement. Vous pouvez toujours faire confiance à votre application l’émetteur du certificat du serveur, alors faites-le simplement.
certificat de serveur auto-signé
le deuxième cas deSSLHandshakeException esten raison d’un certificat auto-signé, ce qui signifie que le serveur se comporte comme sa propre autorité de certification.,Ceci est similaire à une autorité de certification inconnue, vous pouvez donc utiliser la même approche de la section précédente.
Vous pouvez créer votre propreTrustManager,cette fois en faisant confiance directement au certificat du serveur. Cela a tous les aspects discutés précédemment de lier votre application directement à un certificat, mais peut être fait de manière sécurisée. Cependant, vous devez faire attention à vous assurer que votre certificat auto-signé a une clé extrêmement forte. À partir de 2012, une signature RSA 2048 bits avec un exposant de 65537 expirant tôt est acceptable., Lors de la rotation des touches, vous devez vérifier les recommandations d’anauthority (telles que NIST) sur ce qui est acceptable.
Autorité de certification intermédiaire manquante
le troisième cas deSSLHandshakeExceptionse produit en raison d’une autorité de certification intermédiaire manquante. La plupart des publicCAs ne signent pas de certificats de serveur directement. Au lieu de cela,ils utilisent leur certificat CA principal, appelé CA racine, pour signer des CAs intermédiaires. Ils le font afin que l’autorité de certification racine puisse être storedoffline pour réduire le risque de compromis., Cependant, les systèmes d’exploitation comme Android typiquementtrust uniquement racine CAs directement,ce qui laisse un court écart de confiance entre le servercertificate—signé par L’autorité de certification intermédiaire—et le vérificateur de certificat, qui connaît l’autorité de certification racine. Pour résoudre ce problème, le serveur n’envoie pas uniquement son certificat au client lors de la prise de contact SSL, mais une chaîne de certificats de l’autorité de certification du serveur via tous les intermédiaires nécessaires pour atteindre une autorité de certification racine fiable.
pour voir à quoi cela ressemble dans la pratique, voici le courrier.Google.,com certificatechain vu par la commandeopenssls_client:
cela montre que le serveur envoie un certificat pour le courrier.Google.délivré par la CA de Thawte SGC, qui est une CA intermédiaire, et un second certificat pour la CA de Thawte SGC délivré par une CA Verisign, qui est la CA primaire approuvée par Android.
cependant, il n’est pas rare de configurer un serveur pour ne pas inclure l’autorité de certification intermédiaire nécessaire., Par exemple, voici un serveur qui peut provoquer une erreur dans les navigateurs Android etexceptions dans les applications Android:
Ce qui est intéressant à noter ici, c’est que visiter ce serveur dans la plupart des navigateurs de bureau ne provoque pas d’erreur comme une autorité de certification complètement inconnue ou un certificat de serveur auto-signé.cause. En effet, la plupart des navigateurs de bureau mettent en cache des CA intermédiaires de confiance au fil du temps. Une fois que le navigateur a visité et appris sur une autorité de certification intermédiaire à partir d’un site, il ne sera pas nécessaire que l’autorité de certification intermédiaire soit incluse dans la chaîne de certificats la prochaine fois.,
certains sites le font intentionnellement pour des serveurs web secondaires utilisés pour servir des ressources. Par exemple, ils peuvent avoir leur page HTML principale servie par un serveur avec un certificatechain complet, mais ont des serveurs pour les ressources telles que les images, CSS ou JavaScript qui n’incluent pas theCA, probablement pour économiser de la bande passante. Malheureusement, parfois, ces serveurs peuvent fournirun service web que vous essayez d’appeler à partir de votre application Android, ce qui n’est pas aussi indulgent.
Il y a deux approches pour résoudre ce problème:
- configurez le serveur pour inclure L’autorité de certification intermédiaire dans la chaîne de serveur., La plupart des CAs fournissent de la documentation sur la façon de procéder pour tous les serveurs Web courants. C’est la seule approche si vous avez besoin que le site fonctionne avec les navigateurs Android par défaut au moins via Android 4.2.
- ou, traitez l’autorité de certification intermédiaire comme toute autre autorité de certification inconnue, et créez un
TrustManagerpour lui faire confiance directement, comme cela a été fait dans les deux sections précédentes.
problèmes courants avec la vérification du nom d’hôte
comme mentionné au début de cet article,la vérification d’une connexion SSL comporte deux éléments clés., Le premierest de vérifier le certificat provient d’une source de confiance, qui était au centre de la section précédentesection. L’objectif de cette section est la deuxième partie: s’assurer que le serveur auquel vous vous adressez présente le bon certificat. Quand ce n’est pas le cas, vous verrez généralement une erreur comme celle-ci:
une des raisons pour lesquelles cela peut se produire est due à une erreur de configuration du serveur. Le serveur est configuré avec un certificat qui n’a pas de champs de nom de sujet ou de sujet alternatif qui correspondent au serveur que vous essayez d’atteindre. Il est possible d’utiliser un certificat avec de nombreux serveurs différents., Par exemple, en regardant le google.com certificat avec openssl s_client -connect google.com:443 | openssl x509 -text vous pouvez voir qu’un sujet qui prend en charge *.google.com mais aussi soumettre des noms alternatifs pour *.youtube.com,*. android.com, et d’autres. L’erreur se produit uniquement lorsque le nom du serveur auquel vous vous connectez n’est pas répertorié par le certificat comme acceptable.
Malheureusement, cela peut se produire pour une autre raison: l’hébergement virtuel. Lors du partage d’aserver pour plus d’un nom d’hôte avec HTTP, le serveur web peut indiquer à partir de la requête HTTP/1.1 quel nom d’hôte cible le client recherche., Malheureusement, cela est compliqué avechttps, car le serveur doit savoir quel certificat retourner avant de voir le HTTPrequest. Pour résoudre ce problème, des versions plus récentes de SSL, en particulier TLSv.1.0 et versions ultérieures,prend en charge L’Indication de nom de serveur(SNI), qui permet au client SSL de spécifier intendedhostname au serveur afin que le certificat approprié puisse être renvoyé.
heureusement,HttpsURLConnection supportsSNI depuis Android 2.3. Un workaroundif vous devez prendre en charge Android 2.,2 (et plus) consiste à configurer un hôte alternatif virtuel sur un port unique afin qu’il soit sans ambiguïté sur le certificat de serveur à renvoyer.
l’alternative la plus radicale consiste à remplacer HostnameVerifier par un qui n’utilise pas le nom d’hôte de votre hôte virtuel, mais celui renvoyé par le serveur par défaut.
attention: remplacerHostnameVerifierpeut être très dangereux si l’autre hôte virtuel n’est pas sous votre contrôle, car anon-pathattacker pourrait diriger le trafic vers un autre serveur à votre insu.,
Si vous êtes toujours sûr de vouloir remplacer la vérification du nom d’hôte, voici un exemple qui remplace le vérificateur pour un seul URLConnectionpar un qui vérifie toujours que le nom d’hôte est au moins sur prévu par l’application:
Mais rappelez-vous, si vous vous trouvez en train de remplacer la vérification du nom d’hôte, en particulier en raison de l’hébergement virtuel, c’est toujours très dangereux si l’autre hôte virtuel n’est pas sous votre contrôle et vous devriez trouver un hébergement alternatif arrangementqui évite ce problème.,
avertissements sur L’utilisation directe de SSLSocket
Jusqu’à présent, les exemples se sont concentrés sur HTTPS en utilisantHttpsURLConnection.Parfois, les applications doivent utiliser SSL séparément de HTTP. Par exemple, une application de messagerie peut utiliser des variantes SSL de SMTP, POP3 ou IMAP. Dans ces cas, l’application voulons utiliser des SSLSocketdirectement, de la même manière que HttpsURLConnection n’en interne.
Les techniques décrites par sofar pour traiter les problèmes de vérification de certificat s’appliquent également à SSLSocket.,En fait, lors de l’utilisation d’un custom TrustManager, ce qui est passé àHttpsURLConnection est une SSLSocketFactory.Donc, si vous avez besoin d’utiliser un TrustManager avec unSSLSocket, followthe mêmes étapes et l’utilisation de SSLSocketFactory pour créer votreSSLSocket.
attention:SSLSocket n’effectue pas la vérification du nom d’hôte. C’est à votre application d’effectuer sa propre vérification du nom d’hôte, de préférence en appelant getDefaultHostnameVerifier() avec le nom d’hôte attendu., Furtherbeware que HostnameVerifier.verify()ne lève pas d’exception en cas d’erreur mais renvoie à la place un résultat booléen que vous devez vérifier explicitement.
Voici un exemple montrant comment vous pouvez le faire. Cela montre que lors de la connexion togmail.com port 443 sans support SNI, vous recevrez un certificat formail.google.com. Ceci est prévu dans ce cas, alors vérifiez pour vous assurer que le certificat est bien pour mail.google.com:
Denylisting
SSL s’appuie fortement sur CAs pour émettre des certificats uniquement aux propriétaires de serveurs et de domaines correctement vérifiés., Dans de rares cas, les CAs sont trompés ou, dans le cas de Comodo ou DigiNotar,violés, ce qui entraîne l’émission des certificats d’un nom d’hôte à un autre que le propriétaire du serveur ou du domaine.
afin d’atténuer ce risque, Android a la possibilité d’ajouter certains certificats ou Evenwhole CAs à une liste denylist. Bien que cette liste ait été historiquement intégrée au système d’exploitation, à partir d’Android 4.2, cette liste peut être mise à jour à distance pour faire face aux futurs compromis.,
épinglage
Une application peut encore se protéger contre les certificats émis frauduleusement par atechnique connu sous le nom d’épinglage. Cela utilise essentiellement l’exemple fourni dans le cas de CA inconnu ci-dessus pour restreindre le CAs de confiance d’une application à un petit ensemble connu pour être utilisé par les serveurs de l’application. Ceci empêche le compromis de l’un des 100 autres CAs du système d’entraîner une violation du canal sécurisé des applications.
certificats clients
Cet article s’est concentré sur L’utilisateur de SSL pour sécuriser les communications avec les serveurs., SSL prend également en charge la notion de certificats clients qui permettent au serveur de valider l’identité d’aclient. Bien que dépassant le cadre de cet article, Les techniques impliquées sont similaires à specifyinga custom TrustManager.
Nogotofail: un outil de test de sécurité du trafic réseau
Nogotofail est un outil qui vous permet de confirmer facilement que vos applications sont en sécurité contre les vulnérabilités TLS / SSL connues et les erreurs de configuration. C’est un outil automatisé, puissant et évolutif pour tester les problèmes de sécurité réseau sur tout appareil dont le trafic réseau pourrait être amené à le traverser.,
Nogotofail est utile pour trois cas d’utilisation principaux:
- trouver des bogues et des vulnérabilités.
- vérifier les correctifs et surveiller les régressions.
- comprendre quelles applications et quels périphériques génèrent quel trafic.
Nogotofail fonctionne pour Android, iOS, Linux, Windows, Chrome OS, OSX, en fait tout appareil que vous utilisez pour vous connecter à Internet. Il existe un client facile à utiliser pour configurer les paramètres et recevoir des notifications sur Android et Linux, ainsi que le moteur d’attaque lui-même qui peut être déployé en tant que routeur, serveur VPN ou proxy.