Souvent mis en avant pour son aspect sécurité, le système d'exploitation
OpenBSD embarquerait dans son code des portes dérobées mises en place
sous la houlette du FBI il y a une dizaine d'années.
Des rumeurs ont longtemps été relayées à propos de la présence d'une
backdoor gouvernementale dans le système d'exploitation Windows.
Stupeur, c'est aujourd'hui un système d'exploitation Open Source qui
fait l'objet de tels soupçons, et en l'occurrence OpenBSD loué pour être
un OS très sécurisé avec cryptographie intégrée.
Le créateur du système d'exploitation libre de type UNIX, Theo de Raadt,
a rendu public un e-mail qui lui a adressé Gregory Perry, une vieille
connaissance. Actuellement PDG de la société GoVirtual Education,
Gregory Perry a été auparavant le directeur technique de NETSEC et a
contribué au framework cryptographique d'OpenBSD.
C'est au sein de NETSEC que l'homme a effectué un travail de consultant
pour le compte d'une branche du FBI ( Federal Bureau of Investigations
). Il affirme qu'il y a maintenant dix ans, le FBI a rémunéré des
développeurs afin qu'ils installent des backdoors dans la pile réseau
IPSEC d'OpenBSD. Ces portes dérobées et autres mécanismes auraient pour
but de surveiller le système de chiffrement lors de connexions VPN entre
des sites.
Il avance que c'est pourquoi des personnes proches du FBI sont
aujourd'hui devenues des avocats de l'utilisation d'OpenBSD dans des
environnements virtualisés pour des implémentations VPN. Ces soudaines
révélations paraissent étranges, mais si Gregory Perry a attendu près de
dix ans avant de " passer aux aveux ", c'est parce qu'il précise que
son accord de non-divulgation avec le FBI vient d'expirer.
Theo de Raadt refuse de souscrire à une théorie du complot mais fait
preuve d'une grande transparence en rendant public le message de Gregory
Perry. Il pousse ainsi à un audit du code concerné par les personnes qui
l'utilisent. Un audit qui ne sera pas une mince affaire. Par ailleurs,
il donne l'opportunité aux développeurs OpenBSD cités par Gregory Perry
de se défendre.
Pour Theo de Raadt, même si les backdoors existent, le code de IPSEC a
beaucoup évolué depuis dix ans. Difficile donc selon lui d'évaluer
l'impact des allégations de Gregory Perry. Il souligne néanmoins que la
pile IPSEC était gratuite et qu'une large partie de son code se retrouve
dans beaucoup d'autres projets et produits qu'OpenBSD.
Pas la peine: tout a déjà été dit ailleurs. Google est votre ami.
^^^^^^^^ Donc, on se demande à quoi peut bien servir ce NG, n'est-ce pas ?
Bah, ce n'est pas spécifique à ce groupe, je pense... Usenet est en perte de vitesse, il ne faut pas se le cacher... Je viens de "remonter" mon serveur ici, suite à quelques demandes d'utilisateurs, mais s'il n'avait tenu qu'à moi (malgré un peu de nostalgie)... Il était arrêté depuis plus de 6 mois suite à l'arrêt quasi-simultané de nos 2 feeds. J'en ai trouvé un autre, merci à l'UBO. ;-)
Beaucoup de choses se passent désormais sur les listes de diffusion, et je peux vous dire que cette "nouvelle" a été abondamment commentée dans plusieurs d'entre elles.
Cela dit, ce groupe peut avoir son utilité également, bien sûr, mais dans le cas de ce "scoop", il s'est dégonflé très rapidement par la suite...
D'ailleurs, n'est-ce pas vous qui, au début de cette année, disiez qu'au niveau des VPN, en dehors d'IPSec, point de salut ?
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est compromis, vous voyez quoi comme solution alternative ?
Hmm. Je sens venir la guerre de religion, là. ;-)
Il y en a plusieurs (en dehors de PPTP ;-) ) (liste non exhaustive):
1) OpenVPN: dans la discussion animée de début janvier (le fil concernait la LOPPSI 2) vous n'aviez pas l'air convaincu par ce logiciel, que vous avez même qualifié, je crois, de "vaporware". Je peux vous dire que c'est très loin d'en être... Ce logiciel fonctionne excellemment, est d'une stabilité remarquable. Il utilise du SSL (OpenSSL), dans une implémentation qui fonctionne également sur UDP (afin d'éviter le fameux problème de l'empilement des couches de correction d'erreur: 2 couches TCP encapsulées l'une dans l'autre, c'est une source potentielle de problèmes, chacune essayant de corriger le tir en faisant des retransmissions, ce qui peut écrouler le lien). Ce n'est cependant pas du DTLS, mais une solution alternative, qui a consisté à re-coder la couche de fiabilité ordinairement apportée par TCP. Vous pouvez utiliser une authentification par clef partagée ou par certificats. Je connais bien cette solution pour l'employer depuis des années (tunnels en fonction depuis 2004).
2) stunnel: jamais utilisé pour ma part en tant que VPN, juste pour établir à la mimine des connexions SSL vers des serveurs web HTTPS, mais il paraît que ça marche bien.
3) OpenSSH: tout à fait utilisable pour établir des tunnels VPN également. Solution de secours que j'ai déjà mise en oeuvre également.
Les solutions 1 (OpenVPN) et 3 (OpenSSH) sont également utilisables en couche mode VPN couche 2 (à partir de la version 4.3 pour OpenSSH). Pour stunnel, je ne pense pas, mais comme je ne l'ai pas utilisé dans ce mode, je n'ai aucune certitude.
Voilà... Maintenant, vous avez parfaitement le droit de ne pas être d'accord, bien entendu.
Cordialement,
Bruno Tréguier
Bonjour,
Le 25/02/2011 à 15:30, Yannix a écrit :
Pas la peine: tout a déjà été dit ailleurs. Google est votre ami.
^^^^^^^^
Donc, on se demande à quoi peut bien servir ce NG, n'est-ce pas ?
Bah, ce n'est pas spécifique à ce groupe, je pense... Usenet est en
perte de vitesse, il ne faut pas se le cacher... Je viens de "remonter"
mon serveur ici, suite à quelques demandes d'utilisateurs, mais s'il
n'avait tenu qu'à moi (malgré un peu de nostalgie)... Il était arrêté
depuis plus de 6 mois suite à l'arrêt quasi-simultané de nos 2 feeds.
J'en ai trouvé un autre, merci à l'UBO. ;-)
Beaucoup de choses se passent désormais sur les listes de diffusion, et
je peux vous dire que cette "nouvelle" a été abondamment commentée dans
plusieurs d'entre elles.
Cela dit, ce groupe peut avoir son utilité également, bien sûr, mais
dans le cas de ce "scoop", il s'est dégonflé très rapidement par la suite...
D'ailleurs, n'est-ce pas vous qui, au début de cette année, disiez qu'au
niveau des VPN, en dehors d'IPSec, point de salut ?
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est
compromis, vous voyez quoi comme solution alternative ?
Hmm. Je sens venir la guerre de religion, là. ;-)
Il y en a plusieurs (en dehors de PPTP ;-) ) (liste non exhaustive):
1) OpenVPN: dans la discussion animée de début janvier (le fil
concernait la LOPPSI 2) vous n'aviez pas l'air convaincu par ce
logiciel, que vous avez même qualifié, je crois, de "vaporware". Je peux
vous dire que c'est très loin d'en être... Ce logiciel fonctionne
excellemment, est d'une stabilité remarquable. Il utilise du SSL
(OpenSSL), dans une implémentation qui fonctionne également sur UDP
(afin d'éviter le fameux problème de l'empilement des couches de
correction d'erreur: 2 couches TCP encapsulées l'une dans l'autre, c'est
une source potentielle de problèmes, chacune essayant de corriger le tir
en faisant des retransmissions, ce qui peut écrouler le lien). Ce n'est
cependant pas du DTLS, mais une solution alternative, qui a consisté à
re-coder la couche de fiabilité ordinairement apportée par TCP. Vous
pouvez utiliser une authentification par clef partagée ou par
certificats. Je connais bien cette solution pour l'employer depuis des
années (tunnels en fonction depuis 2004).
2) stunnel: jamais utilisé pour ma part en tant que VPN, juste pour
établir à la mimine des connexions SSL vers des serveurs web HTTPS, mais
il paraît que ça marche bien.
3) OpenSSH: tout à fait utilisable pour établir des tunnels VPN
également. Solution de secours que j'ai déjà mise en oeuvre également.
Les solutions 1 (OpenVPN) et 3 (OpenSSH) sont également utilisables en
couche mode VPN couche 2 (à partir de la version 4.3 pour OpenSSH). Pour
stunnel, je ne pense pas, mais comme je ne l'ai pas utilisé dans ce
mode, je n'ai aucune certitude.
Voilà... Maintenant, vous avez parfaitement le droit de ne pas être
d'accord, bien entendu.
Pas la peine: tout a déjà été dit ailleurs. Google est votre ami.
^^^^^^^^ Donc, on se demande à quoi peut bien servir ce NG, n'est-ce pas ?
Bah, ce n'est pas spécifique à ce groupe, je pense... Usenet est en perte de vitesse, il ne faut pas se le cacher... Je viens de "remonter" mon serveur ici, suite à quelques demandes d'utilisateurs, mais s'il n'avait tenu qu'à moi (malgré un peu de nostalgie)... Il était arrêté depuis plus de 6 mois suite à l'arrêt quasi-simultané de nos 2 feeds. J'en ai trouvé un autre, merci à l'UBO. ;-)
Beaucoup de choses se passent désormais sur les listes de diffusion, et je peux vous dire que cette "nouvelle" a été abondamment commentée dans plusieurs d'entre elles.
Cela dit, ce groupe peut avoir son utilité également, bien sûr, mais dans le cas de ce "scoop", il s'est dégonflé très rapidement par la suite...
D'ailleurs, n'est-ce pas vous qui, au début de cette année, disiez qu'au niveau des VPN, en dehors d'IPSec, point de salut ?
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est compromis, vous voyez quoi comme solution alternative ?
Hmm. Je sens venir la guerre de religion, là. ;-)
Il y en a plusieurs (en dehors de PPTP ;-) ) (liste non exhaustive):
1) OpenVPN: dans la discussion animée de début janvier (le fil concernait la LOPPSI 2) vous n'aviez pas l'air convaincu par ce logiciel, que vous avez même qualifié, je crois, de "vaporware". Je peux vous dire que c'est très loin d'en être... Ce logiciel fonctionne excellemment, est d'une stabilité remarquable. Il utilise du SSL (OpenSSL), dans une implémentation qui fonctionne également sur UDP (afin d'éviter le fameux problème de l'empilement des couches de correction d'erreur: 2 couches TCP encapsulées l'une dans l'autre, c'est une source potentielle de problèmes, chacune essayant de corriger le tir en faisant des retransmissions, ce qui peut écrouler le lien). Ce n'est cependant pas du DTLS, mais une solution alternative, qui a consisté à re-coder la couche de fiabilité ordinairement apportée par TCP. Vous pouvez utiliser une authentification par clef partagée ou par certificats. Je connais bien cette solution pour l'employer depuis des années (tunnels en fonction depuis 2004).
2) stunnel: jamais utilisé pour ma part en tant que VPN, juste pour établir à la mimine des connexions SSL vers des serveurs web HTTPS, mais il paraît que ça marche bien.
3) OpenSSH: tout à fait utilisable pour établir des tunnels VPN également. Solution de secours que j'ai déjà mise en oeuvre également.
Les solutions 1 (OpenVPN) et 3 (OpenSSH) sont également utilisables en couche mode VPN couche 2 (à partir de la version 4.3 pour OpenSSH). Pour stunnel, je ne pense pas, mais comme je ne l'ai pas utilisé dans ce mode, je n'ai aucune certitude.
Voilà... Maintenant, vous avez parfaitement le droit de ne pas être d'accord, bien entendu.
Cordialement,
Bruno Tréguier
Bruno Tréguier
Bonjour,
Le 25/02/2011 à 15:30, Yannix a écrit :
Pas la peine: tout a déjà été dit ailleurs. Google est votre ami.
^^^^^^^^ Donc, on se demande à quoi peut bien servir ce NG, n'est-ce pas ?
Bah, ce n'est pas spécifique à ce groupe, je pense... Usenet est en perte de vitesse, il ne faut pas se le cacher... Je viens de "remonter" mon serveur ici, suite à quelques demandes d'utilisateurs, mais s'il n'avait tenu qu'à moi (malgré un peu de nostalgie)... Il était arrêté depuis plus de 6 mois suite à l'arrêt quasi-simultané de nos 2 feeds. J'en ai trouvé un autre, merci à l'UBO. ;-)
Beaucoup de choses se passent désormais sur les listes de diffusion, et je peux vous dire que cette "nouvelle" a été abondamment commentée dans plusieurs d'entre elles.
Cela dit, ce groupe peut avoir son utilité également, bien sûr, mais dans le cas de ce "scoop", il s'est dégonflé très rapidement par la suite...
D'ailleurs, n'est-ce pas vous qui, au début de cette année, disiez qu'au niveau des VPN, en dehors d'IPSec, point de salut ?
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est compromis, vous voyez quoi comme solution alternative ?
Hmm. Je sens venir la guerre de religion, là. ;-)
Il y en a plusieurs (en dehors de PPTP ;-) ) (liste non exhaustive):
1) OpenVPN: dans la discussion animée de début janvier (le fil concernait la LOPPSI 2) vous n'aviez pas l'air convaincu par ce logiciel, que vous avez même qualifié, je crois, de "vaporware". Je peux vous dire que c'est très loin d'en être... Ce logiciel fonctionne excellemment, est d'une stabilité remarquable. Il utilise du SSL (OpenSSL), dans une implémentation qui fonctionne également sur UDP (afin d'éviter le fameux problème de l'empilement des couches de correction d'erreur: 2 couches TCP encapsulées l'une dans l'autre, c'est une source potentielle de problèmes, chacune essayant de corriger le tir en faisant des retransmissions, ce qui peut écrouler le lien). Ce n'est cependant pas du DTLS, mais une solution alternative, qui a consisté à re-coder la couche de fiabilité ordinairement apportée par TCP. Vous pouvez utiliser une authentification par clef partagée ou par certificats. Je connais bien cette solution pour l'employer depuis des années (tunnels en fonction depuis 2004).
2) stunnel: jamais utilisé pour ma part en tant que VPN, juste pour établir à la mimine des connexions SSL vers des serveurs web HTTPS, mais il paraît que ça marche bien.
3) OpenSSH: tout à fait utilisable pour établir des tunnels VPN également. Solution de secours que j'ai déjà mise en oeuvre également.
Les solutions 1 (OpenVPN) et 3 (OpenSSH) sont également utilisables en mode VPN couche 2 (à partir de la version 4.3 pour OpenSSH). Pour stunnel, je ne pense pas, mais comme je ne l'ai pas utilisé pour du VPN, je n'ai aucune certitude.
Voilà... Maintenant, vous avez parfaitement le droit de ne pas être d'accord, bien entendu.
Cordialement,
Bruno Tréguier
P.S.: désolé si ce message apparait en plusieurs exemplaires: il semble que j'aie encore un petit souci de fichier "active" à régler, suite à la remise en route de mon serveur INN, j'ai un peu galéré pour poster mon message (mais que fait le newsmaster ? ;-) ), du coup pour l'instant je poste via mon FAI.
Bonjour,
Le 25/02/2011 à 15:30, Yannix a écrit :
Pas la peine: tout a déjà été dit ailleurs. Google est votre ami.
^^^^^^^^
Donc, on se demande à quoi peut bien servir ce NG, n'est-ce pas ?
Bah, ce n'est pas spécifique à ce groupe, je pense... Usenet est en
perte de vitesse, il ne faut pas se le cacher... Je viens de "remonter"
mon serveur ici, suite à quelques demandes d'utilisateurs, mais s'il
n'avait tenu qu'à moi (malgré un peu de nostalgie)... Il était arrêté
depuis plus de 6 mois suite à l'arrêt quasi-simultané de nos 2 feeds.
J'en ai trouvé un autre, merci à l'UBO. ;-)
Beaucoup de choses se passent désormais sur les listes de diffusion, et
je peux vous dire que cette "nouvelle" a été abondamment commentée dans
plusieurs d'entre elles.
Cela dit, ce groupe peut avoir son utilité également, bien sûr, mais
dans le cas de ce "scoop", il s'est dégonflé très rapidement par la suite...
D'ailleurs, n'est-ce pas vous qui, au début de cette année, disiez qu'au
niveau des VPN, en dehors d'IPSec, point de salut ?
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est
compromis, vous voyez quoi comme solution alternative ?
Hmm. Je sens venir la guerre de religion, là. ;-)
Il y en a plusieurs (en dehors de PPTP ;-) ) (liste non exhaustive):
1) OpenVPN: dans la discussion animée de début janvier (le fil
concernait la LOPPSI 2) vous n'aviez pas l'air convaincu par ce
logiciel, que vous avez même qualifié, je crois, de "vaporware". Je peux
vous dire que c'est très loin d'en être... Ce logiciel fonctionne
excellemment, est d'une stabilité remarquable. Il utilise du SSL
(OpenSSL), dans une implémentation qui fonctionne également sur UDP
(afin d'éviter le fameux problème de l'empilement des couches de
correction d'erreur: 2 couches TCP encapsulées l'une dans l'autre, c'est
une source potentielle de problèmes, chacune essayant de corriger le tir
en faisant des retransmissions, ce qui peut écrouler le lien). Ce n'est
cependant pas du DTLS, mais une solution alternative, qui a consisté à
re-coder la couche de fiabilité ordinairement apportée par TCP. Vous
pouvez utiliser une authentification par clef partagée ou par
certificats. Je connais bien cette solution pour l'employer depuis des
années (tunnels en fonction depuis 2004).
2) stunnel: jamais utilisé pour ma part en tant que VPN, juste pour
établir à la mimine des connexions SSL vers des serveurs web HTTPS, mais
il paraît que ça marche bien.
3) OpenSSH: tout à fait utilisable pour établir des tunnels VPN
également. Solution de secours que j'ai déjà mise en oeuvre également.
Les solutions 1 (OpenVPN) et 3 (OpenSSH) sont également utilisables en
mode VPN couche 2 (à partir de la version 4.3 pour OpenSSH). Pour
stunnel, je ne pense pas, mais comme je ne l'ai pas utilisé pour du VPN,
je n'ai aucune certitude.
Voilà... Maintenant, vous avez parfaitement le droit de ne pas être
d'accord, bien entendu.
Cordialement,
Bruno Tréguier
P.S.: désolé si ce message apparait en plusieurs exemplaires: il semble
que j'aie encore un petit souci de fichier "active" à régler, suite à la
remise en route de mon serveur INN, j'ai un peu galéré pour poster mon
message (mais que fait le newsmaster ? ;-) ), du coup pour l'instant je
poste via mon FAI.
Pas la peine: tout a déjà été dit ailleurs. Google est votre ami.
^^^^^^^^ Donc, on se demande à quoi peut bien servir ce NG, n'est-ce pas ?
Bah, ce n'est pas spécifique à ce groupe, je pense... Usenet est en perte de vitesse, il ne faut pas se le cacher... Je viens de "remonter" mon serveur ici, suite à quelques demandes d'utilisateurs, mais s'il n'avait tenu qu'à moi (malgré un peu de nostalgie)... Il était arrêté depuis plus de 6 mois suite à l'arrêt quasi-simultané de nos 2 feeds. J'en ai trouvé un autre, merci à l'UBO. ;-)
Beaucoup de choses se passent désormais sur les listes de diffusion, et je peux vous dire que cette "nouvelle" a été abondamment commentée dans plusieurs d'entre elles.
Cela dit, ce groupe peut avoir son utilité également, bien sûr, mais dans le cas de ce "scoop", il s'est dégonflé très rapidement par la suite...
D'ailleurs, n'est-ce pas vous qui, au début de cette année, disiez qu'au niveau des VPN, en dehors d'IPSec, point de salut ?
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est compromis, vous voyez quoi comme solution alternative ?
Hmm. Je sens venir la guerre de religion, là. ;-)
Il y en a plusieurs (en dehors de PPTP ;-) ) (liste non exhaustive):
1) OpenVPN: dans la discussion animée de début janvier (le fil concernait la LOPPSI 2) vous n'aviez pas l'air convaincu par ce logiciel, que vous avez même qualifié, je crois, de "vaporware". Je peux vous dire que c'est très loin d'en être... Ce logiciel fonctionne excellemment, est d'une stabilité remarquable. Il utilise du SSL (OpenSSL), dans une implémentation qui fonctionne également sur UDP (afin d'éviter le fameux problème de l'empilement des couches de correction d'erreur: 2 couches TCP encapsulées l'une dans l'autre, c'est une source potentielle de problèmes, chacune essayant de corriger le tir en faisant des retransmissions, ce qui peut écrouler le lien). Ce n'est cependant pas du DTLS, mais une solution alternative, qui a consisté à re-coder la couche de fiabilité ordinairement apportée par TCP. Vous pouvez utiliser une authentification par clef partagée ou par certificats. Je connais bien cette solution pour l'employer depuis des années (tunnels en fonction depuis 2004).
2) stunnel: jamais utilisé pour ma part en tant que VPN, juste pour établir à la mimine des connexions SSL vers des serveurs web HTTPS, mais il paraît que ça marche bien.
3) OpenSSH: tout à fait utilisable pour établir des tunnels VPN également. Solution de secours que j'ai déjà mise en oeuvre également.
Les solutions 1 (OpenVPN) et 3 (OpenSSH) sont également utilisables en mode VPN couche 2 (à partir de la version 4.3 pour OpenSSH). Pour stunnel, je ne pense pas, mais comme je ne l'ai pas utilisé pour du VPN, je n'ai aucune certitude.
Voilà... Maintenant, vous avez parfaitement le droit de ne pas être d'accord, bien entendu.
Cordialement,
Bruno Tréguier
P.S.: désolé si ce message apparait en plusieurs exemplaires: il semble que j'aie encore un petit souci de fichier "active" à régler, suite à la remise en route de mon serveur INN, j'ai un peu galéré pour poster mon message (mais que fait le newsmaster ? ;-) ), du coup pour l'instant je poste via mon FAI.
Eric Masson
Bruno Tréguier writes:
'Lut,
1) OpenVPN: 2) stunnel: 3) OpenSSH:
J'ai aussi utilisé SSLTunnel écrit par Titi de chez HSC, très intéressant pour sortir d'un lan où seul l'accès https est disponible (encap ip dans un tunnel https).
C'est loin d'être optimal, mais ça permet de se dépatouiller en présence d'un admin qui bloque tout.
Une autre solution que j'utilise toujours est SSLExplorer/Adito qui permet d'accéder à des services distants de la même manière, la version commerciale de Barracuda Networks permet à l'instar des clients SSL cisco ou Juniper de disposer d'une interface réseau virtuelle routée sur le lan hébergeant le serveur d'accès.
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre chose qu'une implémentation IPSec propre, mais vu le nombre de gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas d'autres solutions que le tunnel sur https qui tient plus du hack que d'une solution murement réfléchie.
-- GG: Je rappelle que la meilleure conversion d'un film vers un jeu vidéo GG: reste celle de Goldeneye, sur N64... FM: Pas d'accord : Windows 95 est une remarquable conversion de Titanic. -+- FM in Guide du Macounet Pervers : Bien convertir son film... -+-
Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> writes:
'Lut,
1) OpenVPN:
2) stunnel:
3) OpenSSH:
J'ai aussi utilisé SSLTunnel écrit par Titi de chez HSC, très
intéressant pour sortir d'un lan où seul l'accès https est disponible
(encap ip dans un tunnel https).
C'est loin d'être optimal, mais ça permet de se dépatouiller en présence
d'un admin qui bloque tout.
Une autre solution que j'utilise toujours est SSLExplorer/Adito qui
permet d'accéder à des services distants de la même manière, la version
commerciale de Barracuda Networks permet à l'instar des clients SSL
cisco ou Juniper de disposer d'une interface réseau virtuelle routée sur
le lan hébergeant le serveur d'accès.
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre
chose qu'une implémentation IPSec propre, mais vu le nombre de
gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas
d'autres solutions que le tunnel sur https qui tient plus du hack que
d'une solution murement réfléchie.
--
GG: Je rappelle que la meilleure conversion d'un film vers un jeu vidéo
GG: reste celle de Goldeneye, sur N64...
FM: Pas d'accord : Windows 95 est une remarquable conversion de Titanic.
-+- FM in Guide du Macounet Pervers : Bien convertir son film... -+-
J'ai aussi utilisé SSLTunnel écrit par Titi de chez HSC, très intéressant pour sortir d'un lan où seul l'accès https est disponible (encap ip dans un tunnel https).
C'est loin d'être optimal, mais ça permet de se dépatouiller en présence d'un admin qui bloque tout.
Une autre solution que j'utilise toujours est SSLExplorer/Adito qui permet d'accéder à des services distants de la même manière, la version commerciale de Barracuda Networks permet à l'instar des clients SSL cisco ou Juniper de disposer d'une interface réseau virtuelle routée sur le lan hébergeant le serveur d'accès.
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre chose qu'une implémentation IPSec propre, mais vu le nombre de gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas d'autres solutions que le tunnel sur https qui tient plus du hack que d'une solution murement réfléchie.
-- GG: Je rappelle que la meilleure conversion d'un film vers un jeu vidéo GG: reste celle de Goldeneye, sur N64... FM: Pas d'accord : Windows 95 est une remarquable conversion de Titanic. -+- FM in Guide du Macounet Pervers : Bien convertir son film... -+-
Bruno Tréguier
Le 25/02/2011 à 21:57, Eric Masson a écrit :
'Lut,
Tiens, un FreeBSDiste... Bonsoir !
1) OpenVPN: 2) stunnel: 3) OpenSSH:
J'ai aussi utilisé SSLTunnel écrit par Titi de chez HSC, très intéressant pour sortir d'un lan où seul l'accès https est disponible (encap ip dans un tunnel https).
Effectivement, j'avais oublié celle-là, comme solution, mais elle est comparable aux autres, le souci principal résidant, encore une fois, en la superposition de 2 couches TCP (d'ailleurs pour ceux qui souhaitent avoir des explications plus complètes sur les problèmes potentiels que ça pose: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html).
C'est loin d'être optimal, mais ça permet de se dépatouiller en présence d'un admin qui bloque tout.
Il y a quelques années, j'avais fait la même chose avec OpenSSH, en forçant le port à 443, sur un réseau sur lequel on n'avait que cette possibilité pour sortir. ;-) Bon, ok, avec un bon firewall qui fait de l'analyse intra-protocolaire et tout, mon flux aurait été rejeté illico, la négo de la connexion SSH n'étant pas du même style que celle de SSL...
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre chose qu'une implémentation IPSec propre, mais vu le nombre de gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas d'autres solutions que le tunnel sur https qui tient plus du hack que d'une solution murement réfléchie.
Une "implémentation IPSec propre", ça existe ? ;-) Je rigole, ça marche bien maintenant, mais j'ai eu par le passé de sérieux problèmes de configuration et de compatibilité entre différentes implémentations (notamment Cisco <-> FreeS/WAN) il y a quelques années (vu le nombre de possibilités: avec ou sans NAT traversal, mode agressif ou pas, mode transport ou tunnel, etc.), et il y a quelques années, SCEP, malgré son initiale, n'était pas vraiment "simple" à mettre en oeuvre.
Bon, comme on a un peu dérivé, là, j'ai changé le titre du fil...
Bonne fin de soirée !
Cordialement,
Bruno Tréguier
Le 25/02/2011 à 21:57, Eric Masson a écrit :
'Lut,
Tiens, un FreeBSDiste... Bonsoir !
1) OpenVPN:
2) stunnel:
3) OpenSSH:
J'ai aussi utilisé SSLTunnel écrit par Titi de chez HSC, très
intéressant pour sortir d'un lan où seul l'accès https est disponible
(encap ip dans un tunnel https).
Effectivement, j'avais oublié celle-là, comme solution, mais elle est
comparable aux autres, le souci principal résidant, encore une fois, en
la superposition de 2 couches TCP (d'ailleurs pour ceux qui souhaitent
avoir des explications plus complètes sur les problèmes potentiels que
ça pose: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html).
C'est loin d'être optimal, mais ça permet de se dépatouiller en présence
d'un admin qui bloque tout.
Il y a quelques années, j'avais fait la même chose avec OpenSSH, en
forçant le port à 443, sur un réseau sur lequel on n'avait que cette
possibilité pour sortir. ;-) Bon, ok, avec un bon firewall qui fait de
l'analyse intra-protocolaire et tout, mon flux aurait été rejeté illico,
la négo de la connexion SSH n'étant pas du même style que celle de SSL...
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre
chose qu'une implémentation IPSec propre, mais vu le nombre de
gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas
d'autres solutions que le tunnel sur https qui tient plus du hack que
d'une solution murement réfléchie.
Une "implémentation IPSec propre", ça existe ? ;-) Je rigole, ça marche
bien maintenant, mais j'ai eu par le passé de sérieux problèmes de
configuration et de compatibilité entre différentes implémentations
(notamment Cisco <-> FreeS/WAN) il y a quelques années (vu le nombre de
possibilités: avec ou sans NAT traversal, mode agressif ou pas, mode
transport ou tunnel, etc.), et il y a quelques années, SCEP, malgré son
initiale, n'était pas vraiment "simple" à mettre en oeuvre.
Bon, comme on a un peu dérivé, là, j'ai changé le titre du fil...
J'ai aussi utilisé SSLTunnel écrit par Titi de chez HSC, très intéressant pour sortir d'un lan où seul l'accès https est disponible (encap ip dans un tunnel https).
Effectivement, j'avais oublié celle-là, comme solution, mais elle est comparable aux autres, le souci principal résidant, encore une fois, en la superposition de 2 couches TCP (d'ailleurs pour ceux qui souhaitent avoir des explications plus complètes sur les problèmes potentiels que ça pose: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html).
C'est loin d'être optimal, mais ça permet de se dépatouiller en présence d'un admin qui bloque tout.
Il y a quelques années, j'avais fait la même chose avec OpenSSH, en forçant le port à 443, sur un réseau sur lequel on n'avait que cette possibilité pour sortir. ;-) Bon, ok, avec un bon firewall qui fait de l'analyse intra-protocolaire et tout, mon flux aurait été rejeté illico, la négo de la connexion SSH n'étant pas du même style que celle de SSL...
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre chose qu'une implémentation IPSec propre, mais vu le nombre de gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas d'autres solutions que le tunnel sur https qui tient plus du hack que d'une solution murement réfléchie.
Une "implémentation IPSec propre", ça existe ? ;-) Je rigole, ça marche bien maintenant, mais j'ai eu par le passé de sérieux problèmes de configuration et de compatibilité entre différentes implémentations (notamment Cisco <-> FreeS/WAN) il y a quelques années (vu le nombre de possibilités: avec ou sans NAT traversal, mode agressif ou pas, mode transport ou tunnel, etc.), et il y a quelques années, SCEP, malgré son initiale, n'était pas vraiment "simple" à mettre en oeuvre.
Bon, comme on a un peu dérivé, là, j'ai changé le titre du fil...
Bonne fin de soirée !
Cordialement,
Bruno Tréguier
Tonton Th
On 02/25/2011 03:30 PM, Yannix wrote:
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est compromis, vous voyez quoi comme solution alternative ?
Des pigeons voyageurs, dopés à la cocaïne. Il doit bien exister une RFC...
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 02/25/2011 03:30 PM, Yannix wrote:
Heu, je m'en rappelle pas, mais c'est très possible. Si IPSec est
compromis, vous voyez quoi comme solution alternative ?
Des pigeons voyageurs, dopés à la cocaïne. Il doit bien
exister une RFC...
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Des pigeons voyageurs, dopés à la cocaïne. Il doit bien exister une RFC...
Tout à fait: http://www.rfc1149.net/rfc1149.html
Mais là on n'a pas la sécurité. 2549 apporte la QOS, mais il faudrait étendre pour avoir IPSec.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Erwan David
Eric Masson écrivait :
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre chose qu'une implémentation IPSec propre, mais vu le nombre de gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas d'autres solutions que le tunnel sur https qui tient plus du hack que d'une solution murement réfléchie.
Note aussi que sur un site bien tenu avecdes données confidentielles, il est plus que normal que les admins bloquent les tunnels...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Eric Masson <emss@free.fr> écrivait :
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre
chose qu'une implémentation IPSec propre, mais vu le nombre de
gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas
d'autres solutions que le tunnel sur https qui tient plus du hack que
d'une solution murement réfléchie.
Note aussi que sur un site bien tenu avecdes données confidentielles, il
est plus que normal que les admins bloquent les tunnels...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Bref, dans un monde parfait, on ne devrait pas avoir besoin d'autre chose qu'une implémentation IPSec propre, mais vu le nombre de gougnaffiers s'occupant "d'administration réseau", il n'y a parfois pas d'autres solutions que le tunnel sur https qui tient plus du hack que d'une solution murement réfléchie.
Note aussi que sur un site bien tenu avecdes données confidentielles, il est plus que normal que les admins bloquent les tunnels...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Eric Masson
Erwan David writes:
'Lut,
Note aussi que sur un site bien tenu avecdes données confidentielles, il est plus que normal que les admins bloquent les tunnels...
Je te l'accorde, mais dans ce cas, fournir à des consultants externes un lien déconnecté du wan interne qui leur permettra l'accès aux ressources externes dont ils peuvent avoir besoin n'est pas non plus complètement idiot.
-- Il n'est pas nécessaire de me faire remarquer que j'en fais (des fautes). Je le sais, et j'essaye de les limier autant que faire se peut. -+- J in Guide du Neuneu sur Usenet : Le limier manque de flair -+-
Erwan David <erwan@rail.eu.org> writes:
'Lut,
Note aussi que sur un site bien tenu avecdes données confidentielles,
il est plus que normal que les admins bloquent les tunnels...
Je te l'accorde, mais dans ce cas, fournir à des consultants externes
un lien déconnecté du wan interne qui leur permettra l'accès aux
ressources externes dont ils peuvent avoir besoin n'est pas non plus
complètement idiot.
--
Il n'est pas nécessaire de me faire remarquer que j'en fais (des
fautes). Je le sais, et j'essaye de les limier autant que faire se
peut.
-+- J in Guide du Neuneu sur Usenet : Le limier manque de flair -+-
Note aussi que sur un site bien tenu avecdes données confidentielles, il est plus que normal que les admins bloquent les tunnels...
Je te l'accorde, mais dans ce cas, fournir à des consultants externes un lien déconnecté du wan interne qui leur permettra l'accès aux ressources externes dont ils peuvent avoir besoin n'est pas non plus complètement idiot.
-- Il n'est pas nécessaire de me faire remarquer que j'en fais (des fautes). Je le sais, et j'essaye de les limier autant que faire se peut. -+- J in Guide du Neuneu sur Usenet : Le limier manque de flair -+-
Eric Masson
Bruno Tréguier writes:
'Lut,
Effectivement, j'avais oublié celle-là, comme solution, mais elle est comparable aux autres, le souci principal résidant, encore une fois, en la superposition de 2 couches TCP (d'ailleurs pour ceux qui souhaitent avoir des explications plus complètes sur les problèmes potentiels que ça pose: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html).
Tout à fait d'accord, c'est moisi dans le principe, mais ça dépanne.
Il y a quelques années, j'avais fait la même chose avec OpenSSH, en forçant le port à 443, sur un réseau sur lequel on n'avait que cette possibilité pour sortir. ;-) Bon, ok, avec un bon firewall qui fait de l'analyse intra-protocolaire et tout, mon flux aurait été rejeté illico, la négo de la connexion SSH n'étant pas du même style que celle de SSL...
L'intérêt de SSLTunnel & SSLExplorer/Adito est justement que la négociation est conforme à ce que peut attendre un IDS ou tout autre dispositif de filtrage.
Une "implémentation IPSec propre", ça existe ? ;-) Je rigole, ça marche bien maintenant, mais j'ai eu par le passé de sérieux problèmes de configuration et de compatibilité entre différentes implémentations (notamment Cisco <-> FreeS/WAN)
Ce fut sport à une époque, c'est clair, pour ma part, je pratique Open/isakmpd & Free/racoon (enfin ipsec-tools depuis un certain temps déjà) et à l'exception de quelques implémentations propriétaires bien moisies, je n'ai pas eu de problèmes depuis une bonne dizaine d'années.
Enfin si, j'ai toujours un souci entre un Open/isakmpd en 4.6 et une saleté de chez Bintec, mais bon, vu que d'autres prestataires ont des soucis similaires que ce soit avec des appliances Juniper ou des linux/openswan...
Enfin, l'interopérabilité entre les piles n'est plus vraiment problématique actuellement, et c'est dommage de ne pas utiliser une technologie vraiment adaptée au besoin.
-- L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier
Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> writes:
'Lut,
Effectivement, j'avais oublié celle-là, comme solution, mais elle est
comparable aux autres, le souci principal résidant, encore une fois, en
la superposition de 2 couches TCP (d'ailleurs pour ceux qui souhaitent
avoir des explications plus complètes sur les problèmes potentiels que
ça pose: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html).
Tout à fait d'accord, c'est moisi dans le principe, mais ça dépanne.
Il y a quelques années, j'avais fait la même chose avec OpenSSH, en
forçant le port à 443, sur un réseau sur lequel on n'avait que cette
possibilité pour sortir. ;-) Bon, ok, avec un bon firewall qui fait de
l'analyse intra-protocolaire et tout, mon flux aurait été rejeté illico,
la négo de la connexion SSH n'étant pas du même style que celle de SSL...
L'intérêt de SSLTunnel & SSLExplorer/Adito est justement que la
négociation est conforme à ce que peut attendre un IDS ou tout autre
dispositif de filtrage.
Une "implémentation IPSec propre", ça existe ? ;-) Je rigole, ça marche
bien maintenant, mais j'ai eu par le passé de sérieux problèmes de
configuration et de compatibilité entre différentes implémentations
(notamment Cisco <-> FreeS/WAN)
Ce fut sport à une époque, c'est clair, pour ma part, je pratique
Open/isakmpd & Free/racoon (enfin ipsec-tools depuis un certain temps
déjà) et à l'exception de quelques implémentations propriétaires bien
moisies, je n'ai pas eu de problèmes depuis une bonne dizaine d'années.
Enfin si, j'ai toujours un souci entre un Open/isakmpd en 4.6 et une
saleté de chez Bintec, mais bon, vu que d'autres prestataires ont des
soucis similaires que ce soit avec des appliances Juniper ou des
linux/openswan...
Enfin, l'interopérabilité entre les piles n'est plus vraiment
problématique actuellement, et c'est dommage de ne pas utiliser une
technologie vraiment adaptée au besoin.
--
L'IRQ a été inventée par Murphy ;
le partage des IRQ, par quelqu'un voulant le defier
Effectivement, j'avais oublié celle-là, comme solution, mais elle est comparable aux autres, le souci principal résidant, encore une fois, en la superposition de 2 couches TCP (d'ailleurs pour ceux qui souhaitent avoir des explications plus complètes sur les problèmes potentiels que ça pose: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html).
Tout à fait d'accord, c'est moisi dans le principe, mais ça dépanne.
Il y a quelques années, j'avais fait la même chose avec OpenSSH, en forçant le port à 443, sur un réseau sur lequel on n'avait que cette possibilité pour sortir. ;-) Bon, ok, avec un bon firewall qui fait de l'analyse intra-protocolaire et tout, mon flux aurait été rejeté illico, la négo de la connexion SSH n'étant pas du même style que celle de SSL...
L'intérêt de SSLTunnel & SSLExplorer/Adito est justement que la négociation est conforme à ce que peut attendre un IDS ou tout autre dispositif de filtrage.
Une "implémentation IPSec propre", ça existe ? ;-) Je rigole, ça marche bien maintenant, mais j'ai eu par le passé de sérieux problèmes de configuration et de compatibilité entre différentes implémentations (notamment Cisco <-> FreeS/WAN)
Ce fut sport à une époque, c'est clair, pour ma part, je pratique Open/isakmpd & Free/racoon (enfin ipsec-tools depuis un certain temps déjà) et à l'exception de quelques implémentations propriétaires bien moisies, je n'ai pas eu de problèmes depuis une bonne dizaine d'années.
Enfin si, j'ai toujours un souci entre un Open/isakmpd en 4.6 et une saleté de chez Bintec, mais bon, vu que d'autres prestataires ont des soucis similaires que ce soit avec des appliances Juniper ou des linux/openswan...
Enfin, l'interopérabilité entre les piles n'est plus vraiment problématique actuellement, et c'est dommage de ne pas utiliser une technologie vraiment adaptée au besoin.
-- L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier
