Rendre NSURLCredential forTrust permanent dans le trousseau

Je réponds à un défi où la protectionSpace.authenticationMethod == "NSURLAuthenticationMethodServerTrust".Rendre NSURLCredential forTrust permanent dans le trousseau

Je crée les informations d'identification pour Trust et l'ajoute au NSURLCredentialStorage.

Mais chaque fois que je redémarre l'application (en cours d'exécution dans le simulateur), je reçois à nouveau le défi. Au cours d'une session, elle ne demande qu'une seule fois car j'ai ajouté les informations d'identification forTrust au stockage. En outre, je peux voir que protectionSpace dans le stockage NSURLCredential. Mais quand je redémarre l'application c'est parti et je dois à nouveau faire confiance au serveur.

Le serveur utilise un certificat auto-signé et je suis accès via HTTPS

S'il vous plaît aider!

Merci d'avance.

Source

2014-09-12 Rob

"utilise un certificat auto-signé". Effectuez-vous une évaluation personnalisée de l'approbation du serveur, comme indiqué dans la note technique 2232? https://developer.apple.com/library/mac/technotes/tn2232/_index.html#//apple_ref/doc/uid/DTS40012884 – quellish

Je donne à l'utilisateur une option pour faire confiance au serveur source ou non. S'ils y croient, je crée les informations d'identification pour Trust, l'ajoute à NSCredentialStorage et en fait le fichier par défaut pour cet espace de protection. Je n'arrive tout simplement pas à trouver comment rendre cela permanent afin que la question de confiance ne se pose pas chaque fois qu'ils lancent l'application (après que celle-ci soit sortie de mémoire) – Rob

Oui, vous devez faire une évaluation de confiance personnalisée et stocker * cela *, c'est-à-dire que votre cert auto-signé doit être une ancre dans la confiance que vous stockez. – quellish

Technical Note TN2232: HTTPS Server Trust Evaluation expose les meilleures pratiques recommandées pour l'utilisation d'un certificat auto-signé dans une application iOS. L'approche recommandée consiste à implémenter l'évaluation de confiance TLS comme l'épinglage SSL: approuver un certificat spécifique ou une clé publique. La mise en œuvre a été démontrée dans la session 2014 de la WWDC Building Apps for Enterprise and Education. Malheureusement, le code pour l'épinglage SSL n'a pas été publié comme exemple de code, et il n'est pas non plus disponible dans les diapositives - uniquement la vidéo. Le processus d'évaluation de l'approbation du serveur est bien expliqué dans la session.

Cela ne résout pas le problème de la persistance de l'approbation du serveur évalué. L'approbation de serveur fournie par le défi d'authentification représente l'état de la transaction SSL et, en tant que telle, ne peut pas réellement être persistante de manière significative. C'est pourquoi le constructeur de NSURLCredential pour utiliser SecTrustRef n'a pas de paramètre pour NSURLCredentialPersistence: l'approbation du serveur doit être par session ou transaction. Cela dit, le système de chargement d'URL permet la gestion par défaut de l'évaluation de la confiance du serveur SSL/TLS. Normalement, pour les connexions HTTPS, vous n'avez pas besoin d'implémenter un gestionnaire d'authentification pour NSURLAuthenticationMethodServerTrust. Si l'évaluation de l'approbation par défaut échouait, votre connexion échouait avec quelques erreurs familières - c'est ce qui se passe lors de l'utilisation d'un certificat auto-signé, car le certificat n'est pas approuvé. Il est peut-être possible d'ajouter votre certificat approuvé, auto-signé aux ancres de confiance de l'application (comme vous le faites dans l'évaluation de confiance pour l'épinglage SSL) et la gestion par défaut "fonctionnera" à partir de ce point. Malheureusement, je n'ai pas actuellement d'environnement de test dans lequel je peux tester cela.

Source

2014-09-13 06:35:26 quellish

Ce que j'ai fait dans le passé, pour le meilleur ou pour le pire, c'est quand je reçois le défi de confiance, j'invite l'utilisateur à faire confiance au serveur ou non. S'ils font confiance au serveur, je stocke le protectionSpace dans ma base de données d'application comme approuvé, puis quand je vois le défi de confiance, je peux le comparer à ma liste de serveurs de confiance et s'il y a une correspondance je crée l'information d'identification procéder sans autre intervention de l'utilisateur requise.Je donne également à l'utilisateur la possibilité de retirer cette confiance de l'application afin que la prochaine fois l'application demande à nouveau. – Rob

@quellish Je vois le comportement opposé à ce que vous mentionnez ici. Lorsque je crée une tâche de données 'NSURLSession', je n'enregistre pas les informations d'identification (ou je ne les rends pas persistantes) car je dois contester toutes les requêtes HTTPS dans mon application. Cependant, la méthode déléguée 'URLSession: didReceiveChallenge: completionHandler:' est seulement appelée pour la première requête, ce qui me dit que les informations d'identification * sont * persistantes quelque part, je ne sais pas où. – paulvs

@paulvs, il n'y a qu'un seul "lieu" où ils peuvent être persistés: NSURLCredentialStorage. Est-ce que le défi ne se produit que sur la première demande, ou la première demande pour un * hôte * donné? Le second scénario est commun et peut être affecté par plusieurs choses, et peut * sembler * se comporter contrairement à la documentation selon la façon dont vous avez implémenté le délégué, et s'il s'agit d'un délégué de session, d'un délégué de tâche et d'une instance différente. chaque demande. – quellish

Rendre NSURLCredential forTrust permanent dans le trousseau

Répondre

Questions connexes