Je souhaiterais savoir s'il existe une quelconque application utilisant
exclusivement IPSec pour ses communications, et non TLS/SSL habituellement
utilisé pour le chiffrement des communications applicatives, et si oui
lequel ?
La question sous-jacente est : est-il possible d'utiliser IPSec pour
chiffrer les flux d'une seule application sans avoir à créer une interface
virtuelle au niveau de l'OS et que n'importe quelle application pourrait
utiliser ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Masson
"gg" writes:
'Lut,
Je souhaiterais savoir s'il existe une quelconque application utilisant exclusivement IPSec pour ses communications,
IPSec est une fonctionnalité de niveau réseau, qui n'a donc rien à voir avec le niveau application.
Une application peut toutefois modifier la SPD (*) de l'hôte sur lequel elle se trouve si elle dispose des droits et du code nécessaires.
La question sous-jacente est : est-il possible d'utiliser IPSec pour chiffrer les flux d'une seule application sans avoir à créer une interface virtuelle au niveau de l'OS et que n'importe quelle application pourrait utiliser ?
Dans le cadre d'une implémentation dérivé de celle de KAME (linux 2.6, DragonFlyBSD, FreeBSD, NetBSD, linux 2.4 avec backport debian), il est possible via setkey de spécifier, via des sélecteurs, quel trafic doit être soumis à transformation ipsec (voir spdadd) : http://www.die.net/doc/linux/man/man8/setkey.8.html
La même fonctionnalité est disponible sous OpenBSD, même si les utilitaires de configuration sont différents (il y a eu du changement récemment dans ce domaine)
Windows XP semble disposer des mêmes fonctionnalités via la configuration d'un filtre dans une politique de sécurité IPSEC (à configurer via un plugin dans la MMC)
Bref, la doc ipsec de l'os utilisé devrait fournir les infos nécessaires.
* : Security Policy Database -- Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour fonctionner,à force,en France de refuser tout rapport sain avec l'argent,l'on riqsque de tuer ce nouvel outil. -+- AA in: <http://www.le-gnu.net> - Le netétiquette du riche -+-
"gg" <gg@voila.Fr> writes:
'Lut,
Je souhaiterais savoir s'il existe une quelconque application utilisant
exclusivement IPSec pour ses communications,
IPSec est une fonctionnalité de niveau réseau, qui n'a donc rien à voir
avec le niveau application.
Une application peut toutefois modifier la SPD (*) de l'hôte sur lequel
elle se trouve si elle dispose des droits et du code nécessaires.
La question sous-jacente est : est-il possible d'utiliser IPSec pour
chiffrer les flux d'une seule application sans avoir à créer une interface
virtuelle au niveau de l'OS et que n'importe quelle application pourrait
utiliser ?
Dans le cadre d'une implémentation dérivé de celle de KAME (linux 2.6,
DragonFlyBSD, FreeBSD, NetBSD, linux 2.4 avec backport debian), il est
possible via setkey de spécifier, via des sélecteurs, quel trafic doit
être soumis à transformation ipsec (voir spdadd) :
http://www.die.net/doc/linux/man/man8/setkey.8.html
La même fonctionnalité est disponible sous OpenBSD, même si les
utilitaires de configuration sont différents (il y a eu du changement
récemment dans ce domaine)
Windows XP semble disposer des mêmes fonctionnalités via la
configuration d'un filtre dans une politique de sécurité IPSEC (à
configurer via un plugin dans la MMC)
Bref, la doc ipsec de l'os utilisé devrait fournir les infos
nécessaires.
* : Security Policy Database
--
Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour
fonctionner,à force,en France de refuser tout rapport sain avec
l'argent,l'on riqsque de tuer ce nouvel outil.
-+- AA in: <http://www.le-gnu.net> - Le netétiquette du riche -+-
Je souhaiterais savoir s'il existe une quelconque application utilisant exclusivement IPSec pour ses communications,
IPSec est une fonctionnalité de niveau réseau, qui n'a donc rien à voir avec le niveau application.
Une application peut toutefois modifier la SPD (*) de l'hôte sur lequel elle se trouve si elle dispose des droits et du code nécessaires.
La question sous-jacente est : est-il possible d'utiliser IPSec pour chiffrer les flux d'une seule application sans avoir à créer une interface virtuelle au niveau de l'OS et que n'importe quelle application pourrait utiliser ?
Dans le cadre d'une implémentation dérivé de celle de KAME (linux 2.6, DragonFlyBSD, FreeBSD, NetBSD, linux 2.4 avec backport debian), il est possible via setkey de spécifier, via des sélecteurs, quel trafic doit être soumis à transformation ipsec (voir spdadd) : http://www.die.net/doc/linux/man/man8/setkey.8.html
La même fonctionnalité est disponible sous OpenBSD, même si les utilitaires de configuration sont différents (il y a eu du changement récemment dans ce domaine)
Windows XP semble disposer des mêmes fonctionnalités via la configuration d'un filtre dans une politique de sécurité IPSEC (à configurer via un plugin dans la MMC)
Bref, la doc ipsec de l'os utilisé devrait fournir les infos nécessaires.
* : Security Policy Database -- Le netétiquette n'est qu'une vaste fumisterie,il faut de l'argent pour fonctionner,à force,en France de refuser tout rapport sain avec l'argent,l'on riqsque de tuer ce nouvel outil. -+- AA in: <http://www.le-gnu.net> - Le netétiquette du riche -+-
Vincent Bernat
OoO Lors de la soirée naissante du jeudi 13 juillet 2006, vers 18:14, "gg" disait:
Je souhaiterais savoir s'il existe une quelconque application utilisant exclusivement IPSec pour ses communications, et non TLS/SSL habituellement utilisé pour le chiffrement des communications applicatives, et si oui lequel ?
La question sous-jacente est : est-il possible d'utiliser IPSec pour chiffrer les flux d'une seule application sans avoir à créer une interface virtuelle au niveau de l'OS et que n'importe quelle application pourrait utiliser ?
Contrairement à TLS/SSL qui travaillent juste sous la couche applicative, IPsec travaille au niveau IP. Une application n'a pas à interagir directement avec lui mais doit utiliser les services du système d'exploitation (via TCP ou UDP).
Sous Linux 2.6, il n'y a pas d'interface virtuelle pour IPsec. Une politique de sécurité détermine ce qui doit ou pas passer dans le tunnel IPsec. Je crois me souvenir qu'il est possible pour les applications de spécifier si elles souhaitent ou non passer par ce tunnel IPsec. Ce serait utilisé par exemple pour les clients DHCP ou simplement les démons ISAKMPd. Je suppose que les sources de racoon peuvent éclairer sur ce point.
À noter par rapport à ce que tu dis, que la politique du système sous Linux 2.6 ne permet pas de travailler au niveau des applications. Si par contre, tu trouves quel appel système permet de demander le chiffrement IPsec, tu peux réécrire l'appel système bind() (ou un autre) pour qu'il fasse appel automatiquement à l'appel système découvert (je suppose que c'est setsockopt() avec une option particulière). -- /* * We used to try various strange things. Let's not. */ 2.2.16 /usr/src/linux/fs/buffer.c
OoO Lors de la soirée naissante du jeudi 13 juillet 2006, vers 18:14,
"gg" <gg@voila.Fr> disait:
Je souhaiterais savoir s'il existe une quelconque application utilisant
exclusivement IPSec pour ses communications, et non TLS/SSL habituellement
utilisé pour le chiffrement des communications applicatives, et si oui
lequel ?
La question sous-jacente est : est-il possible d'utiliser IPSec pour
chiffrer les flux d'une seule application sans avoir à créer une interface
virtuelle au niveau de l'OS et que n'importe quelle application pourrait
utiliser ?
Contrairement à TLS/SSL qui travaillent juste sous la couche
applicative, IPsec travaille au niveau IP. Une application n'a pas à
interagir directement avec lui mais doit utiliser les services du
système d'exploitation (via TCP ou UDP).
Sous Linux 2.6, il n'y a pas d'interface virtuelle pour IPsec. Une
politique de sécurité détermine ce qui doit ou pas passer dans le
tunnel IPsec. Je crois me souvenir qu'il est possible pour les
applications de spécifier si elles souhaitent ou non passer par ce
tunnel IPsec. Ce serait utilisé par exemple pour les clients DHCP ou
simplement les démons ISAKMPd. Je suppose que les sources de racoon
peuvent éclairer sur ce point.
À noter par rapport à ce que tu dis, que la politique du système sous
Linux 2.6 ne permet pas de travailler au niveau des applications. Si
par contre, tu trouves quel appel système permet de demander le
chiffrement IPsec, tu peux réécrire l'appel système bind() (ou un
autre) pour qu'il fasse appel automatiquement à l'appel système
découvert (je suppose que c'est setsockopt() avec une option
particulière).
--
/*
* We used to try various strange things. Let's not.
*/
2.2.16 /usr/src/linux/fs/buffer.c
OoO Lors de la soirée naissante du jeudi 13 juillet 2006, vers 18:14, "gg" disait:
Je souhaiterais savoir s'il existe une quelconque application utilisant exclusivement IPSec pour ses communications, et non TLS/SSL habituellement utilisé pour le chiffrement des communications applicatives, et si oui lequel ?
La question sous-jacente est : est-il possible d'utiliser IPSec pour chiffrer les flux d'une seule application sans avoir à créer une interface virtuelle au niveau de l'OS et que n'importe quelle application pourrait utiliser ?
Contrairement à TLS/SSL qui travaillent juste sous la couche applicative, IPsec travaille au niveau IP. Une application n'a pas à interagir directement avec lui mais doit utiliser les services du système d'exploitation (via TCP ou UDP).
Sous Linux 2.6, il n'y a pas d'interface virtuelle pour IPsec. Une politique de sécurité détermine ce qui doit ou pas passer dans le tunnel IPsec. Je crois me souvenir qu'il est possible pour les applications de spécifier si elles souhaitent ou non passer par ce tunnel IPsec. Ce serait utilisé par exemple pour les clients DHCP ou simplement les démons ISAKMPd. Je suppose que les sources de racoon peuvent éclairer sur ce point.
À noter par rapport à ce que tu dis, que la politique du système sous Linux 2.6 ne permet pas de travailler au niveau des applications. Si par contre, tu trouves quel appel système permet de demander le chiffrement IPsec, tu peux réécrire l'appel système bind() (ou un autre) pour qu'il fasse appel automatiquement à l'appel système découvert (je suppose que c'est setsockopt() avec une option particulière). -- /* * We used to try various strange things. Let's not. */ 2.2.16 /usr/src/linux/fs/buffer.c
gg
"Vincent Bernat" a écrit dans le message de news:
OoO Lors de la soirée naissante du jeudi 13 juillet 2006, vers 18:14, "gg" disait:
Je souhaiterais savoir s'il existe une quelconque application utilisant exclusivement IPSec pour ses communications, et non TLS/SSL habituellement utilisé pour le chiffrement des communications applicatives, et si oui lequel ?
Contrairement à TLS/SSL qui travaillent juste sous la couche applicative, IPsec travaille au niveau IP.
Oui
Une application n'a pas à interagir directement avec lui mais doit utiliser les services du système d'exploitation (via TCP ou UDP).
Humm Pq ?
Il existe autant de clients/serveurs VPN IPsec que de "sociétés informatiques" au sens large (Cisco, Kerio, Microsoft, pour ne citer que les plus connues, et développant notamment pour Windows). Certes, ces clients/serveurs agissent en tant que services du SE.
Ma question était en fait: qu'est-ce qui empêche une application de créer elle-même un tunnel VPN IPsec pour ses propres besoins ? A mon avis aucun, vu que ce n'est qu'un problème purement logiciel.
Maintenant, dois-je en conclure qu'il n'existe, aujourd'hui, aucun logiciel le faisant ?
Sous Linux 2.6, il n'y a pas d'interface virtuelle pour IPsec. Une politique de sécurité détermine ce qui doit ou pas passer dans le tunnel IPsec. Je crois me souvenir qu'il est possible pour les applications de spécifier si elles souhaitent ou non passer par ce tunnel IPsec. Ce serait utilisé par exemple pour les clients DHCP ou simplement les démons ISAKMPd. Je suppose que les sources de racoon peuvent éclairer sur ce point.
À noter par rapport à ce que tu dis, que la politique du système sous Linux 2.6 ne permet pas de travailler au niveau des applications. Si par contre, tu trouves quel appel système permet de demander le chiffrement IPsec, tu peux réécrire l'appel système bind() (ou un autre) pour qu'il fasse appel automatiquement à l'appel système découvert (je suppose que c'est setsockopt() avec une option particulière). --
Merci pour ta réponse.
GG
"Vincent Bernat" <bernat@luffy.cx> a écrit dans le message de news:
m33bd55ts6.fsf@neo.luffy.cx...
OoO Lors de la soirée naissante du jeudi 13 juillet 2006, vers 18:14,
"gg" <gg@voila.Fr> disait:
Je souhaiterais savoir s'il existe une quelconque application utilisant
exclusivement IPSec pour ses communications, et non TLS/SSL
habituellement
utilisé pour le chiffrement des communications applicatives, et si oui
lequel ?
Contrairement à TLS/SSL qui travaillent juste sous la couche
applicative, IPsec travaille au niveau IP.
Oui
Une application n'a pas à
interagir directement avec lui mais doit utiliser les services du
système d'exploitation (via TCP ou UDP).
Humm Pq ?
Il existe autant de clients/serveurs VPN IPsec que de "sociétés
informatiques" au sens large (Cisco, Kerio, Microsoft, pour ne citer que les
plus connues, et développant notamment pour Windows). Certes, ces
clients/serveurs agissent en tant que services du SE.
Ma question était en fait: qu'est-ce qui empêche une application de créer
elle-même un tunnel VPN IPsec pour ses propres besoins ? A mon avis aucun,
vu que ce n'est qu'un problème purement logiciel.
Maintenant, dois-je en conclure qu'il n'existe, aujourd'hui, aucun logiciel
le faisant ?
Sous Linux 2.6, il n'y a pas d'interface virtuelle pour IPsec. Une
politique de sécurité détermine ce qui doit ou pas passer dans le
tunnel IPsec. Je crois me souvenir qu'il est possible pour les
applications de spécifier si elles souhaitent ou non passer par ce
tunnel IPsec. Ce serait utilisé par exemple pour les clients DHCP ou
simplement les démons ISAKMPd. Je suppose que les sources de racoon
peuvent éclairer sur ce point.
À noter par rapport à ce que tu dis, que la politique du système sous
Linux 2.6 ne permet pas de travailler au niveau des applications. Si
par contre, tu trouves quel appel système permet de demander le
chiffrement IPsec, tu peux réécrire l'appel système bind() (ou un
autre) pour qu'il fasse appel automatiquement à l'appel système
découvert (je suppose que c'est setsockopt() avec une option
particulière).
--
OoO Lors de la soirée naissante du jeudi 13 juillet 2006, vers 18:14, "gg" disait:
Je souhaiterais savoir s'il existe une quelconque application utilisant exclusivement IPSec pour ses communications, et non TLS/SSL habituellement utilisé pour le chiffrement des communications applicatives, et si oui lequel ?
Contrairement à TLS/SSL qui travaillent juste sous la couche applicative, IPsec travaille au niveau IP.
Oui
Une application n'a pas à interagir directement avec lui mais doit utiliser les services du système d'exploitation (via TCP ou UDP).
Humm Pq ?
Il existe autant de clients/serveurs VPN IPsec que de "sociétés informatiques" au sens large (Cisco, Kerio, Microsoft, pour ne citer que les plus connues, et développant notamment pour Windows). Certes, ces clients/serveurs agissent en tant que services du SE.
Ma question était en fait: qu'est-ce qui empêche une application de créer elle-même un tunnel VPN IPsec pour ses propres besoins ? A mon avis aucun, vu que ce n'est qu'un problème purement logiciel.
Maintenant, dois-je en conclure qu'il n'existe, aujourd'hui, aucun logiciel le faisant ?
Sous Linux 2.6, il n'y a pas d'interface virtuelle pour IPsec. Une politique de sécurité détermine ce qui doit ou pas passer dans le tunnel IPsec. Je crois me souvenir qu'il est possible pour les applications de spécifier si elles souhaitent ou non passer par ce tunnel IPsec. Ce serait utilisé par exemple pour les clients DHCP ou simplement les démons ISAKMPd. Je suppose que les sources de racoon peuvent éclairer sur ce point.
À noter par rapport à ce que tu dis, que la politique du système sous Linux 2.6 ne permet pas de travailler au niveau des applications. Si par contre, tu trouves quel appel système permet de demander le chiffrement IPsec, tu peux réécrire l'appel système bind() (ou un autre) pour qu'il fasse appel automatiquement à l'appel système découvert (je suppose que c'est setsockopt() avec une option particulière). --
Merci pour ta réponse.
GG
Vincent Bernat
OoO En cette fin de matinée radieuse du vendredi 14 juillet 2006, vers 11:39, "gg" disait:
Ma question était en fait: qu'est-ce qui empêche une application de créer elle-même un tunnel VPN IPsec pour ses propres besoins ? A mon avis aucun, vu que ce n'est qu'un problème purement logiciel.
Oui, c'est en effet possible, je n'avais pas compris la chose comme ça. Mais quel serait l'intérêt pour un logiciel de venir avec une pile IP disposant d'IPsec plutôt que de se contenter d'utiliser quelque chose comme TLS/SSL ? L'application aurait quelque chose à cacher au niveau de ses entêtes IP/TCP ? -- panic("esp: what could it be... I wonder..."); 2.2.16 /usr/src/linux/drivers/scsi/esp.c
OoO En cette fin de matinée radieuse du vendredi 14 juillet 2006, vers
11:39, "gg" <gg@voila.Fr> disait:
Ma question était en fait: qu'est-ce qui empêche une application de créer
elle-même un tunnel VPN IPsec pour ses propres besoins ? A mon avis aucun,
vu que ce n'est qu'un problème purement logiciel.
Oui, c'est en effet possible, je n'avais pas compris la chose comme
ça. Mais quel serait l'intérêt pour un logiciel de venir avec une pile
IP disposant d'IPsec plutôt que de se contenter d'utiliser quelque
chose comme TLS/SSL ? L'application aurait quelque chose à cacher au
niveau de ses entêtes IP/TCP ?
--
panic("esp: what could it be... I wonder...");
2.2.16 /usr/src/linux/drivers/scsi/esp.c
OoO En cette fin de matinée radieuse du vendredi 14 juillet 2006, vers 11:39, "gg" disait:
Ma question était en fait: qu'est-ce qui empêche une application de créer elle-même un tunnel VPN IPsec pour ses propres besoins ? A mon avis aucun, vu que ce n'est qu'un problème purement logiciel.
Oui, c'est en effet possible, je n'avais pas compris la chose comme ça. Mais quel serait l'intérêt pour un logiciel de venir avec une pile IP disposant d'IPsec plutôt que de se contenter d'utiliser quelque chose comme TLS/SSL ? L'application aurait quelque chose à cacher au niveau de ses entêtes IP/TCP ? -- panic("esp: what could it be... I wonder..."); 2.2.16 /usr/src/linux/drivers/scsi/esp.c
Michelot
Bonsoir tous,
L'application aurait quelque chose à cacher au niveau de ses entêtes IP/TCP ?
Je n'ai pas plus d'informations, mais il existe encore des opérateurs qui proposent des VPN IPsec.
Dans ce cas, les données clients sont encapsulés dans un tunnel ESP au niveau du routeur PE du fournisseur. Le routage à travers le réseau de transport opérateur est réalisé par une adresse IP choisie et gérée par l'opérateur pour que le tunnel aboutisse au PE distant.
Sur la liaison d'accès CE-PE les données client peuvent être IP sur Ethernet, ou sur ADSL.
Il n'y a rien à cacher et les données client n'ont pas besoin d'être chiffrées. Seule la notion de tunnel est utilisée pour une transmission non connectée entre 2 extrémités PE.
Cordialement, Michelot
Bonsoir tous,
L'application aurait quelque chose à cacher au
niveau de ses entêtes IP/TCP ?
Je n'ai pas plus d'informations, mais il existe encore des opérateurs
qui proposent des VPN IPsec.
Dans ce cas, les données clients sont encapsulés dans un tunnel ESP
au niveau du routeur PE du fournisseur. Le routage à travers le
réseau de transport opérateur est réalisé par une adresse IP
choisie et gérée par l'opérateur pour que le tunnel aboutisse au PE
distant.
Sur la liaison d'accès CE-PE les données client peuvent être IP sur
Ethernet, ou sur ADSL.
Il n'y a rien à cacher et les données client n'ont pas besoin d'être
chiffrées. Seule la notion de tunnel est utilisée pour une
transmission non connectée entre 2 extrémités PE.
L'application aurait quelque chose à cacher au niveau de ses entêtes IP/TCP ?
Je n'ai pas plus d'informations, mais il existe encore des opérateurs qui proposent des VPN IPsec.
Dans ce cas, les données clients sont encapsulés dans un tunnel ESP au niveau du routeur PE du fournisseur. Le routage à travers le réseau de transport opérateur est réalisé par une adresse IP choisie et gérée par l'opérateur pour que le tunnel aboutisse au PE distant.
Sur la liaison d'accès CE-PE les données client peuvent être IP sur Ethernet, ou sur ADSL.
Il n'y a rien à cacher et les données client n'ont pas besoin d'être chiffrées. Seule la notion de tunnel est utilisée pour une transmission non connectée entre 2 extrémités PE.
