Loppsi 2.0

Nicolas George

10/01/2011 à 19:32

Stephane Catteau , dans le message ,
a écrit :

Ce qui revient au même dans le cas présent, mais apparament tu es plus
intéressé par ta conviction d'avoir raison que par la démonstration de
cette conviction. Du coup tu te contente d'asséner tes certitudes sans
expliciter pourquoi elles existent, ce qui rend la discussion
impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à
deviner ce que tu as dans la tête.

J'avais supposé que le fait que tu te permettes d'intervenir sur une
discussion technique sur les protocole de cryptographie était signe que tu
avais les connaissances élémentaires permettant de suivre la discussion.
Manifestement ce n'est pas le cas. Puisque tu le demandes, je peux faire un
topo sur la question.

L'établissement d'une connexion sécurisée entre un client et un serveur suit
plusieurs étapes. La première étape est l'établissement et le partage d'une
clef de session : un bloc de données aléatoires qui va servir à chiffrer,
avec un algorithme symétrique, le reste de la communication.

L'algorithme le plus connu pour ça est celui de Diffie-Hellman : l'un des
interlocuteurs choisit des grands nombres p, a et k et transmet p, a et a^k
(modulo p) (je note ^ pour puissance). L'autre extrémité répond en
choisissant un grand nombre l et en transmettant a^l. Les deux extrémités
peuvent alors calculer (a^k)^l = (a^l)^k. En revanche, quelqu'un qui a
espionné la conversation passivement ne peut pas ; c'est le problème du
logarithme discret.

D'autres algorithmes existent. Ils garantissent tous au moins deux choses :

1. Quelqu'un qui espionne passivement la conversation ne peut pas
reconstituer la donnée secrète partagée.

2. La donnée secrète partagée dépend en large partie d'éléments choisis par
les deux extrémités : aucune des deux extrémités ne peut, en choisissant
ses paramètres judicieusement, imposer la clef qui l'arrange.

Ceci, bien sûr, en supposant qu'aucune faille théorique ne soit découverte,
bien entendu. Et dans un temps raisonnable, essentiellement tous les
algorithmes peuvent être cassés par force brute si on dispose d'un milliard
d'années devant soi.

Le point 2 est important : il implique qu'un attaquant qui se positionne en
« man in the middle », c'est à dire usurpe le serveur auprès du client et le
client auprès du serveur, ne peut pas se débrouiller pour négocier la même
clef de session avec le client et avec le serveur.

Une fois la clef de session établie, une des extrémités (en général le
serveur, parfois les deux ; je formulerai mes phrases en supposant que c'est
le serveur) s'authentifie auprès de l'autre. Cette authentification consiste
a signer, avec une clef cryptographique asymétrique secrète, un message
dérivé de paramètres choisis par l'autre extrémité.

Pour les protocoles bien conçus, cette authentification prend en compte,
entre autres, la clef de session ou les paramètres qui ont servi à
l'établir. Par exemple, pour TLS, il s'agit d'un haché de l'ensemble des
paquets échangés depuis le début.

Du coup, le man-in-the-middle se retrouve le bec dans l'eau : il doit
envoyer au client une signature de la clef de session qu'il a échangée avec
lui par la clef secrète du serveur, qu'il n'a évidemment pas. Et de l'autre
côté, le serveur lui envoie une signature, mais elle concerne la clef de
session établie avec lui, donc inutilisable.

Ces protocoles (et bien entendu, TLS et SSH utilisent des protocoles de ce
type) rendent donc réellement impossible l'espionnage d'une communication,
que ce soit de manière passive ou active.

Tout ceci repose bien entendu sur des hypothèses, deux que j'ai déjà citées
et une que j'explicite maintenant :

1. L'attaquant ne dispose pas d'une puissance de calcul digne de la
science-fiction.

2. L'attaquant n'a pas connaissance de faiblesses théoriques ou
d'implémentation inconnues dans les protocoles.

3. Le client a un moyen de vérifier la clef publique du serveur.

L'hypothèse 3 est la plus délicate : si tous les moyens de communication du
client avec l'extérieur ont été contrôlés par l'attaquant de toute éternité,
alors l'attaquant peut avoir substitué toutes les occurrences de la clef
publique du serveur et de ses signatures par sa propre clef. Ce scénario est
cependant complètement théorique et impossible à mettre en pratique.

En pratique, SSH résout le point 3 en demandant une vérification manuelle de
l'empreinte de la clef lors de la première connexion, ce qui sort le
problème du protocole. Du côté de TLS, ce sont les autorités de
certification installées dans le navigateur du client qui règlent la
question.

<news:
Accessoirement ces proxies, HTTPS autant que SSH, sont principalement
utilisés non pour le controle, mais pour le développement. Il est plus
simple d'analyser le flux en son centre, que de loguer l'intégralitée
des paquets aux deux extrémitées ; c'est donc un bon outil de
débuguage.
</>

Je te cite également :

# Le plus intéressant étant qu'au bout du compte la mise en place d'un
# tel proxy, sur un bridge en bordure du réseau, augmente le niveau de
# sécurité

C'est de là que la discussion est partie. Évidemment, si le client ou le
serveur _accepte_ d'être espionné, il n'y a rien à dire.

Dans cette discussion, *tu* es la personne qui pense que la clé
publique de l'utilisateur est inconnue du proxy.

Là, on entre dans le grand n'importe quoi, puisqu'il n'y a en général pas de
clef publique de l'utilisateur (l'authentification cliente TLS existe, mais
elle est utilisée de manière anecdotique).

l'utilisation fortuite est aussi possible, même si la tache
est effectivement compliquée par un pré-requis de taille, à savoir la
connaissance de la clé publique de l'utilisateur.

Et là, tu te plantes complètement.

2) Il n'a pas connaissance de la clé publique du serveur.

Il lui faudrait la clef secrète.

Stephane Catteau , dans le message <mn.54267db1da763a69.30736@sc4x.org>,
a écrit :

Ce qui revient au même dans le cas présent, mais apparament tu es plus
intéressé par ta conviction d'avoir raison que par la démonstration de
cette conviction. Du coup tu te contente d'asséner tes certitudes sans
expliciter pourquoi elles existent, ce qui rend la discussion
impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à
deviner ce que tu as dans la tête.

J'avais supposé que le fait que tu te permettes d'intervenir sur une
discussion technique sur les protocole de cryptographie était signe que tu
avais les connaissances élémentaires permettant de suivre la discussion.
Manifestement ce n'est pas le cas. Puisque tu le demandes, je peux faire un
topo sur la question.

L'établissement d'une connexion sécurisée entre un client et un serveur suit
plusieurs étapes. La première étape est l'établissement et le partage d'une
clef de session : un bloc de données aléatoires qui va servir à chiffrer,
avec un algorithme symétrique, le reste de la communication.

L'algorithme le plus connu pour ça est celui de Diffie-Hellman : l'un des
interlocuteurs choisit des grands nombres p, a et k et transmet p, a et a^k
(modulo p) (je note ^ pour puissance). L'autre extrémité répond en
choisissant un grand nombre l et en transmettant a^l. Les deux extrémités
peuvent alors calculer (a^k)^l = (a^l)^k. En revanche, quelqu'un qui a
espionné la conversation passivement ne peut pas ; c'est le problème du
logarithme discret.

D'autres algorithmes existent. Ils garantissent tous au moins deux choses :

1. Quelqu'un qui espionne passivement la conversation ne peut pas
reconstituer la donnée secrète partagée.

2. La donnée secrète partagée dépend en large partie d'éléments choisis par
les deux extrémités : aucune des deux extrémités ne peut, en choisissant
ses paramètres judicieusement, imposer la clef qui l'arrange.

Ceci, bien sûr, en supposant qu'aucune faille théorique ne soit découverte,
bien entendu. Et dans un temps raisonnable, essentiellement tous les
algorithmes peuvent être cassés par force brute si on dispose d'un milliard
d'années devant soi.

Le point 2 est important : il implique qu'un attaquant qui se positionne en
« man in the middle », c'est à dire usurpe le serveur auprès du client et le
client auprès du serveur, ne peut pas se débrouiller pour négocier la même
clef de session avec le client et avec le serveur.

Une fois la clef de session établie, une des extrémités (en général le
serveur, parfois les deux ; je formulerai mes phrases en supposant que c'est
le serveur) s'authentifie auprès de l'autre. Cette authentification consiste
a signer, avec une clef cryptographique asymétrique secrète, un message
dérivé de paramètres choisis par l'autre extrémité.

Pour les protocoles bien conçus, cette authentification prend en compte,
entre autres, la clef de session ou les paramètres qui ont servi à
l'établir. Par exemple, pour TLS, il s'agit d'un haché de l'ensemble des
paquets échangés depuis le début.

Du coup, le man-in-the-middle se retrouve le bec dans l'eau : il doit
envoyer au client une signature de la clef de session qu'il a échangée avec
lui par la clef secrète du serveur, qu'il n'a évidemment pas. Et de l'autre
côté, le serveur lui envoie une signature, mais elle concerne la clef de
session établie avec lui, donc inutilisable.

Ces protocoles (et bien entendu, TLS et SSH utilisent des protocoles de ce
type) rendent donc réellement impossible l'espionnage d'une communication,
que ce soit de manière passive ou active.

Tout ceci repose bien entendu sur des hypothèses, deux que j'ai déjà citées
et une que j'explicite maintenant :

1. L'attaquant ne dispose pas d'une puissance de calcul digne de la
science-fiction.

2. L'attaquant n'a pas connaissance de faiblesses théoriques ou
d'implémentation inconnues dans les protocoles.

3. Le client a un moyen de vérifier la clef publique du serveur.

L'hypothèse 3 est la plus délicate : si tous les moyens de communication du
client avec l'extérieur ont été contrôlés par l'attaquant de toute éternité,
alors l'attaquant peut avoir substitué toutes les occurrences de la clef
publique du serveur et de ses signatures par sa propre clef. Ce scénario est
cependant complètement théorique et impossible à mettre en pratique.

En pratique, SSH résout le point 3 en demandant une vérification manuelle de
l'empreinte de la clef lors de la première connexion, ce qui sort le
problème du protocole. Du côté de TLS, ce sont les autorités de
certification installées dans le navigateur du client qui règlent la
question.

<news:mn.3c187db1d65bd3ca.30736@sc4x.org>
Accessoirement ces proxies, HTTPS autant que SSH, sont principalement
utilisés non pour le controle, mais pour le développement. Il est plus
simple d'analyser le flux en son centre, que de loguer l'intégralitée
des paquets aux deux extrémitées ; c'est donc un bon outil de
débuguage.
</>

Je te cite également :

# Le plus intéressant étant qu'au bout du compte la mise en place d'un
# tel proxy, sur un bridge en bordure du réseau, augmente le niveau de
# sécurité

C'est de là que la discussion est partie. Évidemment, si le client ou le
serveur _accepte_ d'être espionné, il n'y a rien à dire.

Dans cette discussion, *tu* es la personne qui pense que la clé
publique de l'utilisateur est inconnue du proxy.

Là, on entre dans le grand n'importe quoi, puisqu'il n'y a en général pas de
clef publique de l'utilisateur (l'authentification cliente TLS existe, mais
elle est utilisée de manière anecdotique).

l'utilisation fortuite est aussi possible, même si la tache
est effectivement compliquée par un pré-requis de taille, à savoir la
connaissance de la clé publique de l'utilisateur.

Et là, tu te plantes complètement.

2) Il n'a pas connaissance de la clé publique du serveur.

Il lui faudrait la clef secrète.

Vous avez filtré cet utilisateur ! Consultez son message

Stephane Catteau , dans le message ,
a écrit :

Ce qui revient au même dans le cas présent, mais apparament tu es plus
intéressé par ta conviction d'avoir raison que par la démonstration de
cette conviction. Du coup tu te contente d'asséner tes certitudes sans
expliciter pourquoi elles existent, ce qui rend la discussion
impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à
deviner ce que tu as dans la tête.

J'avais supposé que le fait que tu te permettes d'intervenir sur une
discussion technique sur les protocole de cryptographie était signe que tu
avais les connaissances élémentaires permettant de suivre la discussion.
Manifestement ce n'est pas le cas. Puisque tu le demandes, je peux faire un
topo sur la question.

L'établissement d'une connexion sécurisée entre un client et un serveur suit
plusieurs étapes. La première étape est l'établissement et le partage d'une
clef de session : un bloc de données aléatoires qui va servir à chiffrer,
avec un algorithme symétrique, le reste de la communication.

L'algorithme le plus connu pour ça est celui de Diffie-Hellman : l'un des
interlocuteurs choisit des grands nombres p, a et k et transmet p, a et a^k
(modulo p) (je note ^ pour puissance). L'autre extrémité répond en
choisissant un grand nombre l et en transmettant a^l. Les deux extrémités
peuvent alors calculer (a^k)^l = (a^l)^k. En revanche, quelqu'un qui a
espionné la conversation passivement ne peut pas ; c'est le problème du
logarithme discret.

D'autres algorithmes existent. Ils garantissent tous au moins deux choses :

1. Quelqu'un qui espionne passivement la conversation ne peut pas
reconstituer la donnée secrète partagée.

2. La donnée secrète partagée dépend en large partie d'éléments choisis par
les deux extrémités : aucune des deux extrémités ne peut, en choisissant
ses paramètres judicieusement, imposer la clef qui l'arrange.

Ceci, bien sûr, en supposant qu'aucune faille théorique ne soit découverte,
bien entendu. Et dans un temps raisonnable, essentiellement tous les
algorithmes peuvent être cassés par force brute si on dispose d'un milliard
d'années devant soi.

Le point 2 est important : il implique qu'un attaquant qui se positionne en
« man in the middle », c'est à dire usurpe le serveur auprès du client et le
client auprès du serveur, ne peut pas se débrouiller pour négocier la même
clef de session avec le client et avec le serveur.

Une fois la clef de session établie, une des extrémités (en général le
serveur, parfois les deux ; je formulerai mes phrases en supposant que c'est
le serveur) s'authentifie auprès de l'autre. Cette authentification consiste
a signer, avec une clef cryptographique asymétrique secrète, un message
dérivé de paramètres choisis par l'autre extrémité.

Pour les protocoles bien conçus, cette authentification prend en compte,
entre autres, la clef de session ou les paramètres qui ont servi à
l'établir. Par exemple, pour TLS, il s'agit d'un haché de l'ensemble des
paquets échangés depuis le début.

Du coup, le man-in-the-middle se retrouve le bec dans l'eau : il doit
envoyer au client une signature de la clef de session qu'il a échangée avec
lui par la clef secrète du serveur, qu'il n'a évidemment pas. Et de l'autre
côté, le serveur lui envoie une signature, mais elle concerne la clef de
session établie avec lui, donc inutilisable.

Ces protocoles (et bien entendu, TLS et SSH utilisent des protocoles de ce
type) rendent donc réellement impossible l'espionnage d'une communication,
que ce soit de manière passive ou active.

Tout ceci repose bien entendu sur des hypothèses, deux que j'ai déjà citées
et une que j'explicite maintenant :

1. L'attaquant ne dispose pas d'une puissance de calcul digne de la
science-fiction.

2. L'attaquant n'a pas connaissance de faiblesses théoriques ou
d'implémentation inconnues dans les protocoles.

3. Le client a un moyen de vérifier la clef publique du serveur.

L'hypothèse 3 est la plus délicate : si tous les moyens de communication du
client avec l'extérieur ont été contrôlés par l'attaquant de toute éternité,
alors l'attaquant peut avoir substitué toutes les occurrences de la clef
publique du serveur et de ses signatures par sa propre clef. Ce scénario est
cependant complètement théorique et impossible à mettre en pratique.

En pratique, SSH résout le point 3 en demandant une vérification manuelle de
l'empreinte de la clef lors de la première connexion, ce qui sort le
problème du protocole. Du côté de TLS, ce sont les autorités de
certification installées dans le navigateur du client qui règlent la
question.

<news:
Accessoirement ces proxies, HTTPS autant que SSH, sont principalement
utilisés non pour le controle, mais pour le développement. Il est plus
simple d'analyser le flux en son centre, que de loguer l'intégralitée
des paquets aux deux extrémitées ; c'est donc un bon outil de
débuguage.
</>

Je te cite également :

# Le plus intéressant étant qu'au bout du compte la mise en place d'un
# tel proxy, sur un bridge en bordure du réseau, augmente le niveau de
# sécurité

C'est de là que la discussion est partie. Évidemment, si le client ou le
serveur _accepte_ d'être espionné, il n'y a rien à dire.

Dans cette discussion, *tu* es la personne qui pense que la clé
publique de l'utilisateur est inconnue du proxy.

Là, on entre dans le grand n'importe quoi, puisqu'il n'y a en général pas de
clef publique de l'utilisateur (l'authentification cliente TLS existe, mais
elle est utilisée de manière anecdotique).

l'utilisation fortuite est aussi possible, même si la tache
est effectivement compliquée par un pré-requis de taille, à savoir la
connaissance de la clé publique de l'utilisateur.

Et là, tu te plantes complètement.

2) Il n'a pas connaissance de la clé publique du serveur.

Il lui faudrait la clef secrète.

xavier

10/01/2011 à 19:46

Nicolas George <nicolas$ wrote:

Puisque tu le demandes, je peux faire un topo sur la question.
[...]

Merci pour ce moment de pédagogie, c'est vrai que beaucoup
d'administrateurs de serveurs (HTTPS/SSL ou SSH) n'ont pas connaissance
de tous les détails.

Quand on me demande si la connexion à notre intranet est sécurisée, à
ceux qui veulent des détails (mon chef ou mon patron, en général), je
réponds qu'il y a un échange de clés privées/publiques, et que personne
d'autre ne peut les connaître, ce qui est un raccourci très, très,
approximatif, voire inexact, parce que reconnais que je n'ai pas pris la
peine de m'informer sur les détails de l'implémentation. Enfin pour
HTTPS/SSL, parce que pour SSH, qui est mon pain quotidien depuis +15
ans, là, je sais à peu près comment ça marche (l'usage de ssh -vv aide
bien).

Ne parlons pas de Kerberos, là, j'avoue mon ignaritude totale :-)

--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)

Kevin Denis

10/01/2011 à 20:25

Le 10-01-2011, Stephane Catteau a écrit :

Techniquement parlant, je ne sais pas grand chose du
proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait
connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec
n'importe quel serveur.

Tu changes les données du problème. Ceci dit, je ne connais pas
SSH proxy, une recherche internet m'amène vers
http://www.wallix.org/
dont la doc se lit ici:
http://www.wallix.org/index.php/static/sshproxy-05-documentation

En quelques instants de lecture, cela ressemble à un wrapper
à la directive ProxyCommand de SSH. Donc rien de bien neuf sous le
sapin, quoi. Il faut avoir la main sur toute l'infrastructure, et
sur tous les serveurs. Que l'admin de la machine "proxy" puisse lire
ce que je fais sur la machine distante, bah bof, hein puisqu'il est
l'admin des deux (ou assimilé).

cette
robustesse demande une part de confiance.

Que l'on peut mettre en place et qui est stable dans le temps.

Mes clés sont récupérées de manière
fiable, de plus je vérifie ensuite à la connexion qu'il s'agit bien
de la bonne. Et le jour ou je vois un message comme quoi le Host
Key has changed, je coupe la connexion.

Autrement dit, si l'on n'a
pas confiance en la façon dont les clés publiques sont transmises à
l'admin ou en la façon dont ce dernier se connecte au serveur pour les
rajouter[2], alors il y n'est pas impossible que la connexion SSH soit
interceptée et comprise à notre insu.

Ca serait un problème amusant :) Soit l'écriture d'un serveur SSH
qui intercepte la connexion. Il envoie _sa_ clé. Le client n'y fait
pas attention (admettons, hein). Le client se connecte donc au
faux serveur. Forcément, il va vite se rendre compte du problème
puisqu'il n'est pas chez lui, mais chez toi sur ton faux serveur SSH.

Solution: tu forwardes une second connexion de chez toi vers le
vrai serveur. Le client ne voit pas qu'il est tunnelé.
Mais cette connexion, comment l'ouvres tu, avec quel accès?

J'ai connu un admin qui faisait tout l'administration via telnet au
motif que les machines serveurs et son poste de travail étaient sur le
même intranet, espéront le sécurisé à plus de 200%.

J'en ai connu un aussi. Mais plus prudent, il le faisait sur de l'IPSec :)
--
Kevin

Le 10-01-2011, Stephane Catteau <steph.nospam@sc4x.net> a écrit :

Techniquement parlant, je ne sais pas grand chose du
proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait
connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec
n'importe quel serveur.

Tu changes les données du problème. Ceci dit, je ne connais pas
SSH proxy, une recherche internet m'amène vers
http://www.wallix.org/
dont la doc se lit ici:
http://www.wallix.org/index.php/static/sshproxy-05-documentation

En quelques instants de lecture, cela ressemble à un wrapper
à la directive ProxyCommand de SSH. Donc rien de bien neuf sous le
sapin, quoi. Il faut avoir la main sur toute l'infrastructure, et
sur tous les serveurs. Que l'admin de la machine "proxy" puisse lire
ce que je fais sur la machine distante, bah bof, hein puisqu'il est
l'admin des deux (ou assimilé).

cette
robustesse demande une part de confiance.

Que l'on peut mettre en place et qui est stable dans le temps.

Mes clés sont récupérées de manière
fiable, de plus je vérifie ensuite à la connexion qu'il s'agit bien
de la bonne. Et le jour ou je vois un message comme quoi le Host
Key has changed, je coupe la connexion.

Autrement dit, si l'on n'a
pas confiance en la façon dont les clés publiques sont transmises à
l'admin ou en la façon dont ce dernier se connecte au serveur pour les
rajouter[2], alors il y n'est pas impossible que la connexion SSH soit
interceptée et comprise à notre insu.

Ca serait un problème amusant :) Soit l'écriture d'un serveur SSH
qui intercepte la connexion. Il envoie _sa_ clé. Le client n'y fait
pas attention (admettons, hein). Le client se connecte donc au
faux serveur. Forcément, il va vite se rendre compte du problème
puisqu'il n'est pas chez lui, mais chez toi sur ton faux serveur SSH.

Solution: tu forwardes une second connexion de chez toi vers le
vrai serveur. Le client ne voit pas qu'il est tunnelé.
Mais cette connexion, comment l'ouvres tu, avec quel accès?

J'ai connu un admin qui faisait tout l'administration via telnet au
motif que les machines serveurs et son poste de travail étaient sur le
même intranet, espéront le sécurisé à plus de 200%.

J'en ai connu un aussi. Mais plus prudent, il le faisait sur de l'IPSec :)
--
Kevin

Vous avez filtré cet utilisateur ! Consultez son message

Le 10-01-2011, Stephane Catteau a écrit :

Techniquement parlant, je ne sais pas grand chose du
proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait
connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec
n'importe quel serveur.

Tu changes les données du problème. Ceci dit, je ne connais pas
SSH proxy, une recherche internet m'amène vers
http://www.wallix.org/
dont la doc se lit ici:
http://www.wallix.org/index.php/static/sshproxy-05-documentation

En quelques instants de lecture, cela ressemble à un wrapper
à la directive ProxyCommand de SSH. Donc rien de bien neuf sous le
sapin, quoi. Il faut avoir la main sur toute l'infrastructure, et
sur tous les serveurs. Que l'admin de la machine "proxy" puisse lire
ce que je fais sur la machine distante, bah bof, hein puisqu'il est
l'admin des deux (ou assimilé).

cette
robustesse demande une part de confiance.

Que l'on peut mettre en place et qui est stable dans le temps.

Mes clés sont récupérées de manière
fiable, de plus je vérifie ensuite à la connexion qu'il s'agit bien
de la bonne. Et le jour ou je vois un message comme quoi le Host
Key has changed, je coupe la connexion.

Autrement dit, si l'on n'a
pas confiance en la façon dont les clés publiques sont transmises à
l'admin ou en la façon dont ce dernier se connecte au serveur pour les
rajouter[2], alors il y n'est pas impossible que la connexion SSH soit
interceptée et comprise à notre insu.

Ca serait un problème amusant :) Soit l'écriture d'un serveur SSH
qui intercepte la connexion. Il envoie _sa_ clé. Le client n'y fait
pas attention (admettons, hein). Le client se connecte donc au
faux serveur. Forcément, il va vite se rendre compte du problème
puisqu'il n'est pas chez lui, mais chez toi sur ton faux serveur SSH.

Solution: tu forwardes une second connexion de chez toi vers le
vrai serveur. Le client ne voit pas qu'il est tunnelé.
Mais cette connexion, comment l'ouvres tu, avec quel accès?

J'ai connu un admin qui faisait tout l'administration via telnet au
motif que les machines serveurs et son poste de travail étaient sur le
même intranet, espéront le sécurisé à plus de 200%.

J'en ai connu un aussi. Mais plus prudent, il le faisait sur de l'IPSec :)
--
Kevin

Stephane Catteau

10/01/2011 à 22:46

Kevin Denis n'était pas loin de dire :

Techniquement parlant, je ne sais pas grand chose du
proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait
connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec
n'importe quel serveur.

Tu changes les données du problème.

Non, mais les données du problème se sont un peu perdues en route.

[SSH proxy]

En quelques instants de lecture, cela ressemble à un wrapper
à la directive ProxyCommand de SSH. Donc rien de bien neuf sous le
sapin, quoi. Il faut avoir la main sur toute l'infrastructure, et
sur tous les serveurs. Que l'admin de la machine "proxy" puisse lire
ce que je fais sur la machine distante, bah bof, hein puisqu'il est
l'admin des deux (ou assimilé).

Pas forcément la main sur les serveurs, mais il faut qu'il ait la main
sur le proxy pour y ajouter les différentes clés, tant pour les
utilisateurs que pour les clients.
Pour autant, ce n'était pas un pur SSH proxy que j'ai vu à l'oeuvre,
il avait dû servir avant tout de base pour éviter d'avoir à réécrire la
partie de décryptage/loguage. Python et moi n'étant pas de grands amis
et l'une des filles de l'assistance fort jolie, j'avais largement zappé
l'explication technique des modifications apportées, et clairement je
le regrette maintenant.

Cela dit, vu que google n'a rien sur un tel proxy et à force de devoir
y penser ces derniers jours, je me demande jusqu'à quel point ce
n'était pas un flop à l'image de la "sensationnelle" faille WiFi de cet
été.
A l'époque, ma connaissance du protocole SSH était limitée à sa base
(protocole de chiffrement à clé publique/privée), donc j'ai un peu mis
tout ça de côté, mais maintenant je me pose des questions (c.f. plus
bas).

cette robustesse demande une part de confiance.

Que l'on peut mettre en place et qui est stable dans le temps.

Je suis moins catégorique concernant la stabilité dans le temps, mais
il est effectivement possible de renforcer la confiance, ne serait-ce
qu'en envoyant pas bêtement la clé en clair par e-mail via le SMTP de
son FAI/FSI.

[snip]

Solution: tu forwardes une second connexion de chez toi vers le
vrai serveur. Le client ne voit pas qu'il est tunnelé.
Mais cette connexion, comment l'ouvres tu, avec quel accès?

Le problème que je vois n'est pas tant dans l'accès pour ouvrir la
connexion, mais le travail sur la réponse faite par le serveur. Posons
les données du problème :

1) Le client utilisait la clé privée associée à la clé publique connue
du serveur. Ca ne me choque pas plus que cela, SSH proxy a besoin d'une
authentification, autant rien n'avait été changé de ce niveau là et la
même clé servait pour le proxy et pour le serveur. Ca n'est pas top en
matière de sécurité, mais vu qu'il s'agissait d'un environnement de
développement, les implications sont différentes ; au pire un attaquant
pouvait comuniquer avec un serveur de développement qui n'avait rien
derrière et avec un proxy qui n'avait accès qu'à des serveurs
similaires. Dans tous les cas de figure, le proxy ayant connaissance
préalable de la clé utilisée, il pouvait soit décrypter, soit altérer.
Appliqué à un proxy malvaillant, de nombreuses possibilités se
présente. La machine de l'utilisateur est plus vulnérable que le
serveur (puisqu'elle sert à d'autre chose), la clé privée peut avoir
été récupérée. La clé publique peut aussi avoir été interceptée et
remplacée par une autre, correspondant à une clé privée connue du
proxy. Et il y a probablement d'autres possibilité qui m'échappent.

2) Le proxy n'avait pas besoin de connaitre au préalable le serveur
pour travailler. Là par contre je coince... et je ne suis pas le seul
ça me rassurerais presque. Même en considérant que le proxy intercepte
la clé publique envoyée par le serveur, la seule chose qu'il puisse
faire, c'est décrypter ce qu'il a envoyé, pas l'altérer à sa guise. Et
si quelqu'un avait cassé l'algorithme d'échange de clés, il ne l'aurait
pas gardé pour lui :/
Appliqué à un proxy malvaillant c'est la même chose, sans connaissance
de la clé privée du serveur on ne va pas bien loin.

Kevin Denis n'était pas loin de dire :

Techniquement parlant, je ne sais pas grand chose du
proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait
connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec
n'importe quel serveur.

Tu changes les données du problème.

Non, mais les données du problème se sont un peu perdues en route.

[SSH proxy]

En quelques instants de lecture, cela ressemble à un wrapper
à la directive ProxyCommand de SSH. Donc rien de bien neuf sous le
sapin, quoi. Il faut avoir la main sur toute l'infrastructure, et
sur tous les serveurs. Que l'admin de la machine "proxy" puisse lire
ce que je fais sur la machine distante, bah bof, hein puisqu'il est
l'admin des deux (ou assimilé).

Pas forcément la main sur les serveurs, mais il faut qu'il ait la main
sur le proxy pour y ajouter les différentes clés, tant pour les
utilisateurs que pour les clients.
Pour autant, ce n'était pas un pur SSH proxy que j'ai vu à l'oeuvre,
il avait dû servir avant tout de base pour éviter d'avoir à réécrire la
partie de décryptage/loguage. Python et moi n'étant pas de grands amis
et l'une des filles de l'assistance fort jolie, j'avais largement zappé
l'explication technique des modifications apportées, et clairement je
le regrette maintenant.

Cela dit, vu que google n'a rien sur un tel proxy et à force de devoir
y penser ces derniers jours, je me demande jusqu'à quel point ce
n'était pas un flop à l'image de la "sensationnelle" faille WiFi de cet
été.
A l'époque, ma connaissance du protocole SSH était limitée à sa base
(protocole de chiffrement à clé publique/privée), donc j'ai un peu mis
tout ça de côté, mais maintenant je me pose des questions (c.f. plus
bas).

cette robustesse demande une part de confiance.

Que l'on peut mettre en place et qui est stable dans le temps.

Je suis moins catégorique concernant la stabilité dans le temps, mais
il est effectivement possible de renforcer la confiance, ne serait-ce
qu'en envoyant pas bêtement la clé en clair par e-mail via le SMTP de
son FAI/FSI.

[snip]

Solution: tu forwardes une second connexion de chez toi vers le
vrai serveur. Le client ne voit pas qu'il est tunnelé.
Mais cette connexion, comment l'ouvres tu, avec quel accès?

Le problème que je vois n'est pas tant dans l'accès pour ouvrir la
connexion, mais le travail sur la réponse faite par le serveur. Posons
les données du problème :

1) Le client utilisait la clé privée associée à la clé publique connue
du serveur. Ca ne me choque pas plus que cela, SSH proxy a besoin d'une
authentification, autant rien n'avait été changé de ce niveau là et la
même clé servait pour le proxy et pour le serveur. Ca n'est pas top en
matière de sécurité, mais vu qu'il s'agissait d'un environnement de
développement, les implications sont différentes ; au pire un attaquant
pouvait comuniquer avec un serveur de développement qui n'avait rien
derrière et avec un proxy qui n'avait accès qu'à des serveurs
similaires. Dans tous les cas de figure, le proxy ayant connaissance
préalable de la clé utilisée, il pouvait soit décrypter, soit altérer.
Appliqué à un proxy malvaillant, de nombreuses possibilités se
présente. La machine de l'utilisateur est plus vulnérable que le
serveur (puisqu'elle sert à d'autre chose), la clé privée peut avoir
été récupérée. La clé publique peut aussi avoir été interceptée et
remplacée par une autre, correspondant à une clé privée connue du
proxy. Et il y a probablement d'autres possibilité qui m'échappent.

2) Le proxy n'avait pas besoin de connaitre au préalable le serveur
pour travailler. Là par contre je coince... et je ne suis pas le seul
ça me rassurerais presque. Même en considérant que le proxy intercepte
la clé publique envoyée par le serveur, la seule chose qu'il puisse
faire, c'est décrypter ce qu'il a envoyé, pas l'altérer à sa guise. Et
si quelqu'un avait cassé l'algorithme d'échange de clés, il ne l'aurait
pas gardé pour lui :/
Appliqué à un proxy malvaillant c'est la même chose, sans connaissance
de la clé privée du serveur on ne va pas bien loin.

Vous avez filtré cet utilisateur ! Consultez son message

Kevin Denis n'était pas loin de dire :

Techniquement parlant, je ne sais pas grand chose du
proxy si ce n'est qu'il est dérivé de SSH proxy, qu'il avait
connaissance de la clé utilisateur utilisée et qu'il fonctionnait avec
n'importe quel serveur.

Tu changes les données du problème.

Non, mais les données du problème se sont un peu perdues en route.

[SSH proxy]

En quelques instants de lecture, cela ressemble à un wrapper
à la directive ProxyCommand de SSH. Donc rien de bien neuf sous le
sapin, quoi. Il faut avoir la main sur toute l'infrastructure, et
sur tous les serveurs. Que l'admin de la machine "proxy" puisse lire
ce que je fais sur la machine distante, bah bof, hein puisqu'il est
l'admin des deux (ou assimilé).

Pas forcément la main sur les serveurs, mais il faut qu'il ait la main
sur le proxy pour y ajouter les différentes clés, tant pour les
utilisateurs que pour les clients.
Pour autant, ce n'était pas un pur SSH proxy que j'ai vu à l'oeuvre,
il avait dû servir avant tout de base pour éviter d'avoir à réécrire la
partie de décryptage/loguage. Python et moi n'étant pas de grands amis
et l'une des filles de l'assistance fort jolie, j'avais largement zappé
l'explication technique des modifications apportées, et clairement je
le regrette maintenant.

Cela dit, vu que google n'a rien sur un tel proxy et à force de devoir
y penser ces derniers jours, je me demande jusqu'à quel point ce
n'était pas un flop à l'image de la "sensationnelle" faille WiFi de cet
été.
A l'époque, ma connaissance du protocole SSH était limitée à sa base
(protocole de chiffrement à clé publique/privée), donc j'ai un peu mis
tout ça de côté, mais maintenant je me pose des questions (c.f. plus
bas).

cette robustesse demande une part de confiance.

Que l'on peut mettre en place et qui est stable dans le temps.

Je suis moins catégorique concernant la stabilité dans le temps, mais
il est effectivement possible de renforcer la confiance, ne serait-ce
qu'en envoyant pas bêtement la clé en clair par e-mail via le SMTP de
son FAI/FSI.

[snip]

Solution: tu forwardes une second connexion de chez toi vers le
vrai serveur. Le client ne voit pas qu'il est tunnelé.
Mais cette connexion, comment l'ouvres tu, avec quel accès?

Le problème que je vois n'est pas tant dans l'accès pour ouvrir la
connexion, mais le travail sur la réponse faite par le serveur. Posons
les données du problème :

1) Le client utilisait la clé privée associée à la clé publique connue
du serveur. Ca ne me choque pas plus que cela, SSH proxy a besoin d'une
authentification, autant rien n'avait été changé de ce niveau là et la
même clé servait pour le proxy et pour le serveur. Ca n'est pas top en
matière de sécurité, mais vu qu'il s'agissait d'un environnement de
développement, les implications sont différentes ; au pire un attaquant
pouvait comuniquer avec un serveur de développement qui n'avait rien
derrière et avec un proxy qui n'avait accès qu'à des serveurs
similaires. Dans tous les cas de figure, le proxy ayant connaissance
préalable de la clé utilisée, il pouvait soit décrypter, soit altérer.
Appliqué à un proxy malvaillant, de nombreuses possibilités se
présente. La machine de l'utilisateur est plus vulnérable que le
serveur (puisqu'elle sert à d'autre chose), la clé privée peut avoir
été récupérée. La clé publique peut aussi avoir été interceptée et
remplacée par une autre, correspondant à une clé privée connue du
proxy. Et il y a probablement d'autres possibilité qui m'échappent.

2) Le proxy n'avait pas besoin de connaitre au préalable le serveur
pour travailler. Là par contre je coince... et je ne suis pas le seul
ça me rassurerais presque. Même en considérant que le proxy intercepte
la clé publique envoyée par le serveur, la seule chose qu'il puisse
faire, c'est décrypter ce qu'il a envoyé, pas l'altérer à sa guise. Et
si quelqu'un avait cassé l'algorithme d'échange de clés, il ne l'aurait
pas gardé pour lui :/
Appliqué à un proxy malvaillant c'est la même chose, sans connaissance
de la clé privée du serveur on ne va pas bien loin.

Stephane Catteau

10/01/2011 à 22:51

Nicolas George n'était pas loin de dire :

Ce qui revient au même dans le cas présent, mais apparament tu es plus
intéressé par ta conviction d'avoir raison que par la démonstration de
cette conviction. Du coup tu te contente d'asséner tes certitudes sans
expliciter pourquoi elles existent, ce qui rend la discussion
impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à

^^^^^^^^^^^^^^^^^^^^^^^

deviner ce que tu as dans la tête.

J'avais supposé que le fait que tu te [...]

A ma connaissance il s'agit d'une discussion tenue sur un forum
publique, pas d'une discussion privée lisible par les deux seuls
intervenants. Merci, de la part du lecteur, pour ton exposé...

# Le plus intéressant étant qu'au bout du compte la mise en place d'un
# tel proxy, sur un bridge en bordure du réseau, augmente le niveau de
# sécurité

C'est de là que la discussion est partie. Évidemment, si le client ou le
serveur _accepte_ d'être espionné, il n'y a rien à dire.

Parce que toi tu augmentes ton niveau de sécurité à ton insu ?

Dans cette discussion, tu es la personne qui pense que la clé
publique de l'utilisateur est inconnue du proxy.

Là, on entre dans le grand n'importe quoi, puisqu'il n'y a en général
pas de clef publique de l'utilisateur (l'authentification cliente TLS
existe, mais elle est utilisée de manière anecdotique).

Sauf qu'on parle de SSH. Le client crypte p, a et (a^k)%p avec sa clé
privée, que le serveur décrypte avec la clé publique associée, tandis
que le serveur utilise sa clé privée pour crypter a^l et que le client
utilise la clé publique du serveur (qu'il a lui-même transmit le cas
échéant) pour décrypter.
La robustesse de SSH tenant justement au fait que la clé privée du
serveur est suposée[1] ne jamais transiter sur le réseau.

[1]
Mais il lui arrive de transiter sur le réseau, le protocole le
considère même comme une possibilité :
<RFC 4251>
4.1. Host Keys
[...]Multiple hosts MAY share the same host key.[...]
</>
L'idéal dans ce cas là étant de transmettre la clé via une connexion
série directe avec le serveur, mais bon, l'idéal n'est que théorique.

Nicolas George n'était pas loin de dire :

Ce qui revient au même dans le cas présent, mais apparament tu es plus
intéressé par ta conviction d'avoir raison que par la démonstration de
cette conviction. Du coup tu te contente d'asséner tes certitudes sans
expliciter pourquoi elles existent, ce qui rend la discussion
impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à

^^^^^^^^^^^^^^^^^^^^^^^

deviner ce que tu as dans la tête.

J'avais supposé que le fait que tu te [...]

A ma connaissance il s'agit d'une discussion tenue sur un forum
publique, pas d'une discussion privée lisible par les deux seuls
intervenants. Merci, de la part du lecteur, pour ton exposé...

# Le plus intéressant étant qu'au bout du compte la mise en place d'un
# tel proxy, sur un bridge en bordure du réseau, augmente le niveau de
# sécurité

C'est de là que la discussion est partie. Évidemment, si le client ou le
serveur _accepte_ d'être espionné, il n'y a rien à dire.

Parce que toi tu augmentes ton niveau de sécurité à ton insu ?

Dans cette discussion, tu es la personne qui pense que la clé
publique de l'utilisateur est inconnue du proxy.

Là, on entre dans le grand n'importe quoi, puisqu'il n'y a en général
pas de clef publique de l'utilisateur (l'authentification cliente TLS
existe, mais elle est utilisée de manière anecdotique).

Sauf qu'on parle de SSH. Le client crypte p, a et (a^k)%p avec sa clé
privée, que le serveur décrypte avec la clé publique associée, tandis
que le serveur utilise sa clé privée pour crypter a^l et que le client
utilise la clé publique du serveur (qu'il a lui-même transmit le cas
échéant) pour décrypter.
La robustesse de SSH tenant justement au fait que la clé privée du
serveur est suposée[1] ne jamais transiter sur le réseau.

[1]
Mais il lui arrive de transiter sur le réseau, le protocole le
considère même comme une possibilité :
<RFC 4251>
4.1. Host Keys
[...]Multiple hosts MAY share the same host key.[...]
</>
L'idéal dans ce cas là étant de transmettre la clé via une connexion
série directe avec le serveur, mais bon, l'idéal n'est que théorique.

Vous avez filtré cet utilisateur ! Consultez son message

Nicolas George n'était pas loin de dire :

Ce qui revient au même dans le cas présent, mais apparament tu es plus
intéressé par ta conviction d'avoir raison que par la démonstration de
cette conviction. Du coup tu te contente d'asséner tes certitudes sans
expliciter pourquoi elles existent, ce qui rend la discussion
impossible (et inutile pour le lecteur qui n'y apprend rien), sauf à

^^^^^^^^^^^^^^^^^^^^^^^

deviner ce que tu as dans la tête.

J'avais supposé que le fait que tu te [...]

A ma connaissance il s'agit d'une discussion tenue sur un forum
publique, pas d'une discussion privée lisible par les deux seuls
intervenants. Merci, de la part du lecteur, pour ton exposé...

# Le plus intéressant étant qu'au bout du compte la mise en place d'un
# tel proxy, sur un bridge en bordure du réseau, augmente le niveau de
# sécurité

C'est de là que la discussion est partie. Évidemment, si le client ou le
serveur _accepte_ d'être espionné, il n'y a rien à dire.

Parce que toi tu augmentes ton niveau de sécurité à ton insu ?

Dans cette discussion, tu es la personne qui pense que la clé
publique de l'utilisateur est inconnue du proxy.

Là, on entre dans le grand n'importe quoi, puisqu'il n'y a en général
pas de clef publique de l'utilisateur (l'authentification cliente TLS
existe, mais elle est utilisée de manière anecdotique).

Sauf qu'on parle de SSH. Le client crypte p, a et (a^k)%p avec sa clé
privée, que le serveur décrypte avec la clé publique associée, tandis
que le serveur utilise sa clé privée pour crypter a^l et que le client
utilise la clé publique du serveur (qu'il a lui-même transmit le cas
échéant) pour décrypter.
La robustesse de SSH tenant justement au fait que la clé privée du
serveur est suposée[1] ne jamais transiter sur le réseau.

[1]
Mais il lui arrive de transiter sur le réseau, le protocole le
considère même comme une possibilité :
<RFC 4251>
4.1. Host Keys
[...]Multiple hosts MAY share the same host key.[...]
</>
L'idéal dans ce cas là étant de transmettre la clé via une connexion
série directe avec le serveur, mais bon, l'idéal n'est que théorique.

Nicolas George

10/01/2011 à 23:32

Stephane Catteau , dans le message ,
a écrit :

Sauf qu'on parle de SSH. Le client crypte p, a et (a^k)%p avec sa clé
privée, que le serveur décrypte avec la clé publique associée, tandis
que le serveur utilise sa clé privée pour crypter a^l et que le client
utilise la clé publique du serveur (qu'il a lui-même transmit le cas
échéant) pour décrypter.

Et alors ?

Ton discours se met de plus en plus à partir dans tous les sens avec des
bouts de pseudo-arguments dedans, mais sans aucune cohérence d'ensemble.

Kevin Denis

11/01/2011 à 09:54

Le 10-01-2011, Xavier a écrit :

Quand on me demande si la connexion à notre intranet est sécurisée, à
ceux qui veulent des détails (mon chef ou mon patron, en général), je
réponds qu'il y a un échange de clés privées/publiques, et que personne
d'autre ne peut les connaître, ce qui est un raccourci très, très,
approximatif, voire inexact, parce que reconnais que je n'ai pas pris la
peine de m'informer sur les détails de l'implémentation. Enfin pour
HTTPS/SSL, parce que pour SSH, qui est mon pain quotidien depuis +15
ans, là, je sais à peu près comment ça marche (l'usage de ssh -vv aide
bien).

Une lecture intéressante pour HTTPS,
http://news0ft.blogspot.com/2010/04/ssl-est-casse.html

Comme souvent en informatique, sur le papier, c'est beau, ça marche,
c'est fiable, mais dans l'implémentation, certains points laissent à
désirer allant jusqu'à annihiler l'usage initial.
--
Kevin

Yannix

11/01/2011 à 22:47

Le 10/01/2011 23:32, Nicolas George a écrit :

Stephane Catteau , dans le message ,
a écrit :
Sauf qu'on parle de SSH. Le client crypte p, a et (a^k)%p avec sa clé
privée, que le serveur décrypte avec la clé publique associée, tandis
que le serveur utilise sa clé privée pour crypter a^l et que le client
utilise la clé publique du serveur (qu'il a lui-même transmit le cas
échéant) pour décrypter.

Et alors ?

Ton discours se met de plus en plus à partir dans tous les sens avec des
bouts de pseudo-arguments dedans, mais sans aucune cohérence d'ensemble.

Bon, c'est bien vos embrouilles, mais si t'es chercheur-enseignant du
CNRS ou autre, peut-être qu'il serait mieux de faire une conf à se sujet
et de nous poster la vidéo sur le net qu'on comprenne bien. Non ?

A+

X.

Kevin Denis

12/01/2011 à 11:50

Le 10-01-2011, Stephane Catteau a écrit :

Non, mais les données du problème se sont un peu perdues en route.

Cela est parti de la possibilité d'intercaler un hôte entre
la source et la destination, de manière malveillante, pour intercepter (au
moins connaitre) les flux. Cela se fait très bien en HTTP, de
manière volontaire ou transparente, via squid et des règles iptables
par exemple.

En SSH, il y a lieu de séparer les deux:
1-L'utilisateur se connecte volontairement à un proxy SSH
2-Un attaquant s'intercale entre un serveur et un client SSH

Le 1- pourquoi pas. Le 2- est ce qui m'intéresse, et il me semble que
c'est toujours impossible, en tout cas SSH est prévu pour éviter cette
situation.

Appliqué à un proxy malvaillant c'est la même chose, sans connaissance
de la clé privée du serveur on ne va pas bien loin.

Voilà.
--
Kevin

wr35nn89

03/02/2011 à 22:03

Le 07/01/2011 18:33, JKB a écrit :

<soupir>

Je connais un prestataire de service qui possède justement ce genre
de proxy. Pour l'utilisateur final, c'est chiffré. Sauf que le proxy
déchiffre et rechiffre au vol à fins d'analyse pour être sûr que ce
qui circule sur le port 443 est du https légitime et pas un autre
protocole. Après, tout est dans la confiance que l'on accorde au
prestataire en question.

JKB

Exact....
Chez nous, ça sert pour antiviruser les flux https.... (enfin, on dit au
client que c'est pour antiviruser....)
Moi, je vois ça comme une façon de surveiller encore plus les utilisateurs.
Et, oui, pour que ça marche, faut installer les certificats kivonbien
sur les postes clients. Si yapa certificat, c'est intravaillable
(alertes de sécurité dans tous les sens).

Loppsi 2.0

10 réponses

Veuillez sélectionner un problème