Oopsa, desproxy does not work transparently. You either set a socks proxy in the browser or whatever application, or you explicitly tell the application to connect to the desproxy internal ip and listening port.

Back to step 1. Need a tap ethernet adaptor that sends everything to desproxy. Like proxpn does in windows with a virtual ethernet adaptor.

How do I do the tap?

If your goal is to use proXPN why don't you just ask them if you can use the VPN software your distro already includes? Judging by their manual setup instructions for iPhones, I'd say as long as you have support for PPTP you should be good to go. That said, this is quite different from transparent HTTPS proxying, so if you really want to dive into this topic I'll have to ask you to open a new thread in Networking and mark this one as solved. You're welcome to post a link here to the new thread if you wish. TIA.

I did ask 2 years ago, and they sent me an .ovpn file, two certificates and a key, but said they do not support linux. Crucially, their unpaid service is much too slow, so I would only use them as a last resort.

It seems unlikely that nobody has come up with a way to TRANSPARENTLY pass arbitrary tcp/ip to a proxy with the CONNECT method. Would that be called a relay? Can't a tap/tun ethernet adapter send everything to the proxy with the CONNECT method?

Ultrasurf is the fastest anonymity provider, it is worth the effort.

Httptunnel seems to be closer to transparent, but what iptables rules do I need for it?

Or there is pppd that makes things transparent:

"The main problem with firewall piercing is to create a tunnel." ... "The secondary problem is to transform this connection into a full IP access for normal programs to use transparently." ... "For the secondary problem, IP emulators (pppd or SLiRP) are run on each side of the tunnel"

But what are the pppd commands for this?

Is it possible to set a system-wide SOCKS proxy at the machine where desproxy is running and where desproxy is offering the SOCKS proxy?

If yes, how would you tell the system to make an exception and not apply the SOCKS setting to desproxy and ultrasurf's .exe?

Again, you've changed the topic from transparent HTTPS proxying to tunneling/encapsulation. That is a completely separate topic. Open a thread in Networking for it. You can't transparently proxy HTTPS without doing a MITM attack. If you could, then HTTPS would be pointless.

Just found transocks which transparently socksifies everything coming from an iptables rule so everything can go to desproxy-socks4 which converts it to CONNECT methods which any HTTP proxy accepts.

In other words, it is possible to transparently send ALL tcp/ip traffic to a HTTP proxy, HTTPS would be accepted too as if it came from a browser with the proxy specified in its settings.

This is one step from being solved, here's the iptables rules that should work with transocks, taken from here:

LOCAL_NET=192.168.0.0/16

iptables -t nat -X SOCKSIFY
iptables -t nat -N SOCKSIFY
#Exceptions
iptables -t nat -A SOCKSIFY -o lo -j RETURN
iptables -t nat -A SOCKSIFY --dst 127.0.0.1 -j RETURN
iptables -t nat -A SOCKSIFY --dst $LOCAL_NET -j RETURN
#Avoid feedback loops
iptables -t nat -A SOCKSIFY -m owner --cmd-owner transocks -j RETURN
#Log
iptables -t nat -A SOCKSIFY -j LOG -p tcp --syn --log-level info \
--log-prefix "SOCKSify "
#Send to transocks
iptables -t nat -A SOCKSIFY -p tcp -j REDIRECT --to-port 1211

# Socksify traffic leaving this host:
iptables -t nat -A OUTPUT -p tcp --syn -j SOCKSIFY

# Socksify traffic routing through this host:
iptables -t nat -A PREROUTING -p tcp -s $LOCAL_NET --syn -j SOCKSIFY

Except I do not know enough about iptables to know where in the firewall script to put these rules. Can they just go where my old PREROUTING rule went (a rule mentioned in the beginning)?

If by now you still don't understand that for transparent HTTPS proxying to work (MITM attacks aside) the proxy server needs to actually have the cryptographic keys to the encrypted HTTP content, then I don't know if you ever will. No matter how many SOCKS servers, TCP tunnels, or VPNs (or whatever else you manage to think of) you set up, the fact that in the end all you're doing is encapsulating and/or routing packets between a client and a HTTPS server isn't going to change without the keys. Since that doesn't come even remotely close to transparent HTTPS proxying, I've asked you at least twice to open a dedicated thread for your barrage of off-topic questions. Given that you're unwilling to comply with my request, I'm using force to put an end to this.