CommentCaMarche
Recherche
Posez votre question Signaler

Tunnelling IP-over-HTTP

sebsauvage - Dernière réponse le 3 nov. 2009 à 17:23
Bon... je cherche à faire du tunnelling IP-over-HTTP pour pouvoir utiliser tout mes logiciels favoris à traver un firewall qui ne laisse passer que HTTP.
(en ayant une machine à l'extérieur du firewall sur laquelle je peux installer le serveur que je veux)

J'ai trouvé des tas de logiciels:
Bouncer : http://www.r00t3d.org.uk/
Corkscrew : http://www.agroman.net/corkscrew/
HTTPTunnel : http://www.nocrew.org/software/httptunnel.html
Socks via HTTP : http://cqs.dyndns.org/socks/
etc.

Mais je n'arrive pas à trouver un soft qui fasse à la fois:

- authentification (seuls les users autorisés peuvent utiliser le tunnel)
- chiffrement (SSL ou autre, anti-sniffing)
- compression

Ex: Zebedee fait chiffrement+compression, mais pas authentification.
Socks via HTTP fait compression+authentification, mais pas de chiffrement,
HTTP-Tunnel fait de la compression, mais ni authentification ni chiffrement.

Peut-être en combinant ces logiciels ?
(plusieurs tunnels reliés entre eux ?)
Lire la suite 
Réponse
+5
moins plus
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
Ajouter un commentaire
Réponse
+0
moins plus
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
Ajouter un commentaire
Réponse
+0
moins plus
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
Ajouter un commentaire
Réponse
+0
moins plus
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 :-(
Ajouter un commentaire
Réponse
+0
moins plus
Alors Sebsauvage du nouveau? ;-)
Ajouter un commentaire
Réponse
+0
moins plus
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!!!
Ajouter un commentaire
Réponse
+0
moins plus
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 ....)
Ajouter un commentaire
Réponse
+0
moins plus
Ç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
Ajouter un commentaire
Réponse
+0
moins plus
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 ?
Ajouter un commentaire
Réponse
+0
moins plus
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
Ajouter un commentaire
Ce document intitulé «  Tunnelling IP-over-HTTP  » issu de CommentCaMarche (www.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes.

Le fait d'être membre vous permet d'avoir des options supplémentaires.