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

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

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 :-(

Alors Sebsauvage du nouveau? ;-)

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!!!

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 ....)

Ç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 .Ô       Castor - Pour le retour de Bobo                                                                                (_)__   A mort les ergonomes et le point d'interrogation tout moche

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 ?

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
.Ô       Castor - Pour le retour de Bobo                                                                                (_)__   A mort les ergonomes et le point d'interrogation tout moche