Authentification d'un serveur proxy sur HTTPS
Lors de la navigation vers un site Web via HTTPS, le navigateur Web effectue généralement beaucoup de travail en arrière-plan - négociation d'un canal sécurisé, validation du certificat du site, vérification de la chaîne de confiance, etc.
Si votre navigateur est configuré pour utiliser un proxy Web, le protocole HTTP actuel prend en charge une méthode CONNECT - cela permet à votre navigateur de configurer le tunnel TLS vers le site Web, sans révéler le contenu de la demande au proxy (autre que le nom du site, bien sûr).
Que fait le navigateur concernant l'identité du serveur proxy?
Si le proxy ne possède pas de certificat, il peut potentiellement être emprunté par un MitM.
Même si le proxy possède possède un certificat, s'il n'est pas vérifié, il pourrait toujours être possible de l'emprunter.
Le protocole (ou toute RFC associée) définit-il comment cela doit être géré? Comment les navigateurs Web courants gèrent-ils généralement cela?
Si le proxy n'a pas de certificat, y a-t-il un retour à l'utilisateur? Si le proxy possède un certificat, mais qu'il n'est pas valide, y a-t-il des commentaires alors?
De plus, existe-t-il une disposition pour authentifier en toute sécurité le proxy Web, même lorsque la demande est en HTTP simple?
Par exemple, se connecter au proxy via HTTPS même si la demande au site Web est via HTTP ...
REMARQUE: je ne demande pas comment identifier le site Web, qu'il soit tunnelé via le proxy ou qu'il intercepte la chaîne SSL.
Au contraire, je veux vérifier l'identité du proxy lui-même, pour m'assurer qu'aucun serveur non autorisé ne m'attaque ...
Comme d'habitude, répondons d'abord à la question exacte qui a été posée.
À l'heure actuelle, l'utilisation de HTTPS pour se connecter au proxy n'est pas largement prise en charge. La documentation Squid contient quelques informations sur le sujet; pour résumer:
Chrome le prend en charge, mais il doit être configuré via un script de configuration automatique du proxy car il n'y a pas de prise en charge de l'interface graphique. Cela signifie également pas en utilisant la "configuration du proxy à l'échelle du système".
Firefox ne le prend pas en charge, bien que la fonctionnalité soit marquée comme demandée depuis 2007. (MISE À JOUR: Pris en charge dans FF 33 + )
Aucune indication sur les autres navigateurs, ce qui peut être supposé signifier "aucun support que ce soit".
Ce que Chrome fait lorsqu'il rencontre un certificat "quelque peu invalide" pour le proxy doit être testé, mais cela dépendra probablement de la version exacte du navigateur (qui change tout le temps, souvent de manière transparente), le système d'exploitation (car la gestion des certificats a tendance à être déléguée au système d'exploitation), et de quelles manières le certificat n'est pas valide (expiré, mauvais nom de serveur, ancre de confiance inconnue, ...). De plus, il existe un poulet et un Problème d'oeuf ici: la validation complète du certificat, comme le stipule X.509 , inclut la vérification de la révocation, c'est-à-dire le téléchargement de la liste de révocation de certificats pour tous les certificats dans le chemin. Mais si vous utilisez un proxy pour votre trafic HTTP, le téléchargement de la CRL devra passer par ce proxy ... et vous n'avez pas encore validé le certificat proxy. Pas de poulet, pas d'oeuf.
Nous pouvons également noter que le format de fichier de configuration automatique du proxy ne prend pas vraiment en charge le proxy HTTPS. Il n'y a pas de standard formel pour ce fichier, mais la coutume est de suivre un ancien projet Netscape qui dit qu'un fichier PAC définit une fonction Javascript qui peut retourner un proxy noms d'hôte et ports, mais pas le protocole. Donc, pas de HTTPS. Pour sa prise en charge du proxy HTTPS, Chrome utilise implicitement une extension de cette convention de facto en remplissant une URL HTTPS là où elle n'a pas le droit d'être, et en espérant pour que le navigateur donne un sens à cela.
Comme d'habitude, voyons quelles propositions alternatives peuvent être faites.
Pour garantir une communication protégée entre le client et le proxy, les deux solutions suivantes peuvent être applicables:
Utilisez un VPN . C'est très générique, et puisqu'il fonctionne au niveau du système d'exploitation, il s'appliquera à tous les navigateurs. Bien sûr, cela nécessite que quiconque installe la chose sur le client machine ait des droits administratifs sur cette machine (vous ne pouvez pas le faire en tant que simple utilisateur non privilégié).
Utilisez un proxy SOCKS basé sur SSH . Sur votre système client, exécutez:
ssh -N -D 5000 theproxy; puis configurez votre navigateur pour utiliserlocalhost:5000en tant que proxy SOCKS. Cette solution nécessite que le serveur proxy (theproxy) soit également un serveur SSH, que vous ayez un compte dessus et que le port SSH ne soit pas bloqué par un pare-feu de mauvaise humeur.
La solution proxy SOCKS garantira que le trafic passe par la machine proxy, mais n'inclut pas la mise en cache, ce qui est l'une des raisons pour lesquelles nous voulons généralement utiliser un proxy en premier lieu. Il peut cependant être modifié à l'aide d'outils supplémentaires. Le proxy SOCKS consiste à rediriger tout le trafic TCP/IP (de manière générique) via un tunnel personnalisé. La prise en charge générique des applications est possible, en "remplaçant" les appels réseau normaux au niveau du système d'exploitation par des versions qui utilisent SOCKS. En pratique, cela utilise un DLL qui est poussé sur les bibliothèques de système d'exploitation standard; c'est pris en charge dans les systèmes basés sur Unix avec LD_PRELOAD, et je suppose que cela peut aussi être fait avec Windows. La solution complète serait donc:
- Vous utilisez un tunnel SOCKS basé sur SSH de votre client vers la machine proxy.
- Le client SOCKS DLL est appliqué sur le navigateur et configuré pour utiliser
localhost:5000en tant que proxy SOCKS. - Le navigateur veut juste utiliser
theproxy:3128en tant que simple proxy HTTP.
Ensuite, lorsque le navigateur souhaite naviguer, il ouvre une connexion à theproxy:3128, que le DLL intercepte et redirige vers un tunnel SOCKS qu'il ouvre vers localhost:5000. À ce stade, SSH saisit les données et les envoie à theproxy sous la protection du tunnel SSH. Les données se terminent sur theproxy, point auquel la connexion au port 3128 est purement locale (donc à l'abri des attaquants basés sur le réseau).
Une autre façon d'ajouter la mise en cache sur la configuration SSH-SOCKS consiste à appliquer un proxy transparent . Squid peut le faire (sous le nom de "cache d'interception").
Encore une autre façon de faire de la mise en cache avec la protection SSH est d'utiliser SSH pour construire un tunnel générique de votre machine vers le proxy. Lance ça:
ssh -N -L 5000:localhost:3128 theproxy
puis configurez votre navigateur pour utiliser localhost:5000 en tant que proxy [~ # ~] http [~ # ~] (pas SOCKS). Cela n'appliquera pas le proxy sur d'autres protocoles tels que FTP ou Gopher, mais qui les utilise quand même?
Comme d'habitude, posons maintenant la question.
Vous dites que vous voulez vous protéger contre une attaque de l'homme du milie . Mais, vraiment, le proxy est un MitM. Ce que vous voulez vraiment, c'est que le proxy soit l'entité seulement faisant un MitM. HTTPS entre le navigateur et le proxy (ou SSH-SOCKS ou VPN) ne peut protéger que le lien entre le client et le proxy, et pas du tout entre le proxy et le serveur Web cible. Il serait présomptueux de prétendre que les attaques MitM sont contrecarrées de manière fiable sans tenir compte de ce qui se passe sur le Wide Internet, qui est connu pour être un endroit difficile.
Pour une protection de bout en bout contre MitM, utilisez SSL, c'est-à-dire parcourez les serveurs Web HTTPS. Mais si vous le faites, une protection supplémentaire pour le lien navigateur-proxy est superflue.
La protection du trafic entre le navigateur et le proxy est logique si vous considérez l'authentification proxy. Certains mandataires nécessitent une authentification explicite avant d'accorder l'accès à leurs services; c'est (était?) courant dans les grandes organisations, qui voulaient réserver "un accès Internet illimité" à quelques happy few (généralement, le Boss et ses subordonnés préférés). Si vous envoyez un mot de passe au proxy, vous ne voulez pas que le mot de passe soit espionné, d'où SSL. Cependant, un attaquant qui peut espionner le réseau local contrôle nécessairement une machine locale avec des privilèges d'administrateur (peut-être un ordinateur portable qu'il s'est apporté). Ses pouvoirs de nuisance dépassent déjà largement la simple sangsue sur la bande passante Internet. De plus, limiter l'accès à Internet sur une base par utilisateur correspond assez mal aux systèmes d'exploitation modernes, qui ont tendance à s'appuyer sur l'accès Internet pour de nombreuses tâches, y compris les mises à jour logicielles. L'accès à Internet est contrôlé plus efficacement sur une base par utilisation.
Par conséquent, je pense que la protection de l'accès à un proxy HTTP a certains avantages, mais uniquement dans des scénarios plutôt rares. En particulier, cela a très peu à voir avec la défaite de la plupart des attaques MitM.
Chrome côté client et Squid côté proxy peuvent fonctionner via https. Voir Secure Web Proxy pour plus de détails.
J'espère que Chrome vous avertira sur un certificat proxy non valide, mais je n'ai aucune expérience de cette configuration, je ne peux donc pas le confirmer.
Comme alternative à l'utilisation de la réponse de @Thomas Pornin (où il a suggéré d'utiliser SSH), vous pouvez utiliser le bus de service pour maintenir une connexion transparente d'un port local à un serveur distant.
L '"authentification" se produit lorsque le logiciel client proxy se connecte au bus de service ... le point de terminaison de ce bus de service peut être n'importe quoi, comme un intranet, un proxy d'entreprise, etc. Une fois que le logiciel client vous authentifie, un mini-vpn est créé (tout comme SSH).
Comment commencer
Ce client .Net est installé localement et la cible est un proxy ou un autre appareil auquel vous devez faire confiance.
Installer le pont de port
Remarque: Remplacez mentalement le client SQL et 1433 par un port de votre choix ... c'est la même chose avec ce TCP proxy basé
Ce projet permet à plusieurs serveurs NAT d'accéder à plusieurs clients NAT sur Internet via une seule connexion de bus de service.
C'est une implémentation assez intelligente qui vous fera vraiment réfléchir. Ci-dessous la source
http://blogs.msdn.com/b/clemensv/archive/2009/11/18/port-bridge.aspx
... et une autre explication de la même chose.
http://brentdacodemonkey.wordpress.com/2010/05/05/Azure-appfabric-%e2%80%93-a-bridge-going-anywhere/
En outre, il existe un projet connexe appelé "SocketShifter" sur codeplex: http://socketshifter.codeplex.com/ Bien que le site codeplex conseille d'utiliser portbridge, je vois des enregistrements à partir du (août 2010) et je ne sais pas lequel est le plus à jour. Il peut être utile d'enquêter.