Discussion :

[Fladnag]

Bonjour,

J'ai récemment vu un site "serieux" proposer une authentification sur son espace membre depuis sa page d'accueil, puis, une fois authentifié, on passe en HTTPS... mais la page d'accueil étant en HTTP normal, cela ne voudrait il pas dire que les login et pass circulent "en clair" sur le réseau sans être chiffrées ?

En résumé, vaux t'il mieux faire :
* [HTTP] Formulaire de login qui renvoie vers une page en HTTPS
* [HTTPS] Actions chiffrées dans la partie membre

ou :

* [HTTP] Lien vers formulaire de login en HTTPS
* [HTTPS] Formulaire de login qui va envoyer le couple login/pass de maniere chiffré
* [HTTPS] Actions chiffrées

[tiyolx]

Bonjour,

L'envoi du login doit être réalisé à partir d'une page https (comme gmail) et après tout dépend du type d'action que tu as derrière cette authentification.

De toute façon si ton hébergement a un SSL je te conseil de mettre la page de login et le reste de ton espace privé en HTTPS.

Bon courage.

[Fladnag]

merci, c'est bien ce qu'il me semblait ;o)

ce n'est pas pour un site que je développe, mais c'est pour envoyer un mail aux gens de ce site "serieux" pour leur dire que c'est un petit peu n'importe quoi (il n'y a pas que ca comme probleme, mais ca permet d'ajouter un point a l'argumentation ;o)

[oxilab]

Bonjour,

Il est nécessaire de bien distinguer les choses.
peut importe le protocole nécessaire à l'aquisition de la page.
Elle est indépendante de l'envoie des identifiants.
Ce qui compte, ce n'est donc pas le protocole pour l'aquisition du formulaire.
Ce qui compte, c'est le protocole du "DESTINATAIRE" du formulaire ou "action"
Si le serveur sur lequel on "post" les infos du formulaire est un serveur accessible via https, alors toutes les infors seront chiffrés.

https veut dire http over ssl.
Autrement dit, aucune information , aucun protocol http ne circule tant que la couche ssl n'est pas validé. Une fois qu'elle l'est on véhicule le protocole http dedans. Autrement dit on "post" les infos du formulaire sur le serveur en question.

Voila.

Laurent

[Fladnag]

ok, donc avec un formulaire, présent sur une page en HTTP mais avec un action="https..." on aura quelque chose comme :

* Le navigateur "voit" que le protocole destination est en https
* Le navigateur contacte l'adresse destination pour passer en SSL (échange de clé, etc...)
* Le navigateur passe en HTTPS et envoie les données du formulaire (en POST) via HTTPS.

C'est bien cela ? Le navigateur ne transmet AUCUNE donnée du formulaire en clair ?

[tit_nouveau]

ok, donc avec un formulaire, présent sur une page en HTTP mais avec un action="https..." on aura quelque chose comme :

* Le navigateur "voit" que le protocole destination est en https
* Le navigateur contacte l'adresse destination pour passer en SSL (échange de clé, etc...)
* Le navigateur passe en HTTPS et envoie les données du formulaire (en POST) via HTTPS.

C'est bien cela ? Le navigateur ne transmet AUCUNE donnée du formulaire en clair ?

Bonjour,

Je me pose aussi des questions quant à ssl. Si l'on suit ce raisonnement, l'attaque "man in the middle" est impossible. Puisque les informations sont chiffrées de la source jusqu'à la destination (qui utilise sa clé privée pour déchiffrer).
Mais avant que le navigateur chiffre le message, est il possible que le contenu puisse changer ?
Par exemple, je remplis une commande (adresse de livraison, etc...). Et juste quand je paye, avant que je clique sur "ok" pour le paiement par carte de crédit, l'adresse de livraison est changée. Disons que celui qui fait ce type de changement est juste là pour envoyer la livraison ailleurs pour dégrader le service.
Est ce que ce cas peut arriver au niveau du navigateur ?