You can do this with a transparent proxy. This is easy to do on Linux, if you start with a guide like This one
Then you just have to configure squid on the Linux box to send outgoing connections to your favorite anonymous proxy.
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.
Best Answer
For your reference, a very similar question about Firefox specifically was asked here.
The short answer is you can't -- not without some external program. Neither Firefox nor Chrom(e,ium) support proxy chaining out of the box, and making such a low-level networking change to these programs without editing the source code is not possible to do with a browser extension.
Older versions of Firefox had a looser security model that allowed extensions to run just about any native code; these extensions could, in theory, open up a listening port locally and create a proxy within the Firefox process, which could then be chained with the proxy set in Firefox's settings to access the Internet. I am unaware of any extensions that specifically did that, however.
With the current version of Firefox and Chrome, their security model wouldn't allow that sort of thing to happen. So you would need to run some kind of a proxy program locally that would support proxy chaining.
For example, stunnel supports proxy chaining:
CONNECT
verb from your web browser, it makes an HTTPS tunnel (authenticated by a client and server cert pair, if you wish) to a remote server and uses it as a general-purpose TCP proxy (or a different HTTP proxy that is routable from the route server) -- only requiring you to run an stunnel daemon on the remote host.This would allow you to do something like:
Firefox -> localhost stunnel -> remote server stunnel -> remote server Squid/Privoxy/etc. -> Internet
There isn't a way to simplify the local side by removing stunnel with the two browsers you cited, unless you modify the source code of the browser to implement the capability and do a build.