Je travaille pour la salle informatique de mon université. On a reçu
l'autorisation d'installer du Wifi et des prises ethernet pour les
étudiants.
Cependant, on ne veut pas risquer d'avoir n'importe qui qui se connecte à
n'importe quoi.
On voudrait faire du Nat à partir d'une adresse IP qu'on nous a allouée, et
faire passer les ports importants (ssh, ftp, http, subversion, cvs,...)
donc la solution du proxy http est incomplète.
La problème est qu'on voudrait que l'étudiant que se connecte aie à
s'authentifier avant de pouvoir utiliser la connection (par exemple, s'il
rentre une adresse quelconque il est redirigé vers le panneau
d'authentification).
J'ai discuté avec des personnes ayant eu affaire à ce genre de systèmes dans
des lieux publics (conférences sur le LL & co) mais je n'ai pas eu de noms.
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
Laurent
Bonjour,
Je travaille pour la salle informatique de mon université. On a reçu l'autorisation d'installer du Wifi et des prises ethernet pour les étudiants. Cependant, on ne veut pas risquer d'avoir n'importe qui qui se connecte à n'importe quoi. On voudrait faire du Nat à partir d'une adresse IP qu'on nous a allouée, et faire passer les ports importants (ssh, ftp, http, subversion, cvs,...) donc la solution du proxy http est incomplète. La problème est qu'on voudrait que l'étudiant que se connecte aie à s'authentifier avant de pouvoir utiliser la connection (par exemple, s'il rentre une adresse quelconque il est redirigé vers le panneau d'authentification). J'ai discuté avec des personnes ayant eu affaire à ce genre de systèmes dans des lieux publics (conférences sur le LL & co) mais je n'ai pas eu de noms.
Quelqu'un pourait m'éclairer ? Merci beaucoup,
NuFW semble correspondre à ce cahier des charges.
http://www.nufw.org/
Il s'agit d'un parfeu authentifiant se greffant sur Netfilter du noyau Linux. Il sait travailler avec squid (proxy) et les annuaires ldap, faire de l'authentification par utilisateur, du filtrage par OS, logiciel. Il sait même faire du Single Sign On.
Je réfléchis d'ailleurs à l'implémenter sur le réseau de mon entreprise, composé entièrement de stations et serveurs Windows (sic). Il n'est donc pas tributaire du type de clients présents sur le LAN. -- Laurent
Bonjour,
Je travaille pour la salle informatique de mon université. On a reçu
l'autorisation d'installer du Wifi et des prises ethernet pour les
étudiants.
Cependant, on ne veut pas risquer d'avoir n'importe qui qui se connecte à
n'importe quoi.
On voudrait faire du Nat à partir d'une adresse IP qu'on nous a allouée, et
faire passer les ports importants (ssh, ftp, http, subversion, cvs,...)
donc la solution du proxy http est incomplète.
La problème est qu'on voudrait que l'étudiant que se connecte aie à
s'authentifier avant de pouvoir utiliser la connection (par exemple, s'il
rentre une adresse quelconque il est redirigé vers le panneau
d'authentification).
J'ai discuté avec des personnes ayant eu affaire à ce genre de systèmes dans
des lieux publics (conférences sur le LL & co) mais je n'ai pas eu de noms.
Quelqu'un pourait m'éclairer ?
Merci beaucoup,
NuFW semble correspondre à ce cahier des charges.
http://www.nufw.org/
Il s'agit d'un parfeu authentifiant se greffant sur Netfilter du noyau
Linux. Il sait travailler avec squid (proxy) et les annuaires ldap,
faire de l'authentification par utilisateur, du filtrage par OS,
logiciel. Il sait même faire du Single Sign On.
Je réfléchis d'ailleurs à l'implémenter sur le réseau de mon
entreprise, composé entièrement de stations et serveurs Windows
(sic). Il n'est donc pas tributaire du type de clients présents sur le
LAN.
--
Laurent
Je travaille pour la salle informatique de mon université. On a reçu l'autorisation d'installer du Wifi et des prises ethernet pour les étudiants. Cependant, on ne veut pas risquer d'avoir n'importe qui qui se connecte à n'importe quoi. On voudrait faire du Nat à partir d'une adresse IP qu'on nous a allouée, et faire passer les ports importants (ssh, ftp, http, subversion, cvs,...) donc la solution du proxy http est incomplète. La problème est qu'on voudrait que l'étudiant que se connecte aie à s'authentifier avant de pouvoir utiliser la connection (par exemple, s'il rentre une adresse quelconque il est redirigé vers le panneau d'authentification). J'ai discuté avec des personnes ayant eu affaire à ce genre de systèmes dans des lieux publics (conférences sur le LL & co) mais je n'ai pas eu de noms.
Quelqu'un pourait m'éclairer ? Merci beaucoup,
NuFW semble correspondre à ce cahier des charges.
http://www.nufw.org/
Il s'agit d'un parfeu authentifiant se greffant sur Netfilter du noyau Linux. Il sait travailler avec squid (proxy) et les annuaires ldap, faire de l'authentification par utilisateur, du filtrage par OS, logiciel. Il sait même faire du Single Sign On.
Je réfléchis d'ailleurs à l'implémenter sur le réseau de mon entreprise, composé entièrement de stations et serveurs Windows (sic). Il n'est donc pas tributaire du type de clients présents sur le LAN. -- Laurent
Bertrand
Salut,
La problème est qu'on voudrait que l'étudiant que se connecte aie à s'authentifier avant de pouvoir utiliser la connection (par exemple, s'il rentre une adresse quelconque il est redirigé vers le panneau d'authentification). J'ai discuté avec des personnes ayant eu affaire à ce genre de systèmes dans des lieux publics (conférences sur le LL & co) mais je n'ai pas eu de noms.
Voir du coté de IPsec (en n'autorisant ensuite coté routeur que le traffic IPsec correctement signé) ou du coté de 802.1x, agissant tous deux à des niveaux différents.
La solution IPsec a l'avantage de demander moins de matériel (tout peut être fait en logiciel au niveau des clients et du routeur), alors qu'il faut des gros switchs pour du 802.1x, qui offre par contre une protection supplémentaire dans le sens où toute communication sur le réseau, y compris de "client à client", est impossible avant authentification.
Dans les deux cas il va falloir deployer au moins un système de génération de certificats numériques propres à chaque étudiants (donc avec une autorité de certification probablement "maison").
@+ Bertrand
Salut,
La problème est qu'on voudrait que l'étudiant que se connecte aie à
s'authentifier avant de pouvoir utiliser la connection (par exemple, s'il
rentre une adresse quelconque il est redirigé vers le panneau
d'authentification).
J'ai discuté avec des personnes ayant eu affaire à ce genre de systèmes dans
des lieux publics (conférences sur le LL & co) mais je n'ai pas eu de noms.
Voir du coté de IPsec (en n'autorisant ensuite coté routeur que le
traffic IPsec correctement signé) ou du coté de 802.1x, agissant tous
deux à des niveaux différents.
La solution IPsec a l'avantage de demander moins de matériel (tout peut
être fait en logiciel au niveau des clients et du routeur), alors qu'il
faut des gros switchs pour du 802.1x, qui offre par contre une
protection supplémentaire dans le sens où toute communication sur le
réseau, y compris de "client à client", est impossible avant
authentification.
Dans les deux cas il va falloir deployer au moins un système de
génération de certificats numériques propres à chaque étudiants (donc
avec une autorité de certification probablement "maison").
La problème est qu'on voudrait que l'étudiant que se connecte aie à s'authentifier avant de pouvoir utiliser la connection (par exemple, s'il rentre une adresse quelconque il est redirigé vers le panneau d'authentification). J'ai discuté avec des personnes ayant eu affaire à ce genre de systèmes dans des lieux publics (conférences sur le LL & co) mais je n'ai pas eu de noms.
Voir du coté de IPsec (en n'autorisant ensuite coté routeur que le traffic IPsec correctement signé) ou du coté de 802.1x, agissant tous deux à des niveaux différents.
La solution IPsec a l'avantage de demander moins de matériel (tout peut être fait en logiciel au niveau des clients et du routeur), alors qu'il faut des gros switchs pour du 802.1x, qui offre par contre une protection supplémentaire dans le sens où toute communication sur le réseau, y compris de "client à client", est impossible avant authentification.
Dans les deux cas il va falloir deployer au moins un système de génération de certificats numériques propres à chaque étudiants (donc avec une autorité de certification probablement "maison").
@+ Bertrand
T0aD
Bonjour aris,
Une solution serait d'utiliser ce qui se fait deja depuis longtemps pour les reseaux wireless, c'est a dire une passerelle d'authentification. Je sais par exemple qu'un module PAM existe pour se faire, il s'agit de pam_iptables sur lequel tu pourras tres certainement greffer d'autres composants.
Une solution serait d'utiliser ce qui se fait deja depuis longtemps
pour les reseaux wireless, c'est a dire une passerelle
d'authentification. Je sais par exemple qu'un module PAM existe pour se
faire, il s'agit de pam_iptables sur lequel tu pourras tres
certainement greffer d'autres composants.
Une solution serait d'utiliser ce qui se fait deja depuis longtemps pour les reseaux wireless, c'est a dire une passerelle d'authentification. Je sais par exemple qu'un module PAM existe pour se faire, il s'agit de pam_iptables sur lequel tu pourras tres certainement greffer d'autres composants.
Aris Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov' étudiants) mais aussi demanderont trop d'efforts de notre part (un solide travail, générer les certifs et répondre au téléphone quand ça ne marche pas !)
Aris wrote:
Quelqu'un pourait m'éclairer ?
Merci beaucoup,
Aris
Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me
semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov'
étudiants) mais aussi demanderont trop d'efforts de notre part (un solide
travail, générer les certifs et répondre au téléphone quand ça ne marche
pas !)
Aris Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov' étudiants) mais aussi demanderont trop d'efforts de notre part (un solide travail, générer les certifs et répondre au téléphone quand ça ne marche pas !)
yves Agostini
Le Mon, 28 Nov 2005 18:59:55 +0000, Aris a écrit :
Aris wrote:
Aris Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov' étudiants) mais aussi demanderont trop d'efforts de notre part (un solide travail, générer les certifs et répondre au téléphone quand ça ne marche pas !)
le problème est que les pauvres étudiants se snifferont tranquillement leurs mots de passe msn/hotmail, si vous autorisez des protocoles non cryptés. Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Le Mon, 28 Nov 2005 18:59:55 +0000, Aris a écrit :
Aris wrote:
Aris
Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me
semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov'
étudiants) mais aussi demanderont trop d'efforts de notre part (un solide
travail, générer les certifs et répondre au téléphone quand ça ne marche
pas !)
le problème est que les pauvres étudiants se snifferont
tranquillement leurs mots de passe msn/hotmail, si vous autorisez des
protocoles non cryptés.
Une autre solution, limitée à http/https mais tout le transport wifi est
en https. Cela ne nécessite pas de client sur les machines :
http://www.crium.univ-metz.fr/reseau/talweg/
Le Mon, 28 Nov 2005 18:59:55 +0000, Aris a écrit :
Aris wrote:
Aris Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov' étudiants) mais aussi demanderont trop d'efforts de notre part (un solide travail, générer les certifs et répondre au téléphone quand ça ne marche pas !)
le problème est que les pauvres étudiants se snifferont tranquillement leurs mots de passe msn/hotmail, si vous autorisez des protocoles non cryptés. Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Cedric Blancher
Le Mon, 28 Nov 2005 22:48:09 +0000, yves Agostini a écrit :.
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
-- BOFH excuse #253:
We've run out of licenses
Le Mon, 28 Nov 2005 22:48:09 +0000, yves Agostini a écrit :.
Une autre solution, limitée à http/https mais tout le transport wifi est
en https. Cela ne nécessite pas de client sur les machines :
http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure
de vérifier le moindre certificat de site, ni de s'authentifier par le
biais d'un certificat client si besoin est.
Le Mon, 28 Nov 2005 22:48:09 +0000, yves Agostini a écrit :.
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
-- BOFH excuse #253:
We've run out of licenses
Aris
yves Agostini wrote:
Le Mon, 28 Nov 2005 18:59:55 +0000, Aris a écrit :
Aris wrote:
Aris Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov' étudiants) mais aussi demanderont trop d'efforts de notre part (un solide travail, générer les certifs et répondre au téléphone quand ça ne marche pas !)
le problème est que les pauvres étudiants se snifferont tranquillement leurs mots de passe msn/hotmail, si vous autorisez des protocoles non cryptés. Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/ Tant pis, ils sont là pour réaliser leurs projets de groupe, pas pour
discuter sur msn. Je suis en train de faire fonctionner nocatauth, mais je réalise que ce soft est loin d'un produit fini, et en plus il lui manque l'authentification via NIS.
On ne veut surtout pas limiter à http/https, les étudiants ont besoin au minimum de ssh. Maintenant si ils utilisent des protocoles non sûrs, c'est leur problème (mais je vais m'arranger pour que leur login/pass du reseau interne ne finisse *jamais* en clair sur le wifi, évidement.
Merci pour vos remarques,
Aris
yves Agostini wrote:
Le Mon, 28 Nov 2005 18:59:55 +0000, Aris a écrit :
Aris wrote:
Aris
Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me
semble un peu trop "dure" et contraignante pour nos utilisateurs (des
pov' étudiants) mais aussi demanderont trop d'efforts de notre part (un
solide travail, générer les certifs et répondre au téléphone quand ça ne
marche pas !)
le problème est que les pauvres étudiants se snifferont
tranquillement leurs mots de passe msn/hotmail, si vous autorisez des
protocoles non cryptés.
Une autre solution, limitée à http/https mais tout le transport wifi est
en https. Cela ne nécessite pas de client sur les machines :
http://www.crium.univ-metz.fr/reseau/talweg/
Tant pis, ils sont là pour réaliser leurs projets de groupe, pas pour
discuter sur msn. Je suis en train de faire fonctionner nocatauth, mais je
réalise que ce soft est loin d'un produit fini, et en plus il lui manque
l'authentification via NIS.
On ne veut surtout pas limiter à http/https, les étudiants ont besoin au
minimum de ssh. Maintenant si ils utilisent des protocoles non sûrs, c'est
leur problème (mais je vais m'arranger pour que leur login/pass du reseau
interne ne finisse *jamais* en clair sur le wifi, évidement.
Le Mon, 28 Nov 2005 18:59:55 +0000, Aris a écrit :
Aris wrote:
Aris Merci pour vos indications. je vais me tourner vers nocat ou nufw qui
semblent correspondre à mes besoins. la solution de l'ipsec ou 802.1 me semble un peu trop "dure" et contraignante pour nos utilisateurs (des pov' étudiants) mais aussi demanderont trop d'efforts de notre part (un solide travail, générer les certifs et répondre au téléphone quand ça ne marche pas !)
le problème est que les pauvres étudiants se snifferont tranquillement leurs mots de passe msn/hotmail, si vous autorisez des protocoles non cryptés. Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/ Tant pis, ils sont là pour réaliser leurs projets de groupe, pas pour
discuter sur msn. Je suis en train de faire fonctionner nocatauth, mais je réalise que ce soft est loin d'un produit fini, et en plus il lui manque l'authentification via NIS.
On ne veut surtout pas limiter à http/https, les étudiants ont besoin au minimum de ssh. Maintenant si ils utilisent des protocoles non sûrs, c'est leur problème (mais je vais m'arranger pour que leur login/pass du reseau interne ne finisse *jamais* en clair sur le wifi, évidement.
Merci pour vos remarques,
Aris
Vincent Bernat
OoO En cette nuit nuageuse du mardi 29 novembre 2005, vers 00:01, Cedric Blancher disait:
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
La description du système manque de précision, mais on peut imaginer que pour les sites directement en HTTPS, il n'y a aucune interception et on dialogue directement avec le serveur cible. -- I WILL NOT HIDE THE TEACHER'S PROZAC I WILL NOT HIDE THE TEACHER'S PROZAC I WILL NOT HIDE THE TEACHER'S PROZAC -+- Bart Simpson on chalkboard in episode 3G03
OoO En cette nuit nuageuse du mardi 29 novembre 2005, vers 00:01,
Cedric Blancher <blancher@cartel-securite.fr> disait:
Une autre solution, limitée à http/https mais tout le transport wifi est
en https. Cela ne nécessite pas de client sur les machines :
http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure
de vérifier le moindre certificat de site, ni de s'authentifier par le
biais d'un certificat client si besoin est.
La description du système manque de précision, mais on peut imaginer
que pour les sites directement en HTTPS, il n'y a aucune interception
et on dialogue directement avec le serveur cible.
--
I WILL NOT HIDE THE TEACHER'S PROZAC
I WILL NOT HIDE THE TEACHER'S PROZAC
I WILL NOT HIDE THE TEACHER'S PROZAC
-+- Bart Simpson on chalkboard in episode 3G03
OoO En cette nuit nuageuse du mardi 29 novembre 2005, vers 00:01, Cedric Blancher disait:
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
La description du système manque de précision, mais on peut imaginer que pour les sites directement en HTTPS, il n'y a aucune interception et on dialogue directement avec le serveur cible. -- I WILL NOT HIDE THE TEACHER'S PROZAC I WILL NOT HIDE THE TEACHER'S PROZAC I WILL NOT HIDE THE TEACHER'S PROZAC -+- Bart Simpson on chalkboard in episode 3G03
Vincent Bernat
OoO En cette matinée pluvieuse du mardi 29 novembre 2005, vers 10:17, je disais:
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
La description du système manque de précision, mais on peut imaginer que pour les sites directement en HTTPS, il n'y a aucune interception et on dialogue directement avec le serveur cible.
Vérifications prises dans le source, le trafic en HTTPS est également détourné, donc il y aura bien des problèmes de certificats. Mais dans l'absolu, on peut imaginer un système comme je le décris. Talweg semble difficile à adapter tel quel car c'est le script Perl qui effectue la redirection qui vérifie les autorisations. Il faudrait le modifier pour qu'une IP autorisée soit autorisée à passer le firewall pour le port 443.
C'est tout de même une idée intéressante que de forcer l'utilisation de HTTPS pour tout. Cela ne limite pas les interceptions (à moins que l'utilisateur ne vérifie à chaque fois que le certificat de la passerelle ne change pas), mais il ne devient plus possible d'observer passivement ce qu'il se passe. -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
OoO En cette matinée pluvieuse du mardi 29 novembre 2005, vers 10:17,
je disais:
Une autre solution, limitée à http/https mais tout le transport wifi est
en https. Cela ne nécessite pas de client sur les machines :
http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure
de vérifier le moindre certificat de site, ni de s'authentifier par le
biais d'un certificat client si besoin est.
La description du système manque de précision, mais on peut imaginer
que pour les sites directement en HTTPS, il n'y a aucune interception
et on dialogue directement avec le serveur cible.
Vérifications prises dans le source, le trafic en HTTPS est également
détourné, donc il y aura bien des problèmes de certificats. Mais dans
l'absolu, on peut imaginer un système comme je le décris. Talweg
semble difficile à adapter tel quel car c'est le script Perl qui
effectue la redirection qui vérifie les autorisations. Il faudrait le
modifier pour qu'une IP autorisée soit autorisée à passer le firewall
pour le port 443.
C'est tout de même une idée intéressante que de forcer l'utilisation
de HTTPS pour tout. Cela ne limite pas les interceptions (à moins que
l'utilisateur ne vérifie à chaque fois que le certificat de la
passerelle ne change pas), mais il ne devient plus possible d'observer
passivement ce qu'il se passe.
--
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)
OoO En cette matinée pluvieuse du mardi 29 novembre 2005, vers 10:17, je disais:
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
La description du système manque de précision, mais on peut imaginer que pour les sites directement en HTTPS, il n'y a aucune interception et on dialogue directement avec le serveur cible.
Vérifications prises dans le source, le trafic en HTTPS est également détourné, donc il y aura bien des problèmes de certificats. Mais dans l'absolu, on peut imaginer un système comme je le décris. Talweg semble difficile à adapter tel quel car c'est le script Perl qui effectue la redirection qui vérifie les autorisations. Il faudrait le modifier pour qu'une IP autorisée soit autorisée à passer le firewall pour le port 443.
C'est tout de même une idée intéressante que de forcer l'utilisation de HTTPS pour tout. Cela ne limite pas les interceptions (à moins que l'utilisateur ne vérifie à chaque fois que le certificat de la passerelle ne change pas), mais il ne devient plus possible d'observer passivement ce qu'il se passe. -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
yves Agostini
Le Tue, 29 Nov 2005 13:33:55 +0000, Vincent Bernat a écrit :
OoO En cette matinée pluvieuse du mardi 29 novembre 2005, vers 10:17, je disais:
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
.........
Vérifications prises dans le source, le trafic en HTTPS est également détourné, donc il y aura bien des problèmes de certificats. Mais dans l'absolu, on peut imaginer un système comme je le décris. Talweg semble difficile à adapter tel quel car c'est le script Perl qui effectue la redirection qui vérifie les autorisations. Il faudrait le modifier pour qu'une IP autorisée soit autorisée à passer le firewall pour le port 443.
Mais ici on risque le second problème de nocat : le vol de session. Un utilisateur non authentifié peut utiliser cette connexion ouverte, juste le temps d'envoyer un mail d'insulte.
C'est tout de même une idée intéressante que de forcer l'utilisation de HTTPS pour tout. Cela ne limite pas les interceptions (à moins que l'utilisateur ne vérifie à chaque fois que le certificat de la passerelle ne change pas), mais il ne devient plus possible d'observer passivement ce qu'il se passe.
Le Tue, 29 Nov 2005 13:33:55 +0000, Vincent Bernat a écrit :
OoO En cette matinée pluvieuse du mardi 29 novembre 2005, vers 10:17,
je disais:
Une autre solution, limitée à http/https mais tout le transport wifi est
en https. Cela ne nécessite pas de client sur les machines :
http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure
de vérifier le moindre certificat de site, ni de s'authentifier par le
biais d'un certificat client si besoin est.
.........
Vérifications prises dans le source, le trafic en HTTPS est également
détourné, donc il y aura bien des problèmes de certificats. Mais dans
l'absolu, on peut imaginer un système comme je le décris. Talweg
semble difficile à adapter tel quel car c'est le script Perl qui
effectue la redirection qui vérifie les autorisations. Il faudrait le
modifier pour qu'une IP autorisée soit autorisée à passer le firewall
pour le port 443.
Mais ici on risque le second problème de nocat : le vol de session.
Un utilisateur non authentifié peut utiliser cette connexion ouverte,
juste le temps d'envoyer un mail d'insulte.
C'est tout de même une idée intéressante que de forcer l'utilisation
de HTTPS pour tout. Cela ne limite pas les interceptions (à moins que
l'utilisateur ne vérifie à chaque fois que le certificat de la
passerelle ne change pas), mais il ne devient plus possible d'observer
passivement ce qu'il se passe.
Le Tue, 29 Nov 2005 13:33:55 +0000, Vincent Bernat a écrit :
OoO En cette matinée pluvieuse du mardi 29 novembre 2005, vers 10:17, je disais:
Une autre solution, limitée à http/https mais tout le transport wifi est en https. Cela ne nécessite pas de client sur les machines : http://www.crium.univ-metz.fr/reseau/talweg/
Si j'ai bien compris le fonctionnement, le client ne sera plus en mesure de vérifier le moindre certificat de site, ni de s'authentifier par le biais d'un certificat client si besoin est.
.........
Vérifications prises dans le source, le trafic en HTTPS est également détourné, donc il y aura bien des problèmes de certificats. Mais dans l'absolu, on peut imaginer un système comme je le décris. Talweg semble difficile à adapter tel quel car c'est le script Perl qui effectue la redirection qui vérifie les autorisations. Il faudrait le modifier pour qu'une IP autorisée soit autorisée à passer le firewall pour le port 443.
Mais ici on risque le second problème de nocat : le vol de session. Un utilisateur non authentifié peut utiliser cette connexion ouverte, juste le temps d'envoyer un mail d'insulte.
C'est tout de même une idée intéressante que de forcer l'utilisation de HTTPS pour tout. Cela ne limite pas les interceptions (à moins que l'utilisateur ne vérifie à chaque fois que le certificat de la passerelle ne change pas), mais il ne devient plus possible d'observer passivement ce qu'il se passe.
