Redirigez TOUT le trafic Web via TLS sans VPN

10

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.
allquixotic
la source
Essayez-vous des chaussettes? vous pouvez le définir sur le port 443 de votre serveur.
Ashian
Pouvez-vous utiliser la solution décrite dans cet article: VPN HTTP du pauvre ? Notez que son lien vers HTTPTunnel est incorrect.
harrymc
1
delegate.org pourrait être utile.
Arjan
@Ashian Non, SOCKS ne fonctionnera pas, sauf s'il est enveloppé dans TLS. SOCKS n'est pas un protocole basé sur HTTP, donc quand il frappe le proxy interne, il sera bloqué. Et si je devais pouvoir l' exécuter par TLS, je serais probablement utiliser un protocole différent. Mon premier problème est de configurer le tunnel TLS de manière à ce que Firefox puisse l'utiliser. Je n'ai toujours pas vu d'explication sur la façon de procéder.
allquixotic
@harrymc: le titre de la question dit via TLS . Le tunnel HTTP achemine les paquets IP sur HTTP , qui n'est pas chiffré et n'utilise pas TLS. L'article lui-même dit que la connexion n'est pas cryptée. Il n'y a aucun moyen que mon mandataire laisse passer ça. De plus, je n'ai pas de socatprivilèges administratifs sur la boîte client Windows.
allquixotic

Réponses:

5

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.

allquixotic
la source
2

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.

NuTTyX
la source
Malheureusement, cela ne fonctionnera pas, car le protocole SSH n'est pas basé sur SSL / TLS. Lorsque le proxy restrictif de mon côté client renifle la connexion passant par le port 443, il sait instantanément que ce n'est pas un socket TLS et le supprime. Certes, je pourrais l' envelopper dans TLS, mais ce n'est pas ce que votre réponse décrit.
allquixotic
J'ai fait un test avec un proxy HTTP (BURP) et j'ai travaillé, donc ça valait la peine d'essayer. Envelopper SSH sur TLS et le faire fonctionner pourrait devenir délicat, cependant ...
NuTTyX
SSH sur TLS est une indirection inutile. Si vous avez déjà le socket TLS en cours, vous n'avez pas vraiment besoin de SSH. Voir ma réponse ci-dessous. (Remarque: je ne connaissais cette réponse que récemment, donc ce n'est pas comme si j'appuyais votre réponse et que je postais la solution. J'ai littéralement découvert cela il y a environ 25 minutes.)
allquixotic
Heureux que vous l'ayez résolu
NuTTyX
1

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/

Joe
la source
Pour être juste, il est entré dans beaucoup plus de détails avec son poste. Merci pour le vote, cependant.
joe
@krowe Nulle part dans ma réponse ne dit-il "Apache" ou "PuTTY".
allquixotic
Non, ça ne me dérange pas que vous ayez voté pour cette réponse! J'ai simplement interprété votre commentaire comme disant que j'étais en quelque sorte en train de piquer sa réponse ou de l'arracher, alors qu'en fait, je n'ai pas vraiment gagné beaucoup de cette réponse lorsque je cherchais une solution. Rétrospectivement, le blog lié à semble être une bonne alternative à la réponse que j'ai publiée, bien que je ne sois pas sûr de la façon dont cela différerait en termes de performances, de fonctionnalités, etc. (pourrait être meilleur ou pourrait être pire).
allquixotic
+1 J'aime celui-ci car je lance quand même un serveur web.
krowe