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 ?

[Fladnag]

alors, déjà, il faut savoir que l'attaque "man in the middle" est TOUJOURS possible.
Les sessions HTTPS demandent l'échange de clés publiques. Si tu interceptes les 2 clés publiques de chacun des destinataires, tu pourra dechiffrer/rechiffrer le message de maniere totalement transparente.

Si tu veux éviter le man in the middle, il faut que les clés de chacun soit échangés par un autre moyen et non interceptables (de main en main, via le courrier (et encore ^^)). Bref, il faut que la communication soit cryptée dès le début, et qu'il n'y ait pas le moindre octet ou clé qui soit envoyé "en clair" avant la transaction sécurisée.

Ensuite, oui, ce que tu dis serais théoriquement faisable, mais cela voudrait dire que ta machine est infectée par un trojan ou un virus... dans ce cas là il a aussi acces a ta clé publique ET a ta clé privée et peut générer n'importe quel message vers n'importe quel destinataire.

[tit_nouveau]

Même avec les certificats ?

[Fladnag]

Avec les certificats tu peux t'assurer que l'IP avec qui tu discutes correspond bien a tel site. Tu ne peux en effet pas faire du man in the middle dans ce cas là (a moins de casser le certificat, mais bon ^^)

Cependant, il faut bien voir que cela ne marche QUE pour les certificats déjà installés sur ta machine. Donc hors de propos pour le développement d'un site perso ou semi professionnel.

Bref, valable uniquement pour les grosses entreprises qui ont de l'argent a mettre là dedans...

Dans le cas d'un site sécurisé dont tu n'a pas le certificat, il va te proposer de l'installer avec une fenetre de popup du genre "Voulez vous faire confiance...", etc...
Si tu as un man in the middle a ce moment là, je pense qu'il devrait etre possible d'installer un faux certificat correspondant au serveur pirate, le pirate se faisant passer pour toi aupres du vrai serveur, et se faisant passer pour le serveur aupres de toi.

[tit_nouveau]

Salut !

Cela ne marche que pour les certificats installés sur ma machine ? Tu parles des certificats des autorités de certifications n'est ce pas ?
Lorsque le navigateur me sort la petite fenêtre, c'est lorsque le certificat du serveur que je visite a été auto signé (ou signé par une autorité inconnue). Je pense que c'est de ça dont tu parles. Et dans ce cas, si t'acceptes le certificat c'est que tu acceptes de faire confiance au serveur (bien qu'aucune autorité connue n'a signé le certificat transmis) : et donc c'est à tes risques et périls.

A moins de casser un certificat ? Le certificat a été signée avec la clé privée d'une autorité connue. Et les navigateurs ont les clés publiques de ces autorités.

Eventuellement, on peut obtenir le certificat d'un site signé par une autorité. Mais après ?
Imaginons qu'on soit le man in the middle et qu'on ait réussi à faire ce qu'on a parlé plus haut : on se fait passer pour le serveur.
Lorsque firefox va essayer d'obtenir le certificat auprès de l'AC, imaginons qu'on essaie encore le coup du man in the middle et que l'on intercepte la requête et qu'on construise un certificat avec nos infos à lui renvoyer : on va le signer avec quelle clé privée ?

On peut encore bien hacher le certificat puisqu'on a la fonction de hachage (les navigateurs l'ont, nous aussi) mais après ? (d'ailleurs quelle est l'utilité de ce hachage)
A moins d'avoir pu piraté le client et d'avoir substitué la clé publique de l'autorité par la notre... ?!

Comment sont donc stockées les clés publiques chez le client ? Est il possible de les substituer ?Il est possible d'en importer soit même sur firefox donc il est bien possible de me faire passer pour une autorité ? (oublions les accès physique à la machine cliente : sinon on s'en sort plus du tout)

Qu'est ce que t'en penses ?

[Fladnag]

Bon, déjà il faut savoir qu'on ne peux pas créer un message chiffré avec une clé publique.
Le concept des deux clés est simple :
La clé publique (CP) et la clé privée (cp) servent a chiffrer et déchiffrer un message. Tout ce qui a été chiffré avec CP peut etre déchiffré avec cp, et tout ce qui a été chiffré avec cp peut etre déchiffré avec CP.

* A veux envoyer un message a B
* A et B s'échangent CP(A) et CP(B)
* A applique une fonction de hashage sur le message a envoyer et chiffre le resultat avec cp(A) : Cela donne h(A)
* A chiffre le message avec CP(B) : Cela donne M(A)
* A envoie h(A) et M(A) a B
* B recoit le M(A) et déchiffre le message avec sa clé privée cp(B) => B peut lire le message de A.
* B calcule la fonction de hashage sur le message en clair.
* B déchiffre le hashage h(A) avec la clé publique de A : CP(A) et compare le hashage avec celui calculé juste avant. B sait alors :
- Le contenu du message
- Que le message vient de A
- Que le message n'a pas été altéré

Dans le cas d'un man in the middle (C), tu peux toujours te mettre entre les deux si tu connais les deux clés publiques ET que tu arrives a donner ta clé publique au serveur et au client en se faisant passer pour l'autre.
A<->C<->B

Dans le cas d'un certificat, cela n'est en général pas possible car B (client) va détecter que la personne avec qui il communique n'est pas son vrai interlocuteur.

Changer les clés publiques sur UNE machine ne sert a rien, car les deux autorités ne pourront plus communiquer. Ce que tu peux faire par contre c'est ajouter le "faux" certificat du man in the middle.

Casser un certificat doit etre théoriquement possible... si tu as un parc de machine de la puissance de google ou de microsoft, ou acces a un super calculateur pendant quelques mois... sinon c'est pas la peine ^^

[tit_nouveau]

Salut,

J'ai pas pu passer depuis un certain temps. Merci pour tes explications : elles sont claires.
J'avais posté une question mais j'ai trouvé ma réponse. Elle concernait ton exemple : l'existence de deux paires de clés (pour le serveur et le client). Ca voulait dire que le serveur voulait identifier le client aussi. Mais dans le cas d'un site public sécurisé ?
Je me demandais si les navigateurs avait eux aussi des clés. Mais j'ai lu qu'en fait, ils en généraient une aléatoirement et qu'ils la chiffraient avec la clé publique du serveur (qu'ils avaient préalablement authentifié grâce au certificat).
Donc j'ai ma réponse.

Comment se passe la partie authentification du certificats auprès du CA par le client ?

[Fladnag]

un certificat contient en gros 2 valeurs :
* La clé publique de la personne ou de l'entreprise qui a émis le certificat
* Les dates de validité du certificat

Il suffit donc de comparer la clé publique que l'on nous renvoie et la clé contenue dans le certificat pour s'assurer que c'est bien avec le bon site que l'on communique.

[tit_nouveau]

Donc, il y a non seulement, dans le certificat, des informations pour identifier l'autorité de certification (sa clé publique) mais aussi la clé publique du serveur.
L'authentification de l'autorité de certification se fait par comparaison de la clé publique que l'on a reçu à l'intérieur du certificat et la clé qui a été originalement importé par le navigateur : c'est ça ?
Je suis lourd : désolé. Je suis un peu parano pas au point d'avoir un sécurité à toute épreuve (car ça n'existe pas) mais pour comprendre les différentes barrières mises en place pour rendre le piratage plus compliqué.
Je te remercie pour tes explications sur la partie client <-> serveur. C'est clair comme de l'eau de roche maintenant. Un gros merci.