I've set up an anonymous squid proxy server, and it works completely fine, but I haven't found anything about how to encrypt the traffic between me and the server itself. Where to start?

migrated from security.stackexchange.com Aug 27 '14 at 7:19

This question came from our site for information security professionals.


The Squid documentation references this: http://wiki.squid-cache.org/Features/HTTPS#Encrypted_browser-Squid_connection

However, the problem likely isn't configuring Squid, it's finding a browser that works properly...

Chrome supports a HTTPS proxy connection, but only via an autoconfiguration PAC file or the command-line option --proxy-server (see http://dev.chromium.org/developers/design-documents/secure-web-proxy)

Firefox is still "working on it", see https://bugzilla.mozilla.org/show_bug.cgi?id=378637 (7 years and counting). finally supports this as of version 33, (thanks to Dan for the update).

Running a local (on the same machine as the browser) stunnel as a proxy wrapper would solve this for any browser, but might not suit your intended deployment. This useful page shows how to create such a setup (with optional PAM authentication too):


Note this is a completely different thing to using stunnel to tunnel through a HTTP proxy via CONNECT, that's the more commonly documented scenario. Your solution using SOCKS via SSH is roughly equivalent in some senses, but you don't have HTTP support, it's unrestricted (think CONNECT to any port), you don't have caching, and authentication isn't handled by the browser.

If you're using proxy authentication and you want to protect any credential headers, this (HTTPS client-proxy connection) is a good plan. Otherwise this setup might not solve all the problems one hopes it does, and HTTPS connections become double encrypted, which (at least) adds further to connection latency.

  1. you're connecting to a HTTP site: unencrypted traffic leaves the proxy anyway
  2. you're connecting to a HTTPS site: there's nothing in the client-proxy that really needs encrypting except the target of the CONNECT requests (i.e. website hostname), but the TLS client hello will probably have an SNI containing that name, and the server hello will almost certainly have a server certificate, either of which can be intercepted

Another case where it would add value is using client certificates for proxy authentication (but browsers don't support that either), this is reported to work in Firefox (see bug 209312).

This issue was recently flagged by CERT: Vulnerability Note VU#905344 HTTP CONNECT and 407 Proxy Authentication Required messages are not integrity protected as a result of the FalseCONNECT MITM attack.

  • 1
    thanks for the guidance, I've added some more info on how I managed to do it – Rápli András Oct 1 '14 at 10:01
  • 1
    HTTPS proxy support is marked fixed in Firefox 33. Anyone know the status of Safari and IE? – Dan Dec 23 '14 at 16:17
  • Thx for the update. Sorry can't find details on those browsers... – mr.spuratic Dec 24 '14 at 0:13

I'm typing here the exact command which I now use for setting up a 2048-bit encryption to the proxy server:

ssh -C2qTnN -D 8080 user@remote-address

while your browser's proxy settings (the same ugly window that pops up for IE settings) must point to for the SOCKS field, all others left blank (as normally talking about a SOCKS proxy)

Obviously all other ports may work if opened on the remote server.

  • I (subjectively) found dynamic forwarding to be slower than using a single-port tunnel to Squid. Some programs may not support SOCKS either. – Daniel B Oct 1 '14 at 11:00

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.