Discussion :

[Claythest]

Bonjour tout le monde

J'ai un serveur JBoss via lequel je souhaite me connecter de manière sécurisée (SSL). J'ai configuré le tout et tout semble fonctionner.

Seulement, j'aimerai en comprendre d'avantage sur le fonctionnement du SSL afin de savoir qu'est-ce qu'il ne faut pas faire pour ne pas se faire pirater même en utilisant SSL ; quelles sont les manips à ne pas faire.

Il y a un détail sur lequel j'aimerai recevoir des explications : le keystore.

Donc SSL utilise pour fonctionner une paire de clé (une privée et une publique) qui sont stockées dans le keystore.

1ere question : comment ces clés sont-elles générées ? Sont-elles générées d'une manière aléatoire au moment de la création du keystore (avec keytool) ou calculées en fonction des paramètres d'entrée ? Si on passe les mêmes paramètres à keytool, est-il possible de générer le même keystore (et donc les mêmes clés) ?

2eme question : Si je dispose du keystore et que je "sniffe" une communication SSL, puis-je en décoder le contenu ?

Merci d'avance pour vos réponses

[Claythest]

Bon, il semblerait que la réponse à la première question soit que le keystore est généré de manière aléatoire, car 2 certificats contenant un keystore généré avec les mêmes paramètres n'ont pas la même "Empreinte numérique". J'en déduit que les clés doivent être différentes.

La réponse à ma 2ème question semble être oui...


Mais alors je ne comprends pas tout (et vous l'aurez deviné )... Quelle est la différence entre un keystore et un truststore ? Le truststore peut-il être échangé sans soucis particulier ? Que contient-il exactement ?

[Invité]

Bon, il semblerait que la réponse à la première question soit que le keystore est généré de manière aléatoire, car 2 certificats contenant un keystore généré avec les mêmes paramètres n'ont pas la même "Empreinte numérique". J'en déduit que les clés doivent être différentes.

La réponse à ma 2ème question semble être oui...


Mais alors je ne comprends pas tout (et vous l'aurez deviné )... Quelle est la différence entre un keystore et un truststore ? Le truststore peut-il être échangé sans soucis particulier ? Que contient-il exactement ?

Salut,

SSL est basé sur la cryptographie à clef publique et les PKI (Public Key Infrastructure). La pièce maîtresse des PKI est le certificat, Qu'est-ce qu'un certificat ? C#est simplement un fichier qui contient une clef publique et l'identité de son propriétaire, le tout signé pour éviter d'être falsifié. Je fais en gros mais je t'invite à te renseigner plus avant sur le sujet si tu veux en savoir plus.
Bref un certificat peut être échangé avec n'importe qui et c'est son but.
Un certificat SSL dit : salut je suis la clef publique et mon propriétaire est www.plop.org.
Qu'est-ce qu'un keystore ? C'est simplement comme son nom l'indique un magasin de clefs (publiques et/ou privées). En Java tu les utilises pour crypter, décrypter grâce à des algortihmes tel RSA. Et un truststore ? Ben c'est un keystore qui contient les clefs publiques des hôtes et/ou CA (Certification Authority) de confiance. Par exemple si tu veux faire une connexion SSL avec www.plop.org, il te faudra faire confiance à ce certificat (ou à son signataire, ou au signataire du signataire, etc etc...), c'est ce que l'on appelle la chaine de certificats.

Donc en résumé : un client doit avoir dans son truststore de quoi faire confiance au server. Et le server doit avoir dans son keystore la clef privée permettant de signer ce qu'il envoit, et l''échange de la clef de session SSL (Mais je vais pas décrire le protocole SSL ici)

Pour corriger une erreur : un certificat ne contient aucune keystore, mais peut être importé dans un keystore. l'outil keytools génère des clefs aléatoirement quand tu le lui demandes et permet d'exporter la clef publique dans un certificat, ou d'importer des certificats pour utiliser sa clef publique et/ou lui faire confiance.

Alors ton keystore server qui contient la clef privée doit être sécurisé par un mot de passe, car quiconque connaissant la clef privée pourra:
1/ tenter de se faire passer pour ton server -> pas glop
2/ décrypter lors de l'échange de clef à l'établissement de la session SSL la clef de session et donc par la suite décrypter tout conversation -> pas glop du tout non plus
3/ signer des messages se revendiquant de ton server et donc à qui tu feras confiance (ce qui revient à 1 en fait, mais jamais deux points sans trois)

Les enjeux derrières tout cela, sur la nécessité de bien gérer sa PKI (avec CRL notamment) avec ses certificats pour une diffusion à grande échelle, je ne le discuterai pas ici, mais je ne saurai que te conseiller de jeter un oeil là dessus

Amsue toi bien

[Claythest]

Merci énormément pour toutes ces explications !

[...]
Donc en résumé : un client doit avoir dans son truststore de quoi faire confiance au server.[...]

Est-ce que si je rends mon truststore librement téléchargeable sur mon serveur pour que le client le télécharge et ainsi "l'ai dans son truststore" est une manipulation correcte ? Le seul risque que j'y vois, c'est que n'importe qui pourra communiquer avec le serveur... Mais c'est un peu ce que je veux car en fait, je souhaite juste crypter les communications entre mes clients (Java Web Start) et mon Serveur (JBoss). Donc est-ce une bonne méthode que de faire télécharger le trustore par mon client Java Web Start pour ensuite l'affecter à la propriété "javax.net.ssl.trustStore" et donc pouvoir me connecter au serveur avec SSL ? (oui l'architecture est un peu compliqué, mais c'est le prix à payer pour satisfaire les clients )

Le keystore lui, reste sur mon serveur...

[Invité]

Pourquoi ne pas mettre le truststore dans ton jar et le charger au démarrage de ton application ? Comme ça le client n'a rien à faire, c'est transparent, et ton application peut communiquer avec ton server. Tu peux t'inspirer de ce lien.

Bon courage

[Claythest]

Je n'y avais pas pensé !

Merci énormément pour ton aide !

Je pense avoir compris maintenant beaucoup de choses. Place à la pratique et à différents tests pour m'en assurer



EDIT : j'ai parlé trop vite :
En fait, je ne peux pas le mettre dans le jar, car comme je vais distribuer aussi mes serveurs, il sera plus sage de générer le keystore et donc le truststore à chaque installation (pour ne pas que tous les serveurs des différents clients aient le même keystore)... Donc il ne pourra être inclu dans le jar. Néanmoins, ta réponse m'a fait comprendre que cette technique (le rendre téléchargeable) n'était pas absurde