Discussion :

[Hyt3k]

Hello tous,

Tout chemin commence par un pas, dit-on. Je fais mes premiers pas en secu. C est un plaisir mais là je bute.
Par manque de savoir, de culture, de pratique, etc.

Alors voilà le bord3l : J'ai 2 serveurs qui se parlent, Brian et SanAntonio.
Appelons les B. et SA.

SA a plein de documents top secrets chez lui. Cryptés. Et une clé pour décrypter (une clé symétrique).
B. et SA sont connecté au Net.
B a besoin de certains docs.

Mon systeme tourne comme ça (attention nøøb) :
1. B se crée 2 clés (public, privée)
2. B envoie à SA : "tiens voici ma clé publique, envoi moi stp le document '3337' ". (il envoie ca en SSL, ghistoire qu on voit pas sa clé en clair...)
3. SA prend la clé publique de B, SA s en sert pour chiffrer sa clé symétrique à lui, celle qui sert à déchiffrer les docs secrets.
4. SA envoit donc sa clé - celle qui décrypt les docs - sa clé, chiffrée avec la clé de Brian. SA ajoute le doc 3337 à l envoi.
5. Brian recoit ça, il déchiffre avec sa clé privée. Il a maintenant la clé de SA pour déchiffrer le doc 3337.

(Inutile de dire que Brian is in the kitchen, pendant tout ce temps. ok je sors)

Bon et là je me dis : et n'importe qui peut se faire passer pour Brian non ?
Tu requête avec une clé publique et c est banko ?
Je suis largué à ce stade.

Si vous pouvez m aider, je vous aime p***

[JayGr]

Hello,

Pour moi le fonctionnement est bon. Pour plus de détails sur ce genre d'architecture tu peux chercher "PKI architecture" sur ton moteur de recherche favoris.
Même si je pense qu'un seul chiffrement sur le renvoi du doc avec la clé publique de Bryan suffirait.

Et n'importe qui peut se faire passer pour Brian non ?

Oui mais seul Bryan peut déchiffrer puisque c'est le seul à avoir la clé privée associée à la clé publique.

Tu requête avec une clé publique et c est banko ?

Non. Il faut que tu ailles voir du côté de la signature des clés. Le chiffrement c'est pour cacher la signature pour prouver qui tu es.

@+

[Hyt3k]

Merci JayGr,

Depuis, et après avoir retourner la question dans tous les sens,
je me suis rendu à la conclusion suivante :
ce que je fais/vise, finalement, c est un VPN.

Go pour OpenVPN.

Je rajoute un mot de passe "OTP" pour les clients
(One Time Password) afin de m assurer doublement de leur authenticité.

NB :

Citation Envoyé par Hyt3k Voir le message
Et n'importe qui peut se faire passer pour Brian non ?

JayGr : Oui mais seul Bryan peut déchiffrer puisque c'est le seul à avoir la clé privée associée à la clé publique.

Oui mais justement.
Seul l emetteur de la clé publique peut déchiffrer mais rien n assure que cet emetteur == Brian,
ca peut etre n importe qui (Raphael le hackeur, par exemple).

Du coup le VPN, qui gere deja le cryptage des echanges, gere aussi l authentification des clients.
(si j ai bien compris).

[BufferBob]

1. B se crée 2 clés (public, privée)
2. B envoie à SA : "tiens voici ma clé publique, envoi moi stp le document '3337' ". (il envoie ca en SSL, ghistoire qu on voit pas sa clé en clair...)
3. SA prend la clé publique de B, SA s en sert pour chiffrer sa clé symétrique à lui, celle qui sert à déchiffrer les docs secrets.
4. SA envoit donc sa clé - celle qui décrypt les docs - sa clé, chiffrée avec la clé de Brian. SA ajoute le doc 3337 à l envoi.
5. Brian recoit ça, il déchiffre avec sa clé privée. Il a maintenant la clé de SA pour déchiffrer le doc 3337.

euh non pas vraiment, B n'envoie pas sa clé publique à SA, SA la possède déjà, c'est le principe quand on utilise ssh par exemple d'aller mettre sa clé publique explicitement dans le fichier authorized_keys

pour dire "envoi moi le document 1337" à SA, B chiffre son message avec sa clé privée, et SA qui détient la clé privée sera en mesure de le déchiffrer, SA pourra répondre à B en chiffrant ses propres messages-réponses avec la clé publique de B, et seul B sera en mesure de les déchiffrer grâce à sa clé privée
une fois que tout ça est établi, c'est un échange standard entre deux applications distantes, donc ça dépend du protocole (FTP, HTTP, WebDAV etc.) pour récupérer ledit fichier

quant à SSL c'est un protocole qui permet aux deux machines distantes de se mettre d'accord sur les algorithmes de chiffrement à utiliser, et qui est censé assurer l'authentification du serveur, la confidentialité (personne n'a lu le message sur le chemin) et l'intégrité des données échangées (personne n'a modifié le message en cours de route)

effectivement ce que tu cherches est de manières plus générale une connexion chiffrée, de manière ponctuelle (open)ssh fait donc très bien l'affaire, un serveur web avec du HTTPS également, la principale différence étant qu'un VPN crée une carte réseau virtuelle (en clair avec ssh ou https on se connecte sur un port précis, avec un vpn on peut accéder n'importe quel port de la machine en face puisqu'on fait causer 2 interfaces réseau)

edit:

Seul l emetteur de la clé publique peut déchiffrer mais rien n assure que cet emetteur == Brian,
ca peut etre n importe qui (Raphael le hackeur, par exemple).
Du coup le VPN, qui gere deja le cryptage des echanges, gere aussi l authentification des clients.

oui c'est vrai, pour la raison simple que tu dois justement configurer pas uniquement le serveur, mais aussi le client vpn avec le certificat émis par le serveur (ou l'autorité de certification pour être précis mais peu importe ici), c'est précisément le cas de HTTPS en fait, n'importe qui (n'importe quel navigateur) peut se connecter sur un site -dit- sécurisé, on est assuré qu'on est sur le bon serveur, que la communication ne pourra pas être lue ou modifiée, mais le client peut-être n'importe qui, note que même avec HTTPS ça peut se restreindre celà dit, car le navigateur a lui aussi un certificat client comme dans le vpn, la différence étant que le serveur "laisse passer" n'importe qui, en configurant un peu habilement le serveur web et le navigateur on peut parvenir au même résultat (c'est le cas des impôts en ligne par exemple)

[Hyt3k]

pour dire "envoi moi le document 1337" à SA, B chiffre son message avec sa clé privée, et SA qui détient la clé privée sera en mesure de le déchiffrer, SA pourra répondre à B en chiffrant ses propres messages-réponses avec la clé publique de B, et seul B sera en mesure de les déchiffrer grâce à sa clé privée

Merci. Très clair. Cf Bijectivité & http://fr.wikipedia.org/wiki/Cryptog...ym%C3%A9trique

effectivement ce que tu cherches est de manières plus générale une connexion chiffrée, de manière ponctuelle (open)ssh fait donc très bien l'affaire, un serveur web avec du HTTPS également, la principale différence étant qu'un VPN crée une carte réseau virtuelle (en clair avec ssh ou https on se connecte sur un port précis, avec un vpn on peut accéder n'importe quel port de la machine en face puisqu'on fait causer 2 interfaces réseau)

Les échanges seront fréquents, au moins 1x / semaine pour 100 clients.
Par contre j e n avais pas noté cet aspect du VPN : pas de restriction de port...

oui c'est vrai, pour la raison simple que tu dois justement configurer pas uniquement le serveur, mais aussi le client vpn avec le certificat émis par le serveur

Indeed, je vois ça dans le tuto OpenVPN : http://doc.ubuntu-fr.org/openvpn

Merci BufferBob.

A ce stade, yapluka.
Je me questionne encore sur un point : comment peut on s'incruster dans un VPN ?
A quel point est-ce ardu de se faire passer pour un client du VPN, de récupérer le certificat de Brian ?

EDIT:
Dans mon projet, mes clients sont des serveurs pour le coup.
Du coup pas de soucis d'install de certif, (c est pas un humain qui change de bécane : portable, laptop, pc...).
Pour renforcer l'auth, je vais aussi utiliser un OTP (one time password).
Après chaque échange, celui ci est mis à jour.
Avant la fin d un échange, le client demande son nouveau OTP pour la prochaine fois.
Et parce qu on est jamais trop parano, cette demande transmet aussi un Token donné par le serveur lors de l'échange.

[BufferBob]

Je me questionne encore sur un point : comment peut on s'incruster dans un VPN ?
A quel point est-ce ardu de se faire passer pour un client du VPN, de récupérer le certificat de Brian ?

très très très.
à moins de faire transiter des données qui sont véritablement critiques (secrets industriels, données bancaires etc.) je pense pas que ça arrive tous les jours sauf à avoir des facilités d'exploitation pour l'attaquant

pour le dire autrement, je pense que c'est bien plus facile d'abuser Brian et/ou de compromettre directement sa machine que de s'attaquer à son flux chiffré, par exemple Brian quitte son poste pour aller boire un café, Kevin qui passe par là avec sa clé usb dans sa poche, remarque que Brian a laissé sa session ouverte et fait une simple copie de sa clé privée ssh ou son certificat vpn, la sécurité retombe à une simple (et très éventuelle) question de mot de passe.

[Hyt3k]

Merci.

L humain reste la faille yes.
Je suis en train de penser à un dongle usb ou SdCard... le truc ne marche pas sans que la SD soit pluggée.