How to encrypt connection to a squid proxy server
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):
https://congcan.wordpress.com/2014/04/16/how-to-setup-a-secure-web-proxy-using-ssl-encryption-squid-caching-proxy-and-pam-authentication/
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.
- you're connecting to a HTTP site: unencrypted traffic leaves the proxy anyway
- 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.
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 127.0.0.1:8080 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.