Communication sécurisée entre le serveur django et l'application iphone

Question

J'écris une application pour iPhone qui doit envoyer de petites informations (deux chaînes de moins de 128 caractères chacune, à la fois, ce qui n'arrive pas trop souvent) à une application iPhone. serveur lorsque les utilisateurs interagissent avec lui. Je voudrais que cette information reste confidentielle, donc je pense à une sorte de cryptage ou une connexion sécurisée serait nécessaire.

Ma question concerne le côté serveur des choses. Le serveur avec lequel l'application iPhone doit communiquer est écrit en django et s'exécute sur lighttpd. Quelle est la manière la plus appropriée (ou ce qui est un moyen standard) de le faire. Je pensais https, que je sais sur l'iPhone, je peux utiliser ASIHTTPRequest pour faire une demande POST, mais je ne sais pas ce qu'il faut du côté serveur. Ai-je besoin d'un certificat? Comment les données sont-elles cryptées/sécurisées? Y a-t-il des modules django pour vous aider? Dois-je faire quelque chose pour configurer lighttpd?

Quelque chose comme xml-rpc ou json-rpc serait-il plus simple? Est-il possible de sécuriser une telle communication? À quel niveau cela se produirait-il?

Toute aide serait grandement appréciée.

Answer 1

L'utilisation de xml-rpc ou json-rpc est seulement un moyen d'encapsuler vos données dans un formulaire facile à transporter. Votre application iPhone peut transformer les données Objective C en utilisant l'un de ces formats et votre application serveur Django peut transformer les données en objets Python.

Ni l'un ni l'autre n'ont quoi que ce soit à voir avec la sécurité.

La création d'une connexion HTTPS (SSL) crypte toutes les communications entre le client (iPhone) et le serveur (Django). Vous devrez obtenir un certificat pour le serveur. Cela indique au client que le serveur est ce qu'il prétend être. Votre prochaine ligne de recherche dans ce chemin devrait être sur la façon de configurer lighttpd pour gérer le trafic SSL. Une fois que lighttpd a négocié la communication SSL, votre application Django fonctionnera comme pour le trafic non sécurisé.

Ceci est votre meilleur choix.

Si, pour une raison quelconque, vous ne souhaitez pas utiliser SSL, vous pouvez trouver les bibliothèques de chiffrement fort pour les deux extrémités de la communication. L'application iPhone pourrait crypter les données, les envoyer via une connexion HTTP et l'application Django pourrait les déchiffrer. Par exemple, la bibliothèque Python pycrypto implémente des chiffrements de chiffrement forts tels que AES et Blowfish. Vous pourriez être en mesure de trouver une mise en œuvre d'un de ces chiffrements écrit en Objective C.

Avez-vous remarqué que cela devient de plus en plus complexe?

Optez pour SSL. C'est la façon dont la sécurité est faite pour la communication basée sur HTTP.

Answer 2

Hmm on dirait que c'est peut-être ce que vous recherchez, l'avez-vous vu?

Setting up SSL for Lighttpd/Django

Si je lis ce droit, cette configuration permet à votre serveur pour répondre https et requêtes http (?) Ensuite, si votre application entière ne va pas être https il y a ce SSL Middleware pour aider à configurer des chemins comme SSL et d'autres non.

Answer 3

Si vous utilisez https (SSL) côté serveur, cela ne devrait pas poser de problème si vous utilisez XML-RPC ou JSON-RPC. Toutes les données que vous transférez seront cryptées et sécurisées. Je ne peux parler qu'à partir de notre application Rails et de nginx. J'ai acheté un certificat SSL de GoDaddy (très bon marché) et nginx est configuré pour crypter le contenu (Rails ne le fait pas lui-même) à la volée quand il l'envoie. Sur l'iPhone ASIHTTPRequest sera responsable de déchiffrer les données. Toutes les autres couches ne devraient pas être concernées par le cryptage, vous pouvez envoyer tout ce que vous voulez.

Vous pouvez également utiliser un certificat auto-signé. Nous avons décidé d'utiliser GoDaddy car nous utilisons également le certificat SSL pour les navigateurs standards, et ceux-ci affichent un message d'avertissement à l'utilisateur s'il rencontre un certificat auto-signé, ce qui effraie les gens.