HTTP Proxy SSL - Page 1

Je me pose une petite question sur les fonctionnements des proxy HTTP.

En regardant comment configurer un Apache (*) en forward proxy, je me suis rendu compte qu'il n'y avait rien pour le SSL.
Il y a bien une option pour autoriser la méthode CONNECT et qui est spécifique au SSL, mais c'est tout.

Du coup, je me demande comment le proxy fait-il du SSL si on ne lui spécifie pas de certificat
j'ai vaguement regardé avec CocoaPacketAnalyzer (sur une requête ), et j'ai eu l'impression que ma page était chiffrée entre le client web et le proxy (en tout cas, je n'ai pas reconnu son contenu). Après, je comprends que ça soit chiffré entre le proxy et le site web, je me pose simplement la question pour la partie entre le client et le proxy.



* oui, je sais, Squid est mieux, mais je connais déjà assez bien Apache.

Le proxy se contente de faire passer la requête sans la modifier?

Dans la couche ISO, le SSL n'est pas vraiment au même niveau que le HTTP. Le SSL se trouve entre le TCP et le HTTP. Donc l'un se configure indépendamment de l'autre.
Surement que dans ta conf, le SSL est déjà configuré ailleurs.

Hibou > non, le proxy n'a aucune conf SSL. Mais apparemment, la requête n'est apparemment pas modifiée du tout. Il y a simplement les en-têtes qui sont en clair, permettant au proxy d'agir.

Ce qui veut dire qu'on ne peut théoriquement pas avoir un proxy qui fasse du SSL entre un client et un serveur en HTTP.

il lui faudrait au moins un certificat non?

ça me parait chaud, surtout parce que le client n'aurait aucun moyen de vérifier le certif du serveur distant, ou alors il faudrait un espèce de MITM.

squalyl > oui, évidemment ^^

Mais on pourrait soit faire du MITM (ce que permet Squid, mais c'est un hack de la RFC), soit encapsuler la communication du client vers le serveur (SSL ou pas) dans du SSL, quitte à faire du SSL dans du SSL (le tout dans un VPN naturellement ).

Je trouve dommage que le protocole HTTP ne permette pas de faire ça proprement. Si on est à un endroit pas franchement digne de confiance (wifi public, par exemple), on est obligé de faire un VPN alors qu'un simple proxy chiffrant serait bien simple à utiliser.

http est un peu merdique sur SSL oui, ça fait des années que je cherche comment faire des putains de vhosts sur ssl, mais apparemment c'est impossible car le certificat est négocié avant que le serveur sache quel Host: lui parle

En fait, j'ai appris récemment (merci Bob ) que c'était vrai avant, mais que ça a changé (RFC jesaispluscombien). Il suffit de définir un certificat dans le vhost, et ça marche, sans rien faire (testé et approuvé ^^)

Par contre, ça ne marche pas avec les vieux IE.

aha, faut que je tente!

squalyl (./7) :
http est un peu merdique sur SSL oui, ça fait des années que je cherche comment faire des putains de vhosts sur ssl, mais apparemment c'est impossible car le certificat est négocié avant que le serveur sache quel Host: lui parle

ta solution s'appelle le SNI. C'est globalement bien supporté, mais si tu as des clients qui trainent de vieilles versions
, c'est moisi.


(et au passage : http://en.wikipedia.org/wiki/Server_Name_Indication )

et pour la question en ./1, la question est de savoir si tu veux triturer la requête (ou réagir différemment selon le contenu de la requête) ou pas. Si tu as pas besoin de triturer, en toute logique, tu as pas besoin de déplomber le ssl. Sinon, tu as besoin d'héberger le ssl sur ton proxy. L'exemple type, c'est la configuration apache en mode "WAF", où tu vas faire proxy, et mod_security va s'occuper de regarder de plus près ta requête => le SSL doit être sur le proxy et pas sur la cible.

L'idée à la base, c'était de savoir si on pouvait « remplacer » un VPN par un simple proxy (ce qui est quand même plus simple d'emploi), en encapsulant dans du SSL toutes les requêtes vers le proxy, qu'elles soient dans du SSL ou pas quand elles vont du proxy vers le serveur.

edit : hmmm, rien à voir