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.
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.
Toutafé.
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.
C'est sûr. Mais pendant longtemps, IPSec m'a vraiment fait l'effet d'un marteau pilon pour écraser les mouches...
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait que les flux soient un peu "connotés". Je ne crois pas à la sécurité par l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de montrer trop facilement lesquels correspondent à des infos chiffrées, je ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas facilement attaquable (quoique, en déni de service), mais ça peut révéler des adresses IP sensibles à chaque bout de la liaison...
Cela dit, quand on voit du TCP sur port 22, 443, 465, 993 ou autre, on peut aussi avoir le même raisonnement que quand c'est du protocole 50 ou de l'UDP sur 500 ou 4500, après tout. ;-)
Cordialement,
Bruno Tréguier
Bonjour,
Le 26/02/2011 à 14:13, Eric Masson a écrit :
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.
Toutafé.
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.
C'est sûr. Mais pendant longtemps, IPSec m'a vraiment fait l'effet d'un
marteau pilon pour écraser les mouches...
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter
sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait
que les flux soient un peu "connotés". Je ne crois pas à la sécurité par
l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de
montrer trop facilement lesquels correspondent à des infos chiffrées, je
ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas
facilement attaquable (quoique, en déni de service), mais ça peut
révéler des adresses IP sensibles à chaque bout de la liaison...
Cela dit, quand on voit du TCP sur port 22, 443, 465, 993 ou autre, on
peut aussi avoir le même raisonnement que quand c'est du protocole 50 ou
de l'UDP sur 500 ou 4500, après tout. ;-)
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.
Toutafé.
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.
C'est sûr. Mais pendant longtemps, IPSec m'a vraiment fait l'effet d'un marteau pilon pour écraser les mouches...
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait que les flux soient un peu "connotés". Je ne crois pas à la sécurité par l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de montrer trop facilement lesquels correspondent à des infos chiffrées, je ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas facilement attaquable (quoique, en déni de service), mais ça peut révéler des adresses IP sensibles à chaque bout de la liaison...
Cela dit, quand on voit du TCP sur port 22, 443, 465, 993 ou autre, on peut aussi avoir le même raisonnement que quand c'est du protocole 50 ou de l'UDP sur 500 ou 4500, après tout. ;-)
Cordialement,
Bruno Tréguier
yamo'
Salut,
Bruno Tréguier a tapoté, le 25/02/2011 21:28:
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.
J'ai bien reçu l'autre, sur free on dirait qu'il n'apparaît pas!
-- Stéphane
<http://pasdenom.info/fortune/>
Salut,
Bruno Tréguier a tapoté, le 25/02/2011 21:28:
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.
J'ai bien reçu l'autre, sur free on dirait qu'il n'apparaît pas!
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.
J'ai bien reçu l'autre, sur free on dirait qu'il n'apparaît pas!
-- Stéphane
<http://pasdenom.info/fortune/>
Yannix
Le 26/02/2011 12:40, Eric Masson a écrit :
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.
C'est quoi un "lien déconnecté du wan interne qui permets l'accès aux ressources externes" ?
Merci d'avance.
X.
Le 26/02/2011 12:40, Eric Masson a écrit :
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.
C'est quoi un "lien déconnecté du wan interne qui permets l'accès aux
ressources externes" ?
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.
C'est quoi un "lien déconnecté du wan interne qui permets l'accès aux ressources externes" ?
Merci d'avance.
X.
Yannix
Le 25/02/2011 22:45, Bruno Tréguier a écrit :
Salut,
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.
Oui, c'est vrai (et cela ne nous rajeunit pas!). Mais bon, en tatonnant, on arrivait à trouver la bonne combinaison, pour marier les deux routeurs, non ?
IPSec, quoi que tu en penses, reste un standard incontournable question VPN.
A+
X.
Le 25/02/2011 22:45, Bruno Tréguier a écrit :
Salut,
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.
Oui, c'est vrai (et cela ne nous rajeunit pas!). Mais bon, en tatonnant,
on arrivait à trouver la bonne combinaison, pour marier les deux
routeurs, non ?
IPSec, quoi que tu en penses, reste un standard incontournable question VPN.
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.
Oui, c'est vrai (et cela ne nous rajeunit pas!). Mais bon, en tatonnant, on arrivait à trouver la bonne combinaison, pour marier les deux routeurs, non ?
IPSec, quoi que tu en penses, reste un standard incontournable question VPN.
A+
X.
Yannix
Le 25/02/2011 17:42, Bruno Treguier a écrit :
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.
Beaucoup de choses se sont toujours passées sur les mailing listes et en dehors de usenet. La différence essentielle des mailings listes avec usenet, c'est le coté centralisateur avec des choses comme mailman qui permettent de restreindre la diffusion, contrairement à usenet qui a vocation à être non-modéré, public, mondialement diffusé et ceci de façon décentralisée et sans censure possible.
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...
Notez bien que cette histoire de "Greg Perry" qui dénonce (sans preuve) un autre dev pue la désinformation. Ca permet en tout cas de juger de la crédibilité des médias informatiques. C'est un genre de "Charniers de Timişoara" pour la presse informatique en quelque sorte ...
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.
Mais je ne fais que constater : Dans des organisations ayant une certaine taille, c'est du client VPN Cisco (IPSec) sur les clients nomades avec un "concentrateur" Cisco à l'autre bout. Pour les liaisons VPN site à site, c'est l'opérateur telecom qui le fait en vendant du "VPN IP", généralement grâce à du matos Cisco. Je ne dis pas que c'est la panacée universelle, je dis juste que c'est ce qui est utilisé à 95% dans ce genre de cas et je vous laisse en tirer les conclusions qu'il vous plait ;-)
A+
X.
Le 25/02/2011 17:42, Bruno Treguier a écrit :
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.
Beaucoup de choses se sont toujours passées sur les mailing listes et en
dehors de usenet. La différence essentielle des mailings listes avec
usenet, c'est le coté centralisateur avec des choses comme mailman qui
permettent de restreindre la diffusion, contrairement à usenet qui a
vocation à être non-modéré, public, mondialement diffusé et ceci de
façon décentralisée et sans censure possible.
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...
Notez bien que cette histoire de "Greg Perry" qui dénonce (sans preuve)
un autre dev pue la désinformation. Ca permet en tout cas de juger de la
crédibilité des médias informatiques. C'est un genre de "Charniers de
Timişoara" pour la presse informatique en quelque sorte ...
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.
Mais je ne fais que constater : Dans des organisations ayant une
certaine taille, c'est du client VPN Cisco (IPSec) sur les clients
nomades avec un "concentrateur" Cisco à l'autre bout. Pour les liaisons
VPN site à site, c'est l'opérateur telecom qui le fait en vendant du
"VPN IP", généralement grâce à du matos Cisco. Je ne dis pas que c'est
la panacée universelle, je dis juste que c'est ce qui est utilisé à 95%
dans ce genre de cas et je vous laisse en tirer les conclusions qu'il
vous plait ;-)
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.
Beaucoup de choses se sont toujours passées sur les mailing listes et en dehors de usenet. La différence essentielle des mailings listes avec usenet, c'est le coté centralisateur avec des choses comme mailman qui permettent de restreindre la diffusion, contrairement à usenet qui a vocation à être non-modéré, public, mondialement diffusé et ceci de façon décentralisée et sans censure possible.
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...
Notez bien que cette histoire de "Greg Perry" qui dénonce (sans preuve) un autre dev pue la désinformation. Ca permet en tout cas de juger de la crédibilité des médias informatiques. C'est un genre de "Charniers de Timişoara" pour la presse informatique en quelque sorte ...
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.
Mais je ne fais que constater : Dans des organisations ayant une certaine taille, c'est du client VPN Cisco (IPSec) sur les clients nomades avec un "concentrateur" Cisco à l'autre bout. Pour les liaisons VPN site à site, c'est l'opérateur telecom qui le fait en vendant du "VPN IP", généralement grâce à du matos Cisco. Je ne dis pas que c'est la panacée universelle, je dis juste que c'est ce qui est utilisé à 95% dans ce genre de cas et je vous laisse en tirer les conclusions qu'il vous plait ;-)
A+
X.
Yannix
Le 26/02/2011 17:26, Bruno Tréguier a écrit :
Bonjour,
Salut,
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait que les flux soient un peu "connotés". Je ne crois pas à la sécurité par l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de montrer trop facilement lesquels correspondent à des infos chiffrées, je ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas facilement attaquable (quoique, en déni de service), mais ça peut révéler des adresses IP sensibles à chaque bout de la liaison...
Et tes solutions alternatives résolvent ce "problème" ou pas ?
A+
X.
Le 26/02/2011 17:26, Bruno Tréguier a écrit :
Bonjour,
Salut,
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter
sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait
que les flux soient un peu "connotés". Je ne crois pas à la sécurité par
l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de
montrer trop facilement lesquels correspondent à des infos chiffrées, je
ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas
facilement attaquable (quoique, en déni de service), mais ça peut
révéler des adresses IP sensibles à chaque bout de la liaison...
Et tes solutions alternatives résolvent ce "problème" ou pas ?
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait que les flux soient un peu "connotés". Je ne crois pas à la sécurité par l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de montrer trop facilement lesquels correspondent à des infos chiffrées, je ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas facilement attaquable (quoique, en déni de service), mais ça peut révéler des adresses IP sensibles à chaque bout de la liaison...
Et tes solutions alternatives résolvent ce "problème" ou pas ?
A+
X.
Yannix
Le 26/02/2011 10:23, Erwan David a écrit :
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...
Sur un LAN bien tenu avec des données vraiment confidentielles, les admins bloquent tout simplement l'accès à internet. C'est une règle de bon sens.
A+
X.
Le 26/02/2011 10:23, Erwan David a écrit :
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...
Sur un LAN bien tenu avec des données vraiment confidentielles, les
admins bloquent tout simplement l'accès à internet. C'est une règle de
bon sens.
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...
Sur un LAN bien tenu avec des données vraiment confidentielles, les admins bloquent tout simplement l'accès à internet. C'est une règle de bon sens.
A+
X.
Bruno Tréguier
Le 27/02/2011 à 16:30, Yannix a écrit :
Le 26/02/2011 17:26, Bruno Tréguier a écrit :
Bonjour,
Salut,
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait que les flux soient un peu "connotés". Je ne crois pas à la sécurité par l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de montrer trop facilement lesquels correspondent à des infos chiffrées, je ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas facilement attaquable (quoique, en déni de service), mais ça peut révéler des adresses IP sensibles à chaque bout de la liaison...
Et tes solutions alternatives résolvent ce "problème" ou pas ?
Bonjour,
Oui et non. Il n'y a pas de solution idéale, bien entendu, mais par exemple, OpenVPN peut fonctionner sur n'importe quel port (en TCP ou en UDP, bien que ce dernier mode soit préféré toujours pour les mêmes raisons: sinon on empile des couches TCP). Cela permet d'établir un tunnel entre port arbitraire sur une machine A, et un autre port arbitraire sur une machine B. C'est peut-être un tout petit peu plus discret qu'un trafic IPSec, mais à peine.
En revanche, une particularité qui peut avoir un intérêt est la suivante: pour quelqu'un qui n'est pas sur le trajet des données, la présence d'un serveur OpenVPN est beaucoup plus difficile à établir avec les ports source et destination variables, que quand l'échange a toujours lieu sur un port connu et depuis un port connu (en l'occurrence 500, pour IKE). Dans le cas d'OpenVPN, donc, il vous faut causer *sur* le bon port, *depuis* le bon port, sans les connaître à l'avance, pour espérer avoir une réponse. Scanner une machine à la recherche d'un éventuel serveur OpenVPN est donc beaucoup plus long que pour un serveur IPSec...
Là encore ce n'est qu'un avantage minime, mais bon...
Cordialement,
Bruno Tréguier
Le 27/02/2011 à 16:30, Yannix a écrit :
Le 26/02/2011 17:26, Bruno Tréguier a écrit :
Bonjour,
Salut,
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter
sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait
que les flux soient un peu "connotés". Je ne crois pas à la sécurité par
l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de
montrer trop facilement lesquels correspondent à des infos chiffrées, je
ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas
facilement attaquable (quoique, en déni de service), mais ça peut
révéler des adresses IP sensibles à chaque bout de la liaison...
Et tes solutions alternatives résolvent ce "problème" ou pas ?
Bonjour,
Oui et non. Il n'y a pas de solution idéale, bien entendu, mais par
exemple, OpenVPN peut fonctionner sur n'importe quel port (en TCP ou en
UDP, bien que ce dernier mode soit préféré toujours pour les mêmes
raisons: sinon on empile des couches TCP). Cela permet d'établir un
tunnel entre port arbitraire sur une machine A, et un autre port
arbitraire sur une machine B. C'est peut-être un tout petit peu plus
discret qu'un trafic IPSec, mais à peine.
En revanche, une particularité qui peut avoir un intérêt est la
suivante: pour quelqu'un qui n'est pas sur le trajet des données, la
présence d'un serveur OpenVPN est beaucoup plus difficile à établir avec
les ports source et destination variables, que quand l'échange a
toujours lieu sur un port connu et depuis un port connu (en l'occurrence
500, pour IKE). Dans le cas d'OpenVPN, donc, il vous faut causer *sur*
le bon port, *depuis* le bon port, sans les connaître à l'avance, pour
espérer avoir une réponse. Scanner une machine à la recherche d'un
éventuel serveur OpenVPN est donc beaucoup plus long que pour un serveur
IPSec...
Là encore ce n'est qu'un avantage minime, mais bon...
L'avantage désormais c'est qu'à peu près tout ce qui peut se connecter sur un réseau possède une implémentation IPSec.
Un petit truc qui me gêne (mais c'est mineur) avec IPSec, c'est le fait que les flux soient un peu "connotés". Je ne crois pas à la sécurité par l'obscurité, mais si dans un ensemble de flux réseaux on peut éviter de montrer trop facilement lesquels correspondent à des infos chiffrées, je ne suis pas contre. Bon, bien sûr, c'est chiffré, donc a priori pas facilement attaquable (quoique, en déni de service), mais ça peut révéler des adresses IP sensibles à chaque bout de la liaison...
Et tes solutions alternatives résolvent ce "problème" ou pas ?
Bonjour,
Oui et non. Il n'y a pas de solution idéale, bien entendu, mais par exemple, OpenVPN peut fonctionner sur n'importe quel port (en TCP ou en UDP, bien que ce dernier mode soit préféré toujours pour les mêmes raisons: sinon on empile des couches TCP). Cela permet d'établir un tunnel entre port arbitraire sur une machine A, et un autre port arbitraire sur une machine B. C'est peut-être un tout petit peu plus discret qu'un trafic IPSec, mais à peine.
En revanche, une particularité qui peut avoir un intérêt est la suivante: pour quelqu'un qui n'est pas sur le trajet des données, la présence d'un serveur OpenVPN est beaucoup plus difficile à établir avec les ports source et destination variables, que quand l'échange a toujours lieu sur un port connu et depuis un port connu (en l'occurrence 500, pour IKE). Dans le cas d'OpenVPN, donc, il vous faut causer *sur* le bon port, *depuis* le bon port, sans les connaître à l'avance, pour espérer avoir une réponse. Scanner une machine à la recherche d'un éventuel serveur OpenVPN est donc beaucoup plus long que pour un serveur IPSec...
Là encore ce n'est qu'un avantage minime, mais bon...
