Redirigez TOUT le trafic Web via TLS sans VPN

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' localhostinterface 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 CONNECTSSL / 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 squidsur 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 tuncarte réseau qui peut effectuer un routage de couche 3, ni faire aucune sorte de routage de couche 2 (par exemple tap). 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.

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:

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

2. 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, mais Squidaurait 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 ...)

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

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

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

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

;This is the *client's* stunnel.conf.
[https]
accept = localhost:9020
connect = your.lan.proxy:80
client = yes
protocol = connect
;protocolHost should be the same as the "accept" for the server
protocolHost = 1.2.3.4:443
;Same CAfile, different cert and key pair
CAfile = ca.crt
cert = client.crt
key = client.key
;VERY IMPORTANT!!! Make sure it's really your server and not a MITM attempt by your local network by making sure that the certificate authority "ca.crt" really signed the server's cert
verify = 2
;More performance tweaks...
sessionCachetimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

.

;This is the *server's* stunnel.conf.
[https]
;1.2.3.4 is a publicly-routable, static IP address that can be connected to by your box that's under the firewall
accept = 1.2.3.4:443
;localhost:8118 is an example of where your local forwarding HTTP(S) proxy might reside.
connect = localhost:8118
CAfile = ca.crt
cert = server.crt
key = server.key
;VERY IMPORTANT!!! Without this, anyone in the world can use your public stunnel port as an open proxy!
verify = 2
;Set some timeouts higher for performance reasons
sessionCacheTimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

Une fois que tout est configuré, le résultat final finit par ressembler à ceci:

1. Votre navigateur Web se connecte à localhost:9020(stunnel) et le traite comme un proxy pouvant accepter les connexions HTTP et / ou HTTPS.
2. Une fois que stunnel obtient une connexion de votre navigateur, il atteint, via le proxy / passerelle de votre pare-feu, pour établir une session TLS avec votre serveur distant. À ce stade, votre client vérifie le certificat PKI de votre serveur et vice versa.
3. Une fois la session TLS établie avec votre serveur distant, Stunnel transmet les données provenant de votre navigateur, par exemple une requête HTTP ou une requête de tunnel SSL, via le proxy local et directement à votre serveur. Ce canal est crypté, donc votre réseau local ne peut pas dire ce que contiennent les données, il ne peut que le deviner en faisant une analyse du trafic.
4. Une fois que l' stunnelinstance exécutée sur votre serveur commence à recevoir des données, elle ouvre une connexion, par exemple localhost:8118, à l'endroit où votre serveur proxy HTTP (S), dans mon cas Privoxy, écoute.
5. Privoxy agit alors comme un serveur proxy HTTP de transfert normal et transmet vos demandes à Internet public via le FAI du serveur.

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.

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 Apacheou Squidfasse le proxy et un serveur SSH. Sur votre PC client, vous avez besoin d' puttyun 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) un Port 443sur /etc/ssh/sshd_configet autorisez également le transfert TCP (ajoutez AllowTcpForwarding yessur 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:

Listen 127.0.0.1:8080
ProxyRequests On
<Proxy *>
  Order deny,allow
</Proxy>

Serveur terminé, configurons votre PC client:

Sur putty, configurez l'IP publique de votre Debian en tant que Hostet en 443tant que port. Assurez-vous que SSHest toujours sélectionné. Modifiez les Connection -> Proxyparamètres, sélectionnez HTTPet remplissez vos paramètres de "proxy restrictif". Modifiez les Connectionparamètres et établissez une durée de vie de 30- 60. Passez à Connection -> SSH -> Tunnels. Sur source porttablir 8080, et Destination, localhost:8080. Laissez Localsélectionné et appuyez sur Add. Vous devriez voir dans l'espace au-dessus de quelque chose comme L8080 locahost:8080. Revenez aux Sessionparamètres, notez un nom sur la première ligne de Saved sessionset enregistrez tous ces paramètres fastidieux pour aider à rétablir la connexion les jours suivants.

Vous pouvez maintenant essayer de vous Openconnecter à 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 localhostau port 8080comme proxy.

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/