Hypothèses:
Serveur:
- J'ai un serveur Debian Squeeze, routable sur Internet public, avec une adresse IPv4 statique.
- J'ai un accès illimité pour modifier le logiciel sur le serveur.
- Le serveur peut écouter sur des ports arbitraires, reconfigurer les règles du pare-feu, fondamentalement, il n'y a aucune restriction sur ce que le serveur peut faire.
Client:
- Je peux exécuter Firefox, des programmes Java, des programmes .NET et certains exécutables natifs qui ne nécessitent pas d'accès administrateur sur mon système local (un bureau Windows verrouillé sans droits d'administrateur).
- Je peux installer des modules complémentaires dans Firefox.
- Je peux écouter sur n'importe quel port de l'
localhost
interface loopback ( ). Ainsi, les programmes susmentionnés peuvent se lier à un port local et effectuer des E / S réseau arbitraires, sans passer par un proxy. - Tout accès public à Internet est acheminé via un proxy HTTP restrictif qui bloque de nombreux sites et effectue une inspection minutieuse avec état. Sur le port 80, il autorise exclusivement HTTP (pas TLS / SSL). Sur le port 443, il autorise
CONNECT
SSL / TLS basé sur des hôtes distants qui ne sont pas bloqués par le nom de domaine / l'adresse IP. - Le proxy HTTP restrictif n'effectue pas d' inspection approfondie des paquets des connexions TLS autorisées via le proxy, et il n'effectue pas d' attaques Man in the Middle sur ces connexions.
- Le serveur susmentionné auquel j'ai accès n'est pas bloqué par le proxy.
Objectif:
Je souhaite acheminer toutes les demandes HTTP et HTTPS émises par Firefox, via le serveur ci-dessus, via SSL / TLS.
Autres notes sur le "But":
- Même si le site de point de terminaison (par exemple,
http://superuser.com
) n'utilise pas SSL / TLS sur mon serveur, je souhaite toujours utiliser SSL / TLS de mon client sur mon serveur et demander à mon serveur d'exécuter la requête HTTP - cryptée ou non - - à ma destination souhaitée. - Je me fiche que mon serveur regarde le trafic SSL "en clair". En d'autres termes, je n'ai pas besoin d'un cryptage SSL complet de bout en bout de mon client local, jusqu'au serveur distant, si le serveur distant est accessible par exemple
https://google.com
. En d'autres termes, je fais confiance au serveur pour garder mes données confidentielles. - Je suis prêt à installer des logiciels ou des extensions Firefox qui ne nécessitent pas de droits d'administrateur et peuvent fonctionner sur Windows 7 32 bits.
- Les logiciels libres sont préférés aux logiciels propriétaires et les logiciels gratuits aux logiciels nécessitant des frais de licence.
- Les logiciels existants sont préférables à devoir coder de nouveaux logiciels, bien que je sois prêt à écrire du code si c'est la seule façon.
Je suis à la recherche d'une "solution" vaguement décrite qui décrit:
- Quel logiciel serait requis sur le client? S'il existe un progiciel spécifique que vous connaissez, nommez-le; sinon, décrivez ce que le logiciel client devrait faire .
- Quel logiciel serait requis sur le serveur? S'il existe un progiciel spécifique que vous connaissez, nommez-le; sinon, décrivez ce que le logiciel serveur devrait faire .
- Si vous avez nommé des progiciels spécifiques ci-dessus, décrivez les paramètres de configuration qui seraient nécessaires pour le configurer afin d'atteindre mon objectif.
- Si, pour une raison quelconque, vous croyez que ce n'est pas possible , expliquez pourquoi .
Choses que j'ai essayées et qui ne fonctionnent pas
- En installant
squid
sur mon serveur, j'ai essayé de configurer mon propre proxy HTTP standard sur mon serveur. Cela n'a pas fonctionné, car lorsque je demande des sites Web dans Firefox via HTTP standard, Firefox essaie également d'accéder à mon serveur via HTTP standard! Ce n'est pas acceptable, car le proxy sur mon réseau local peut bien sûr observer et / ou bloquer le trafic HTTP régulier entre mon client et le serveur. - Les VPN ne fonctionnent pas , pas même OpenVPN sur TLS à l'écoute sur le port 443, car je n'ai pas les autorisations sur l'ordinateur local pour installer une
tun
carte réseau qui peut effectuer un routage de couche 3, ni faire aucune sorte de routage de couche 2 (par exempletap
). En bref: j'aurais besoin de droits d'administrateur pour installer OpenVPN, et même si j'avais ces droits d'administrateur temporairement, la société ne serait pas très satisfaite s'ils la trouvaient installée. Un programme Java ou .NET est beaucoup moins visible, en particulier lorsqu'il n'est pas installé dans Ajout / Suppression de programmes et n'a pas de composant de pilote de noyau comme OpenVPN.
socat
privilèges administratifs sur la boîte client Windows.Réponses:
Je l'ai compris. : D Cette solution répond à toutes mes exigences et répond parfaitement à tous mes objectifs. Les performances ne sont pas trop mauvaises non plus, compte tenu du niveau d'indirection qui est nécessaire pour y parvenir.
L'approche générale est donc la suivante:
Configurez une autorité de certification (CA) locale et générez une "clé de serveur" et une "clé de client" RSA (j'ai utilisé un cryptage 256 bits). Pour cela, j'ai utilisé Easy-RSA version 3.0.0-rc2.
Exécutez n'importe quel proxy HTTP standard sur la «Debian Box» (le serveur sur Internet public), en vous assurant de l'écouter uniquement sur localhost (il ne doit PAS être exposé à Internet public). Pour mes besoins, j'ai utilisé
Privoxy
, maisSquid
aurait aussi bien fonctionné. Puisqu'il n'écoute que sur localhost, l'authentification n'est pas nécessaire (sauf s'il y a des processus en cours sur votre box auxquels vous ne faites pas confiance; dans ce cas, yikes ...)Téléchargez stunnel et installez-le sur le client et le serveur. Le processus pour ce faire va être spécifique au système d'exploitation; dans mon cas, j'ai choisi de compiler stunnel à partir de la source (paranoïa ...) pour Windows, ce qui était un processus assez compliqué que je ne détaillerai pas ici. Côté serveur, il était disponible dans le gestionnaire de paquets :)
La configuration de Stunnel était assez intimidante au début, mais c'est plus simple qu'il n'y paraît! Fondamentalement, sur le serveur, vous avez besoin de quelque chose comme le "stunnel.conf du serveur" ci-dessous. Sur le client, vous avez besoin de quelque chose comme le "stunnel.conf du client" ci-dessous.
Démarrez Privoxy; démarrer stunnel sur le serveur, en le pointant vers le fichier de configuration; démarrer stunnel sur le client, en le pointant vers le fichier de configuration. Il n'y a vraiment rien de spécial dans la configuration de Privoxy; le défaut était bien pour moi.
Dans Firefox, votre navigateur de choix côté client, définissez le proxy HTTP et HTTPS pour être le même que le port stunnel de votre client écoute - probablement quelque chose comme localhost: 8080.
Je devrais probablement noter que si le proxy de votre réseau local exige une sorte d'authentification, vous devrez soit obtenir un stunnel pour vous authentifier, soit utiliser un autre proxy d'interception local et les enchaîner - quelque chose comme Firefox -> stunnel -> local proxy d'authentification -> proxy / passerelle LAN -> internet -> stunnel de votre serveur -> privoxy.
C'est beaucoup de copie, mais ça marche!
.
Une fois que tout est configuré, le résultat final finit par ressembler à ceci:
localhost:9020
(stunnel) et le traite comme un proxy pouvant accepter les connexions HTTP et / ou HTTPS.stunnel
instance exécutée sur votre serveur commence à recevoir des données, elle ouvre une connexion, par exemplelocalhost:8118
, à l'endroit où votre serveur proxy HTTP (S), dans mon cas Privoxy, écoute.La quantité de sockets et de tampons impliqués rend cette méthode très lourde, surtout si vous imbriquez une connexion SSL via le proxy, mais elle a l'avantage que votre réseau local n'a aucun moyen de savoir quels sites vous visitez via SSL. Je veux dire, il sait que vous visitez votre serveur, mais à part cela, il ne sait pas si vous visitez Gmail ou SuperUser ou autre chose. Et votre passerelle locale n'a aucun moyen de vous filtrer ou de vous bloquer.
la source
J'ai essayé cette configuration sur ma machine locale, et je peux vous assurer que le "proxy restrictif" obtiendrait un
CONNECT DEBIAN_IP:443 HTTP/1.1
, mais il ne verrait aucun certificat, donc je ne suis pas sûr que cela fonctionnerait.Supposons que votre Debian possède
Apache
ouSquid
fasse le proxy et un serveur SSH. Sur votre PC client, vous avez besoin d'putty
un programme qui n'a pas besoin de privilèges d'administrateur pour s'exécuter, pas besoin d'installation et qui pourrait s'exécuter à partir d'une clé USB.D'abord votre Debian:
Faites écouter votre SSH sur le port
443
, ajoutez simplement (ou remplacez votre port actuel) unPort 443
sur/etc/ssh/sshd_config
et autorisez également le transfert TCP (ajoutezAllowTcpForwarding yes
sur ce fichier)Configurez votre Squid ou Apache pour faire du proxy. Étant donné que cela va être utilisé via un tunnel SSH, il suffit d'écouter sur l'interface de bouclage. Si vous utilisez un Apache:
Serveur terminé, configurons votre PC client:
Sur putty, configurez l'IP publique de votre Debian en tant que
Host
et en443
tant que port. Assurez-vous queSSH
est toujours sélectionné. Modifiez lesConnection -> Proxy
paramètres, sélectionnezHTTP
et remplissez vos paramètres de "proxy restrictif". Modifiez lesConnection
paramètres et établissez une durée de vie de30
-60
. Passez àConnection -> SSH -> Tunnels
. Sursource port
tablir8080
, etDestination
,localhost:8080
. LaissezLocal
sélectionné et appuyez surAdd
. Vous devriez voir dans l'espace au-dessus de quelque chose commeL8080 locahost:8080
. Revenez auxSession
paramètres, notez un nom sur la première ligne deSaved sessions
et enregistrez tous ces paramètres fastidieux pour aider à rétablir la connexion les jours suivants.Vous pouvez maintenant essayer de vous
Open
connecter à votre Debian. Si vous voyez l'invite de l'utilisateur, nous ne sommes qu'à une étape de la fin. Sinon ... nous devrons chercher un autre moyen.Maintenant, sur Firefox, définissez
localhost
au port8080
comme proxy.la source
Vous êtes à mi-chemin avec la configuration d'un proxy sur votre serveur. L'autre moitié est SSL sur le serveur, et un proxy local sur le client utilisant du mastic pour se connecter à votre proxy HTTP compatible SSL, et configurez Firefox pour tout proxy à 127.0.0.1.
Je viens de faire un rapide google pour une configuration de mastic et j'ai trouvé ceci: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/
la source