Tunnelling IP-over-HTTP
Fermé
sebsauvage
-
18 févr. 2002 à 13:56
Castor Messages postés 17858 Date d'inscription mardi 3 juillet 2001 Statut Modérateur Dernière intervention 7 novembre 2023 - 3 nov. 2009 à 17:23
Castor Messages postés 17858 Date d'inscription mardi 3 juillet 2001 Statut Modérateur Dernière intervention 7 novembre 2023 - 3 nov. 2009 à 17:23
A voir également:
- Tunnelling IP-over-HTTP
- Ethernet n'a pas de configuration ip valide - Guide
- Protocole http - Guide
- Comment connaître son adresse ip - Guide
- Ip local - Guide
- Http error 413 zimbra - Forum autres boîtes mail
10 réponses
Castor
Messages postés
17858
Date d'inscription
mardi 3 juillet 2001
Statut
Modérateur
Dernière intervention
7 novembre 2023
169
11 déc. 2007 à 13:46
11 déc. 2007 à 13:46
Même si la conversation est un peu ancienne, on ne sait pas si tu as trouvé en effet Seb :)
Et ca reste interressant
En relisant je viens de penser à un truc:
Faire un tunnel HTTP, puis a l'intérieur un tunnel SSH qui permetttrait donc chiffrement+authentification. En n'authorisant que le protocole SSH à traverser ton tunnel HTTP
Et ca reste interressant
En relisant je viens de penser à un truc:
Faire un tunnel HTTP, puis a l'intérieur un tunnel SSH qui permetttrait donc chiffrement+authentification. En n'authorisant que le protocole SSH à traverser ton tunnel HTTP
Yota238
Messages postés
120
Date d'inscription
mardi 15 janvier 2002
Statut
Membre
Dernière intervention
3 avril 2002
2
18 févr. 2002 à 16:03
18 févr. 2002 à 16:03
En plus a ta liste
http:/http-tunnel.com
sous windows mais payant.
le tunnel sort de ton reseau derière ton firewall et va sur ta machine qui est sur le net c'est ça ?
a mon avis tu dois configurer ta station linux pour accepter seulement ton ip a communiquer avec elle.
plus faire un http-tunnel en ssl.
pour la compression ? je vois pas bien ?
Yota238 - www.e-reservoir.ch
http:/http-tunnel.com
sous windows mais payant.
le tunnel sort de ton reseau derière ton firewall et va sur ta machine qui est sur le net c'est ça ?
a mon avis tu dois configurer ta station linux pour accepter seulement ton ip a communiquer avec elle.
plus faire un http-tunnel en ssl.
pour la compression ? je vois pas bien ?
Yota238 - www.e-reservoir.ch
Utilisateur anonyme
18 févr. 2002 à 17:11
18 févr. 2002 à 17:11
Je pense (mais c a confirmer) que l'authentification peut se faire sur la becane distante.
si g bien compris, ton tunnel aura une sortie sur chaque becane... logiquement seules ces deux becanes en question pourront l'utiliser.... donc ce que tu souhaite ce serait surtout qu'un indelicat n'ouvre pas un nouvo tunnel sur ton serveur... il "sufirait" (enfin je suppose) de n'authoriser les connexions sur un certain port qu'avec authentification... la question du "comment" reste cependant... si tu progresses ds tes recherhces, fait nous signe, c super interressant comme sujet
.O
(_)__... Castor
si g bien compris, ton tunnel aura une sortie sur chaque becane... logiquement seules ces deux becanes en question pourront l'utiliser.... donc ce que tu souhaite ce serait surtout qu'un indelicat n'ouvre pas un nouvo tunnel sur ton serveur... il "sufirait" (enfin je suppose) de n'authoriser les connexions sur un certain port qu'avec authentification... la question du "comment" reste cependant... si tu progresses ds tes recherhces, fait nous signe, c super interressant comme sujet
.O
(_)__... Castor
Hello... merci pour vos réponses.
http://http-tunnel.com je connais, leur service gratuit me conviendrais très bien si les trames ne transitaient pas en clair sur le réseau local (pas glop avec NNTP : le mot de passe est en clair).
Je ne peux pas filtrer par les IP:
L'IP du client n'est pas fixe (proxy avec load balancer), et le serveur non plus (IP dynamique).
Il me faut donc un filtrage avec mot de passe ou équivalent (fichier certificat ou autre).
castor, en effet, c'est bien sur le serveur (celui qui est en dehors du firewall) que je veux pouvoir authentifier l'utilisateur (je veux pouvoir être le seul à utiliser le serveur tunnel installé sur ma machine).
La version payante de HTTPort fait exactement ce que je veux, mais c'est payant, et pas donné.
En fait, je veux pouvoir faire passer n'importe quel protocole à travers un proxy HTTP. Il faut absolument que ça soit chiffré (pour la compression, c'est optionnel ; pour l'authentification, elle n'est nécessaire que si je dois installer le serveur tunnel sur une machine à moi.)
J'avais pensé utiliser Zebedee (chiffrement SSL+compression) avec une clé fixe (authentification), mais il ne résiste pas à des attaques de type replay.
L'idéal serait:
flux TCP <---> compression <---> authentification des paquets/du user <---> chiffrement <---> encapsulation HTTP
Ainsi, on pourrait authentifier l'utilisateur sans être sensibles aux attaques replay (grâce à la négociation de nouvelles clé SSL à chaque 'connexion').
On pourrait bien sûr simplifier un peu en utilisant directement SSL sur le proxy (ce que fait HTTPort, sans la compression):
flux TCP <---> compression <---> authentification des paquets/du user <---> encapsulation HTTPS.
Je suis en train de me demander si je ne pourrais pas programmer ça moi-même - si j'en avais le temps :-(
http://http-tunnel.com je connais, leur service gratuit me conviendrais très bien si les trames ne transitaient pas en clair sur le réseau local (pas glop avec NNTP : le mot de passe est en clair).
Je ne peux pas filtrer par les IP:
L'IP du client n'est pas fixe (proxy avec load balancer), et le serveur non plus (IP dynamique).
Il me faut donc un filtrage avec mot de passe ou équivalent (fichier certificat ou autre).
castor, en effet, c'est bien sur le serveur (celui qui est en dehors du firewall) que je veux pouvoir authentifier l'utilisateur (je veux pouvoir être le seul à utiliser le serveur tunnel installé sur ma machine).
La version payante de HTTPort fait exactement ce que je veux, mais c'est payant, et pas donné.
En fait, je veux pouvoir faire passer n'importe quel protocole à travers un proxy HTTP. Il faut absolument que ça soit chiffré (pour la compression, c'est optionnel ; pour l'authentification, elle n'est nécessaire que si je dois installer le serveur tunnel sur une machine à moi.)
J'avais pensé utiliser Zebedee (chiffrement SSL+compression) avec une clé fixe (authentification), mais il ne résiste pas à des attaques de type replay.
L'idéal serait:
flux TCP <---> compression <---> authentification des paquets/du user <---> chiffrement <---> encapsulation HTTP
Ainsi, on pourrait authentifier l'utilisateur sans être sensibles aux attaques replay (grâce à la négociation de nouvelles clé SSL à chaque 'connexion').
On pourrait bien sûr simplifier un peu en utilisant directement SSL sur le proxy (ce que fait HTTPort, sans la compression):
flux TCP <---> compression <---> authentification des paquets/du user <---> encapsulation HTTPS.
Je suis en train de me demander si je ne pourrais pas programmer ça moi-même - si j'en avais le temps :-(
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
El_Diablo666
Messages postés
294
Date d'inscription
jeudi 8 février 2007
Statut
Membre
Dernière intervention
3 décembre 2012
32
29 juil. 2009 à 16:50
29 juil. 2009 à 16:50
Bon je pense que le sujet date un peut mais ça m'intéresse toujours alors s'il y a des vivants qui peuvent m'aider.
moi j'ai réalisé du tunnelling IP-over-HTTP a l'aide de HTTPort et HTTHost et j'ai réussi a accéder au service internet bloquer par le firewal, mais le pb c'est que mon admin a comme même intercepter mon trafic et a détecté que je me suis connecter a msn(il a détecter le port utiliser par msn 1863. Je cherche a chiffrer mon trafic de telle façon qu'il n'arrive plus a lire a l'intérieur de mais requête. J'ai lue quelque part que l'IDS SNORT arrivé a détecté l'utilisation des tunnelling IP-over-HTTP avec HTTPort et HTTHost par l'analyse des entête HTTP qui sont codé en base64.
J'aimerai avoir une solution qui chiffre tout ça!!! merci!!!
moi j'ai réalisé du tunnelling IP-over-HTTP a l'aide de HTTPort et HTTHost et j'ai réussi a accéder au service internet bloquer par le firewal, mais le pb c'est que mon admin a comme même intercepter mon trafic et a détecté que je me suis connecter a msn(il a détecter le port utiliser par msn 1863. Je cherche a chiffrer mon trafic de telle façon qu'il n'arrive plus a lire a l'intérieur de mais requête. J'ai lue quelque part que l'IDS SNORT arrivé a détecté l'utilisation des tunnelling IP-over-HTTP avec HTTPort et HTTHost par l'analyse des entête HTTP qui sont codé en base64.
J'aimerai avoir une solution qui chiffre tout ça!!! merci!!!
Personnellement je passe par un tunellle https (tunnelling IP over HTTPS) avec SSL histoire que l'on sache pas ce que je fait dans ce-dit tunelle (le proxy ne voit qu'une connexion sur un site SSL) toutefois sa a des fois ses limite surtout avec squid si l'admin est parano (la meilleurs parade est éventuellement de couper régulièrement les liaison SSL ou pire de ne pas les autoriser mais dans ce cas plus de https ....)
Castor
Messages postés
17858
Date d'inscription
mardi 3 juillet 2001
Statut
Modérateur
Dernière intervention
7 novembre 2023
169
5 oct. 2009 à 11:30
5 oct. 2009 à 11:30
Ça commence a remonter oui :)
Le problème du tunnel crypté est que dès qu'il y a un proxy tu as de grandes chances que le trafic soit intercepté et donc coupé
Bien souvent les admins réseau mettent des simili "man in the middle": En clair tu interroges le site, le proxy se substitue au site et rejoue la requête
Du coup le trafic ssl n'est plus crypté à l'intérieur du proxy et byebye les tunnels
Le problème du tunnel crypté est que dès qu'il y a un proxy tu as de grandes chances que le trafic soit intercepté et donc coupé
Bien souvent les admins réseau mettent des simili "man in the middle": En clair tu interroges le site, le proxy se substitue au site et rejoue la requête
Du coup le trafic ssl n'est plus crypté à l'intérieur du proxy et byebye les tunnels
Bonsoir, je tape l'incruste :D
En gros Castor, tu veux nous dire qu'il n'y a pas de réel moyen de crypter son tunnel...
C'est plutôt emmerdant ça.
Personnellement je cherche juste à contourner le proxy pour ouvrir quelques ports et accéder à certains sites.
Ça fonctionnait assez bien en ssh tout simple jusque là mais avec l'arrivée de ce proxy, le port de sorti est toujours "ouvert" mais pas pour le ssh. Un IPS apparemment...
De ce que je lis, la méthode de DOCKY99 n'a pas l'air si mal mais quid du squid : qu'est ce que l'admin peut bien voir ?
En gros Castor, tu veux nous dire qu'il n'y a pas de réel moyen de crypter son tunnel...
C'est plutôt emmerdant ça.
Personnellement je cherche juste à contourner le proxy pour ouvrir quelques ports et accéder à certains sites.
Ça fonctionnait assez bien en ssh tout simple jusque là mais avec l'arrivée de ce proxy, le port de sorti est toujours "ouvert" mais pas pour le ssh. Un IPS apparemment...
De ce que je lis, la méthode de DOCKY99 n'a pas l'air si mal mais quid du squid : qu'est ce que l'admin peut bien voir ?
Castor
Messages postés
17858
Date d'inscription
mardi 3 juillet 2001
Statut
Modérateur
Dernière intervention
7 novembre 2023
169
3 nov. 2009 à 17:23
3 nov. 2009 à 17:23
Bah tout dépend de comment est configuré le proxy pour l'https
Si il décrypte puis recrypte il n'y a pas de différence entre un flux en clair ou en SSL
En revanche si il laisse passer le flux SSL "as is" alors il verra quedalle
Si il décrypte puis recrypte il n'y a pas de différence entre un flux en clair ou en SSL
En revanche si il laisse passer le flux SSL "as is" alors il verra quedalle
