VPN SSL et PROXYPASS

[laal]

Bonjour à tous,

j'utilise SME 7.3 avec la contrib OpenVPN-bridge. Je voudrais pouvoir utiliser le VPN sur le port 443 (c'est le seul autorisé côté client).
Quelqu'un a t-il déjà utilisé proxypass pour réaliser cela?

Merci à vous.

laal

[jdh]

Cela ne risque guère de fonctionner !

Sans être spécialiste SME, je peux imaginer que proxypass est une contribution permettant d'aiguiller du trafic http selon le nom de domaine.

Or si OpenVPN utilise le port tcp/443 (i.e. https), d'une part proxypass ne peut pas fonctionner sur https, et d'autre part le trafic openvpn n'étant pas du http donc proxypass ne fonctionnera surement pas !

(Ce serait aussi le cas en port tcp/80 !)

(Au fait, pourquoi proxypass ne fonctionne pas pour https ? J'ai la réponse mais le lecteur l'a-t-il ?)

[laal]

Bonjour,

d'après http://bugs.contribs.org/show_bug.cgi?id=1612 proxypass supporte le ssl.

Il me semblait également que du flux ssl à travers un proxy s'établissait via un connect et que partant de là, le flux était encapsulé et que l'on pouvait y faire passer n'importe quoi.

Je pensais que quelque chose du style https://vpn.mondomaine.com vers https://localhost:1194 pouvait fonctionner.

Merci de corriger si je me plante dans mon approche.

Laal.

[jdh]

La logique, c'est que "proxypass" ne devrait pas fonctionner pour https ... parce qu'il serait comme MITM (Man In The Middle) ce que justement https est justement destiné à éviter. Je vais regarder cela, mais cela m'étonne très très fortement ...


Par contre, je suis presque certain que proxypass ne peut rien faire avec du vpn-ssl comme OpenVPN. La raison en est simple : http est un protocole texte pur dans lequel on peut lire par exemple une requête comme

GET /
http://www.domaine.com

Accept : ....

Il y a donc possibilité de trouver à quel vrai serveur est destiné le trafic concerné bien que plusieurs serveurs ait la même adresse ip.

OpenVPN créé un trafic direct entre 2 hôtes qui ne peut être analysé que d'un côté ou de l'autre du tunnel. Le receveur n'a aucun moyen de faire quoi que ce soit de ce trafic ... puisque ce n'est pas du "http" !

[jdh]

Je confirme ce que j'écrivais plus haut.

1/ OpenVPN est un protocole totalement différent de http : il ne peut être parsé pour être dispatché. Cela clôt définitivement ce type d'astuce !

2/ Proxypass est une extension d'Apache capable de dispatcher du trafic http (et non https) en fonction du nom dns du serveur.

Le "SSLEngine" est une extension d'Apache 2.0 qui permet de rediriger le trafic http vers un (vrai) serveur en https !

[laal]

Bonjour,

il est pourtant possible de mettre en œuvre des vpn ssl (pas ipsec) avec des clients derrière des proxies de navigation, et cela fonctionne.
C'est ce que j'utilise au boulot ou seul le 443 peut passer en connect sur squid, les serveurs VPN qui écoutent sur ce port là sont accessibles depuis le boulot en SSL. Comme mon SME n'a qu'une @ publique et que le 443 est utilisé je pensais pouvoir me servir d'apache en reverse pour utiliser Open VPN.
Il est bien évident que sur du SSL les proxies n'ont aucune vision de ce qui transite, ils se bornent à connecter deux machines en IP. Connecter j'ai dit? Il faut donc que je passe open VPN en TCP.


Laal.

[laal]

à jdh

J'étais en train de rédiger mon post quand le tien est arrivé, ma réponse est donc relative au précédent.

Il est effectivement possible que la version d'apache explique que ça fonctionne d'un côté et pas de l'autre.

[jdh]

(Voilà une question intéressante : elle est, pour moi, l'occasion de vérifier mon expertise !)


* OpenVPN et proxy :
Le lien http://openvpn.net/howto.html#http me semble clair : du côté client (seulement), on peut utiliser un proxy http (sous réserves que le protocole soit tcp et non udp : bien vu le "connecté" ! udp n'est pas un protocole "connecté" pour ceux qui l'ignore).

Le moins que l'on puisse dire c'est que cela ne doit pas être simple d'écrire un fichier de conf "universel" !


* Proxypass :
On est là du côté serveur : le trafic vpn-ssl est nécessairement crypté : il ne peut donc y avoir un MITM : il n'y a aucune possibilité d'analyser le flux (et de le modifier) !


Il y a donc 2 cas :

Client <--- internet -----> Serveur OpenVPN
Client <-> proxy http <---- internet ----> Serveur OpenVPN

Il faut bien comprendre que TLS/SSL crypte le trafic entre le client (ou le proxy http) et le serveur OpenVPN.



J'ai déjà eu à y réflechir, pour mon cas perso, dans une entreprise : j'ai (aussi) choisi le trafic en tcp/443 parce que je peux supposer que c'est toujours autorisé pour le client quel que soit la config réseau, mais je n'héberge pas de serveur https !

[sibsib]

J'ai déjà eu à y réflechir, pour mon cas perso, dans une entreprise : j'ai (aussi) choisi le trafic en tcp/443 parce que je peux supposer que c'est toujours autorisé pour le client quel que soit la config réseau, mais je n'héberge pas de serveur https !

Hello,

Juste pour ce point particulier :

nous utilisons sur mon lieu de travail des proxy 'bluecoat'. Ces bêtes ont deux comportements par rapport aux flux https :
1) Les URL demandés font partie d'une liste (très restreintes !) d'URL de confiance (globalement, les banques et les organismes publics) et dans ce cas, le proxy 'pousse le flux https sans l'analyser. On peut parler du fonctionnement 'normal'.
2) La demande https ne fait pas partie de ces URL et dans ce cas, le proxy Etablit lui la session https vers le serveurs, et se présente au client comme s'il était le site distant (mais avec son propre certificat !). Ce qui lui permet d'analyser le flux et donc de refuser tout ce qui n'est pas 'conforme à la charte'. Etant entendu que monter un tunnel vpm depuis le taf jusqu'à l'extérieur ne fait clairement pas partie de la charte informatique...

Je ne sais pas si ce mode de fonctionnement est exceptionnel, en tout cas çà existe, et donc, il peut être un peu 'court' de ce dire qu'en 443 on peut tout faire sortir.

A+,
Pascal

[laal]

Bonjour,

je persiste, sur un flux HTTPS, tu peux tout encapsuler (dans ton cas tu as deux flux car le buecoat est en coupure (client et serveur), celà permet d'être intrusif sur les flux au détriment de la sécurité car le certificat présenté est celui du bluecoat et pas celui du site distant ce qui doit faire monter un popup d'alerte sur les postes client (MITM), je suppose qu'il y a un reset de la connexion côté internet par le bluecoat en cas de doute sur le certificat pour contrer les fakes).

Sinon plus généralement pour éviter une polémique sur le https : comment faire pour rediriger via proxypass :

http://monsite.fr:3000 vers http://ntop.monsite.fr


Merci.

laal.

[sibsib]

Yop,

Je ne suis pas sûr d'avoir compris ton post, donc juste pour précision :

Dans notre cas, tu ne feras passer que du https conforme par notre proxy car le proxy fait une analyse syntaxique sur le contenu, et refuse ce qui n'est pas du pur html. C'est d'ailleurs pour pouvoir faire cette analyse qu'il décrypte le flux.
De plus, le bluecoat n'accepte évidemment pas les certificats autosignés, ou périmés ou créées pour une autre URL que celle demandée !

Donc, dans notre archi, tu ne montes pas un tunnel VPN sans l'accord de l'équipe sécu (Sachant que seul le proxy a le droit de passer en 443 vers l'extérieur, aux niveau des firewalls).

A+,
Pascal

[laal]

Bonsoir,

Ce que je voulais dire c'est que le bluecoat est terminaison SSL, il se comporte donc en client SSL vis à vis du site WEB et comme serveur SSL vis à vis du client (il décrypte et recrypte le flux).
Donc le client voulant surfer sur https://laposte.net se verra présenter le certificat de onorganisation.org et s'il est victime de phishing il ne poura pas le vérifier via le certificat.
C'est donc au bluecoat de vérifier le certificat et de casser la session TCP avec le serveur s'il détecte une discordance.
Dans ton cas vu que les serveurs https accessibles sont en white list, le phishing ne devrait pas pouvoir se produire car la session se verrait refusée par le bluecoat (sauf si tes DNS ne sont pas patchés et que tu te fais attaquer )


Laal.

[laal]

Bonjour à tous,

comme dirait l'autre : j'ai une bonne et une mauvaise nouvelle par quoi je commence?

Open VPN fonctionne super bien la contrib est de toute beauté !!
Proxypass fonctionne pour le https
ça c'était les bonnes nouvelles

la mauvaise c'est que proxypass fonctionne en MITM (en tout cas je n'ai pas réussi à lui faire faire du connect), donc je le sens très mal pour faire monter un tunnel VPN entre un apache et open VPN.

Je suis preneur de toute idée (ceux qui veulent me dire "je te l'avais dit" peuvent se lâcher )".

Laal.

[jdh]

Je reprends ce que j'ai écrit :

- on peut, éventuellement, utiliser un proxy du côté du client roadwarrior (grâce à CONNECT),
- proxypass est un aiguilleur de trafic http entrant,
- EN AUCUN CAS, proxypass est capable d'aiguiller du trafic https,
- à fortiori, proxypass ne peut aiguiller du trafic openvpn même défini en tcp/443 (port https).


Je confirme :

- OpenVPN est un outil efficace, simple à mettre en oeuvre, bref comme je les aime ...
- proxypass (les instructions Apache) est assez simple (pas immédiat !) mais très correct, bref bien !

[laal]

Bonsoir,

proxypass fonctionne sur du https, pour les saint Thomas du SSL : contactez moi par MP et je vous donne mes URLs (c'est une mire de login que je voudrais éviter de me faire attaquer...).

Laal.