Discussion :

[Nickonet]

Salut tout le monde, je suis entrain de tester le tutoriel login sur un webservice de develppez et je me demandais s'il y avait oyen d'envoyer son login mdp avec du ssl plutot que des POST comme ici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
								ArrayList<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>();
 
									nameValuePairs.add(new BasicNameValuePair("pwd", etPwdConf.getText().toString()));
 
 
									try {
 
										HttpClient httpclient = new DefaultHttpClient();
 
										HttpPost httppost = new HttpPost(MenuPrincipal.ressources.getString(R.string.serveraddress)+"/subscribe.php");
 
										httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs));
 
										HttpResponse response = httpclient.execute(httppost);

[Invité]

Bonjour,

Le fait que le message soit sécurisé (SSL) ne dépend pas du type de requête http (POST).

Si l'URL du service est préfixée par "https://" HttpClient va automatiquement encrypter le message http.

[Largo13]

Je rebondi sur la question car elle me semble intéressante et aborde une problématique à laquelle je vais être confronté rapidement :-)

Quid de la gestion d'un certificat ? Car ajouter un S à http ne suffit pas ...
Quid d'une connexion à l'aide du protocol handshake SSL

(Mes questions sont vagues et larges car je m'intéresse au sujet dans sa globalité avant de choisir une solution plutôt qu'une autre).

Bien à vous.

Lionel

[Invité]

Bonjour,

Quid de la gestion d'un certificat ? Car ajouter un S à http ne suffit pas ...
Quid d'une connexion à l'aide du protocol handshake SSL

L'ajout du S suffira du côté client.
L'implémentation HttpClient gère automatiquement la négociation de la transaction SSL avec le serveur.

Côté serveur, bah tout dépend du serveur http (apache, IIS, ...). Il faut lire la documentation.

[nicroman]

HTTPS = HTTP over SSL

SSL = Secured Socket Layer, c'est à dire un socket TCP sécurisé...

Le handshake se fait avant même de commencer une transaction HTTP (à l'ouverture de session TCP quoi !)

Quand le client voit "https://..." il sait qu'il va devoir faire du HTTP non pas sur un socket "TCP" de base (port 80 par défaut), mais sur un socket "SSL" (port 443 par défaut). Le reste (protocole HTTP) est absolument inchangé, que ce soit coté serveur ou coté client...

Le même code PHP, le même code client...
Il faut juste que le client "sache" ouvrir une connexion SSL (c'est le cas de DefaultHttpClient), et que le serveur "sache" écouter des connexions SSL (à voir la documentation du serveur).
Attention, du fait du handshake initial, il faut que le certificat (attaché à un nom de domaine) et l'adresse IP du serveur (utilisé pour la connexion SSL) soient en phase => 1 certificat = 1 IP.

[Nickonet]

Merci de vos réponses ! Et est il préférable de crypter le mdp en md5 avant de l'envoyer au serveur ou bien le crypter une fois sur le serveur pour l'enregistrer dans la base de données ?

[Arno5788]

Bonjour,



L'ajout du S suffira du côté client.
L'implémentation HttpClient gère automatiquement la négociation de la transaction SSL avec le serveur.

Côté serveur, bah tout dépend du serveur http (apache, IIS, ...). Il faut lire la documentation.

Je ne suis pas tout à fait d'accord, dans le cas d'un certificat auto-signé il faudra le gérer aussi côté client.

[nicroman]

Merci de vos réponses ! Et est il préférable de crypter le mdp en md5 avant de l'envoyer au serveur ou bien le crypter une fois sur le serveur pour l'enregistrer dans la base de données ?

Le cryptage en md5 rajoute une sécurité du coté serveur: Même si le serveur est compromis, les mots de passe sont sécurisés...
Attention bien utiliser un md5+salt, sinon, rien n'est sur (il existe des 'rainbow table' pour 'cracker' le md5).
Par contre, il a pour inconvénient l'impossibilité d'envoyer son mdp à l'utilisateur, la fonction "forget password" devient alors "reset password".