Bypass Proxy

From YobiWiki
Revision as of 17:50, 1 May 2015 by <bdi>PhilippeTeuwen</bdi> (talk | contribs) (→‎SOCKS5)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Comment passer outre un proxy (mal configuré)

Background

L'article Tunneling SSL Through a WWW Proxy dont une copie est visible sur Bypass Proxy reference

Introduction: Cela marche-t-il sur mon proxy?

La première chose à faire est de voir si vous pouvez passer manuellement à travers votre proxy.
Après, on verra comment "automatiser" et crypter la méthode si ça marche (qqs scripts faits pour vous attendent)
Lorsque Mozilla se connecte à un serveur https à travers un proxy, il fait exactement la même chose que ce que nous allons utiliser: il emploie une commande CONNECT cf l'article donné comme background pour une description + complète.
Essayez: 

telnet <proxy-server> <port du proxy>

puis (attention, frappe à l'aveugle...) 

CONNECT www.bxlug.be:80 HTTP/1.0
1 return ou +

puis si ca marche le proxy renverra une chaîne style 

HTTP/1.0 200 Connection established
Proxy-Agent: firewall wwwd

et là vous accédez de facon normale au service, exemple ici: 

GET / HTTP/1.0
1 return ou +

Et vous pouvez tester ainsi le service que vous désirez, par exemple: 

CONNECT www.teuwen.org:22 HTTP/1.0
->
HTTP/1.0 200 Connection established
Proxy-Agent: firewall wwwd
SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1

Vous pouvez aussi recevoir un truc style 

HTTP/1.0 407 Proxy-Auth
Proxy-Authenticate: Basic realm=proxy
Server: CSM Proxy Server
PROXY AUTHORIZATION ERROR
[etc]

si vous devez vous identifier à votre proxy.
Dans ce cas, un truc qui fonctionne parfois est de d'abord sortir sur le Net avec votre browser IE qui s'identifiera façon NT si le proxy est M$.
Le proxy vous reconnaîtra alors par après pour qqs temps.
Sinon, vous devez inclure une string d'identification avec la commande CONNECT mais c'est déjà plus complexe.
A la main, à part l'auth basique en base64, je ne vois pas trop, les autres sont un peu trop complexes pour se faire manuellement. 

CONNECT host:port HTTP/1.0
Proxy-Authorization: basic dXNlcjpwYXNzd29yZA==

Où la string dXNlcjpwYXNzd29yZA== a été obtenue par 

echo -n "user:password" |base64-encode
(package mime-codecs dans la Debian, d'autres utils existent aussi)

Si le proxy est bien configuré il ne devrait pas vous laisser passer sur n'importe quel port comme je le fais mais uniquement sur les ports pour les services sous TLS/SSL: https:443 imaps:993 ...
Dans ce cas vous devrez mettre votre ssh par exemple sur un tel port.
PS: Vous pouvez employer netcat au lieu de telnet, vous verrez ce que vous taperez, ca peut aider...
Bon hack!


Utilisation de SSH à travers un proxy

Récupérez la dernière version du script
Installez le script dans par exemple /usr/local/bin/ssh-tunnel.pl


Dans ~/.ssh/config ajouter une section du style: 

 Host hal
   HostName www.teuwen.org
   ProxyCommand /usr/local/bin/ssh-tunnel.pl <nom du proxy> <port du proxy> %h %p

ou pour activer la détection automatique, en bas du ficher config: 

 Host *
   ProxyCommand /usr/local/bin/ssh-tunnel.pl - - %h %p

avec un fichier ~/.ssh/proxy.conf style 

# SSH Tunnel configuration file.

# Section: OPTIONS
[option-section]
debug   = 0
dry     = 0
timeout = 1

# Section: PROXY
[proxy-section]

# Example
1.2.3/24   myproxy:8080

# Section: PROXY2 - new format
# Syntax for each line:
# subnet[\w]proxy:port[\w]{options}
[proxy2-section]

# Example
1.2.3/24   myproxy:8080 -C /tmp/clbanner.txt

Le script fonctionne aussi bien sous linux que sous cygwin

Exemple de bannière à mettre dans /tmp/clbanner.txt: 

SSH-2.0-OpenSSH_4.6p1 Debian-5

Si la bannière n'est pas correcte elle sera corrigée automatiquement et au 2ème essai cela marchera.

Utilisation de SSH à travers un proxy requérant une identification

Il faut envoyer en plus la string d'identification au proxy Dans proxy.conf il suffit d'ajouter le login et pwd dans une 3ème et 4ème colonne

Having fun with socat, bash & file descriptors...

This section will show some alternatives to what the Perl script is capable of, just to show interesting capabilities of bash & socat people could not think about:

Could socat send the ssh client banner in advance then eats the real client banner later, as the Perl script can do, to force some stupid proxies to talk to the destination?

Let's re-explain the issue:

  • We want to connect to a SSH server through a HTTP proxy
  • We've to send a CONNECT command to the proxy and the proxy will reply, we hope, a "Connection established" message.
  • The problem is that some proxies will reply ok even before having tried to establish anything. Such a proxy will first wait for the first line of the client then only establish the connection to the server and forward the line to the server. This is logical for HTTP where the first command comes from the client (GET...) but in a SSH session the server is the first to send its banner.
  • So we'll send what will be the client banner to provoke the proxy to connect the server and get its banner. Once the client will get the server banner it'll start speaking, sending its own banner, which we've to intercept otherwise the server will get twice the client banner.
 Proxycommand /usr/local/bin/socat -%%SYSTEM:"(echo -n -e 'SSH-2.0-OpenSSH_5.1p1 Debian-3\r\n'; \
   read -n 32;exec cat)" TCP:%h:%p

Little explanation:

  • We use SYSTEM rather than EXEC because we've to execute some bash scripting. EXEC expects a single command so you'd have to do sth like EXEC:"bash -c '(echo ...'"
  • socat has to modify only the client-to-server channel, therefore the "-%SYSTEM" construction.
  • % is repeated because it's a metachar of Proxycommand we've to escape.
  • The bash operations are performing what we explained before on the client-to-server channel: sending the banner, eating the banner from the client, then forwarding the communication from that point.
  • The client banner is here hardcoded, not the best solution...
  • "exec cat" replaces the current bash script by the last command, cat, to have one less process.

Now let's take the connection to the proxy into account, using the native capabilities of socat: 

 Proxycommand /usr/local/bin/socat -%%SYSTEM:"(echo -n -e 'SSH-2.0-OpenSSH_5.1p1 Debian-3\r\n'; \
   read -n 32;exec cat)" PROXY:%h:%p|TCP:my.proxy:8080

Now can we get rid of socat? Using only bash?? Yes! 

 Proxycommand /usr/local/bin/bash -c 'exec 3<>/dev/tcp/my.proxy/8080;echo -n -e "CONNECT %h:%p HTTP/1.0\r\n\r\n" >&3 ; \
   read -n 39 <&3;(exec cat <&3 &); echo -n -e "SSH-2.0-OpenSSH_5.1p1 Debian-3\r\n" >&3; read -n 32;exec cat >&3'
  • Note that I'm using a /usr/local/bin/bash, a recompiled version of bash because Debian disabled this nice capability of bash. For safety they say... did they even notice gawk is also capable of TCP?? Anyway this choice doesn't have proper rationale than "shut up, we know what's good for you". Thanks Debian...
  • read -n 39 is there to eat the reply of the proxy, could be different on yours...
  • At the end 3 processes will run: ssh and two "cat", one being in background. The problem is that that last one won't be killed at the end of the session.

How to replace the two "cat" to maintain the bidirectional communication? 

 Proxycommand /usr/local/bin/bash -c 'exec 3<>/dev/tcp/my.proxy/8080;echo -n -e "CONNECT %h:%p HTTP/1.0\r\n\r\n" >&3; \
   read -n 39 <&3; echo -n -e "SSH-2.0-OpenSSH_5.1p1 Debian-3\r\n" >&3; head -c 50 <&3; read -n 32; \
   exec /usr/local/bin/socat - FD:3'

Back with socat, here used just to maintain the forwarding between stdin/stdout and file descriptor 3.

  • If you compare it with the two cat solution, note that forwarding from server to client was done before as the client will send its banner only once it gets something from the server. To achieve the same we introduced the "head -c 50" to forward part of the server-to-client communication before eating the client banner.
  • "head -c 50": the number 50 is not that important, it has to be bigger than the server banner (usually between 20 and 35 chars) and smaller than the first server packet (about 800 chars)

Hum ok but didn't we want to get rid of socat? (a reason could be that under Windows/cygwin socat is considered as "undesirable" by McAfee, no comment :-( ) 

 Proxycommand /usr/local/bin/bash -c 'exec 3<>/dev/tcp/my.proxy/8080;echo -n -e "CONNECT %h:%p HTTP/1.0\r\n\r\n" >&3; \
   read -n 39 <&3; echo -n -e "SSH-2.0-OpenSSH_5.1p1 Debian-3\r\n" >&3; head -c 50 <&3; read -n 32;\
   exec multitee 0:3 3:1'

Multitee (source here, also packaged in Debian) can do exactly what socat was doing: "socat - FD:3" == "multitee 0:3 3:1".
To compile multitee on Cygwin, see here

Using SSH as a proxy

ssh -D 1234

Or using putty, add a dynamic port forwarding (specify local port and no dest)

This simply enables ssh as a SOCKS v5 proxy.
Points your browser to the localhost:1234 socks proxy and enjoy!

Note that by default Firefox still does the DNS queries locally and this could either fail or discard sensitive informations so you can change this behavior (ff v1.5 or 2.0 at least) by changing the following in about:config 

network.proxy.socks_remote_dns=true

Et apt-get install dante-client si on veut utiliser socksify pour permettre à des programmes ne connaissant pas les proxys socks de fonctionner malgré tout.

Utilisation d'autres services à travers un proxy requérant une identification (vieux!!)

Installez ce script dans par exemple /usr/local/bin/tunnel-auth.pl 

#! /usr/bin/perl
#
# tunnel-auth.pl
#
# Usage: tunnel-auth.pl ssl-proxy port destination_host port localport AuthToken
#
# This script can be used for any program to connect to any port via localhost
# It traverses a www-proxy/firewall that supports the http CONNECT
# command described in
# http://home.netscape.com/newsref/std/tunneling_ssl.html
# & http://muffin.doit.org/doc/rfc/tunneling_ssl.html
#
# The AuthToken: cf http://www.zvon.org/tmRFC/RFC2617/Output/chapter2.html
# "To receive authorization, the client sends the userid and password, separated by a
# single colon (":") character, within a base64 encoded string in the credentials"
# Ex:  echo -n "user:password" |base64-encode -> dXNlcjpwYXNzd29yZA==
#
# Example, connect to host named "remote" outside of your firewall:
# $ tunnel-auth.pl www-proxy 80 remote dXNlcjpwYXNzd29yZA=='
# Then use localhost:2222 to connect remote:22!
#
# Comment all PRINT STDOUT if you don't want a dump.
#
# Written by Urban Kaveus <urban@statt.ericsson.se>
# Posted by Urban Kaveus to newsgroup comp.security.ssh on 23 Jan 1997.
# Addition of base64 Authentication by Doegox <phil@teuwen.org>
# Addition of local server for other services than SSH by Doegox <phil@teuwen.org>

#require 'sys/socket.ph';
use Socket;
# Parse command line arguments

if ( $#ARGV != 5 ) {
    print STDERR "Usage: $0 ssl-proxy port destination port localport AuthToken\n";
    exit(1);
}

$sslproxy    = shift;
$proxyport   = shift;
$destination = shift;
$destport    = shift;
$localport   = shift;
$authtoken   = shift;

print STDOUT "\nProxy: $sslproxy:$proxyport\nDest:  $destination:$destport\nLocalPort: $localport\n";

# Makes STDOUT "hot" so always flushed:
select((select(STDOUT), $|=1)[0]);

# Set up network communication

($protocol) = (getprotobyname("tcp"))[2];
($proxyip)  = (gethostbyname($sslproxy))[4];
$localaddr  = pack('S n a4 x8', &AF_INET, 0, "\0\0\0\0");
$proxyaddr  = pack('S n a4 x8', &AF_INET, $proxyport, $proxyip);

# Set up client socket
socket(Server, PF_INET, SOCK_STREAM, $protocol) or
    die("Failed to create socket for client connexion");
setsockopt(Server, SOL_SOCKET, SO_REUSEADDR, pack("l", 1)) || die "setsockopt: $!";
bind(Server, sockaddr_in($localport, INADDR_ANY)) or
    die("Failed to bind socket for client connexion");
listen(Server,SOMAXCONN) or
    die("Failed to listen for client connexion");
my $paddr;
$SIG{CHLD} = \&REAPER;
$paddr = accept(Client,Server);
my($localport,$iaddr) = sockaddr_in($paddr);
my $name = gethostbyaddr($iaddr,AF_INET);
# Force flushing of socket buffers
select (Client); $| = 1;
print STDOUT "Client connected to $name\n";

# Set up proxy connexion
socket (PROXY, &AF_INET, &SOCK_STREAM, $protocol) or
    die("Failed to create socket for proxy connexion");
bind (PROXY, $localaddr) or
    die("Failed to bind socket for proxy connexion");
connect (PROXY, $proxyaddr) or
    die("Failed to connect to $sslproxy port $proxyport");

# Force flushing of socket buffers
select (PROXY);  $| = 1;

# Send a "CONNECT" command to proxy:

print PROXY "CONNECT $destination:$destport HTTP/1.0\r\nProxy-Authorization: Basic  $authtoken\r\n\r\n";

# Wait for HTTP status code, bail out if you don't get back a 2xx code.

$_ = <PROXY>;
print STDOUT "Server connected to $destination:$destport\n";
print STDOUT "Reply of server:$_";

($status) = (split())[1];

die("Received a bad status code \"$status\" from proxy server")
    if ( int($status/100) != 2 );

# Skip through remaining part of MIME header

while(<PROXY>) {
    chomp;   # Strip <LF>
    last if /^[\r]*$/;		# Empty line or a single <CR> left
}

# Start copying packets in both directions.

if($child = fork) { # Parent process
    while (sysread(PROXY,$_,4096)) {
		print STDOUT "\n\n#<-#$_";
        print Client;
    }
    sleep 2;
    kill(15,$child) if $child;
}

else { # Child process
    while (sysread(Client,$_,4096)) {
    	print STDOUT "\n\n#->#$_";
		print PROXY;
    }
}

Pour l'utiliser par exemple pour Jabber: 

/usr/local/bin/tunnel-auth.pl <nom du proxy> <port du proxy> 212.68.212.217 <string d'identification>

Le client peut alors se connecter sur 127.0.0.1:5222
Par défaut, un dump de la communication apparaîtra dans la console.
Si cela est dérangeant, par exemple si la communication se fait en SSL, rediriger la sortie. 

/usr/local/bin/tunnel-auth.pl <nom du proxy> <port du proxy> 212.68.212.217 <string d'identification> >/dev/null

L'adresse de destination doit sans doutes être chiffrée (IP) plutôt que textuelle (Nom de domaine)
Si cela est gênant par ex pour le cas d'un serveur jabber, ajouter la correspondance dans /etc/hosts (ou C:\WINNT\system32\drivers\etc\hosts): 

127.0.0.1 jabber.reseaucitoyen.be

et utiliser le nom de domaine réel dans le client plutôt que 127.0.0.1

Autre solution pour utiliser d'autres services que SSH:
On peut bien entendu se contenter des premiers scripts pour SSH et utiliser SSH pour créer un tunnel vers une machine à l'extérieur: 

ssh -L5222:jabber.reseaucitoyen.be:5222 -N user@hal

Où hal a été configuré dans le ~/.ssh/config, cf plus haut

Robustesse

Il se peut que la communication soit cassée par le proxy de temps à autres
Pour la rendre robuste, on peut utiliser par exemple la commande suivante: 

sh -c "while true; do date; ssh <host>; sleep 30; done"

Conjointement à l'utilisation de l'option "ServerAliveInterval 10" dans config cela garantit de redémarrer le tunnel endéans la minute (ServerAliveInterval*ServerAliveCountMax(=3)+sleep).
Enfin pour générer du traffic ce qui tend à garder la connexion ouverte par le proxy: pour une communication ssh avec terminal, voir le paquet spinner et pour une communication ssh uniquement avec déport de port et sans shell on peut créer qqch comme: 

 #!/bin/bash
 
 ANSI_XY_SAVE="\033[s"
 ANSI_XY_RESTORE="\033[u"
 STAR='-\|/'
 echo -n "Dummy login "
 for ((k=0;k<5;k=(k+1)%4));do
     echo -e -n "${ANSI_XY_SAVE}${STAR:$k:1} ${ANSI_XY_RESTORE}"
     sleep 5
 done

à sauver dans /usr/local/bin/star.sh et l'activer: 

chsh -s /usr/local/bin/star.sh <user>

Next step: Through real SSL Proxies

Nowadays the proxies are a bit smarter and don't let you CONNECT to ports, even port 443, if you're not talking SSL.
So for those proxies you have to talk

  • only on port 443, other ports fail
  • or SSL only, SSH or other protocols fail
  • or both: only SSL only on port 443

Talking SSL but not on the right port

Example: jabber server on port 5223, XML over SSL
That's easy providing that you can use port 443 on another server.
You can simply bounce the packets between the clients and the jabber server with some iptables on your server with a free port 443: 

IPTABLES -t nat -A PREROUTING -i eth0 -d my.free.ip -p tcp --dport 443 -j DNAT --to-destination jabber.server.ip:5223
IPTABLES -A FORWARD -d jabber.server.ip -p tcp --dport 5223 -j ACCEPT
IPTABLES -A FORWARD -s jabber.server.ip -p tcp --sport 5223 -j ACCEPT
IPTABLES -t nat -A POSTROUTING -o eth0 -d jabber.server.ip -p tcp --dport 5223 -j SNAT --to-source my.free.ip

So now the connection appears to be really SSL on the port 443.

Example is my jabber bouncer: jabber-rc.yobi.be port 443 => jabber.reseaucitoyen.be port 5223
You can try with e.g. Psi which is capable of connecting through a proxy and to another server/port than the real one.

Not talking SSL

Server side: simple SSL wrapper

You can use SSL wrappers to encapsulate the traffic in sth that looks like a real SSL connection (and it is).
Look at stunnel, stunnel4 or crywrap

Or use simply socat: 

socat OPENSSL-LISTEN:443 TCP4:127.0.0.1:22

More secure and flexible way: 

socat -d -d -lmlocal2 OPENSSL-LISTEN:443,bind=myip,su=nobody,fork,reuseaddr TCP4:127.0.0.1:22

Client side: simple SSL wrapper

 Port 443
 Proxycommand socat - OPENSSL:%h:%p,verify=0

Or using the script above: 

 Port 443
 ProxyCommand  /usr/local/bin/ssh-tunnel.pl - 0 %h %p -e --noproxy

Server side: using Apache2

Now you don't have tons of IPs and you want already to run your Apache on port 443, so what?

Here is an interesting script which serves as HTTPS server, GET and POST are served by reverse proxy, the script contacts the local Apache, and CONNECT can be used to connect to e.g. the SSH server you desesperately wanted to reach. 

Client -> BigBrotherProxy -> 443:Script -> Apache or SSH!

And if an admin wants to check that IP you're connecting to in SSL, he will get... an SSL Apache ;-)
Of course your client has to be smart enough to be able to do a CONNECT / SSL / CONNECT string before letting e.g. SSH talking to its server.

Ok ok but why not using directly Apache with sth like that? 

<VirtualHost 85.234.207.99:443>
  ...
  SSLEngine on
  ...
  ProxyRequests on 
  AllowCONNECT 22
  <Proxy *>  
     Some ACLs, we don't want to be universal proxy!
  </Proxy> 
</VirtualHost>

That would be wonderful but it appears that Apache, as soon as you do a CONNECT, becomes crystal and everything goes through it untouched, so the SSH server gets SSL-encrypted jam and its reply goes untouched to you while you were expecting SSL!
Slight difference between Apache 1.3 and Apache 2 is that the first one sends you its "HTTP/1.0 200 Connection established" still in SSL while the second already drops SSL before sending the msg in clear.
But anyway it's simply unusable in this stage.

Visibly other people were looking to the same direction and this bugreport, actually a feature request with a patch, seems to bring exactly what we want!

The patch applied smoothly to the current Debian Etch version (2.2.3-3.2) 

apt-get build-dep apache2
apt-get install fakeroot
apt-get source apache2
apply the patch...
dpkg-buildpackage -uc -us -rfakeroot
coffee...

And now the fresh apache2.2-common_2.2.3-3.2_amd64.deb contains our patched /usr/lib/apache2/modules/mod_proxy_connect.so

To avoid problems at further upgrades, I move the new module to a new name: 

mod_proxy_connect.so -> /usr/lib/apache2/modules/mod_proxy_connect_ssl.so

And create the corresponding config files: 

/etc/apache2/mods-available/proxy_connect_ssl.load:
LoadModule proxy_connect_module /usr/lib/apache2/modules/mod_proxy_connect_ssl.so

And /etc/apache2/mods-enabled/proxy_connect_ssl.load pointing to the previous one as usual.
Don't forget to enable also the main proxy module.

Client side: using socat

First test: 

socat - OPENSSL:my.server:443,verify=0
CONNECT another.server:22 HTTP/1.0

HTTP/1.0 200 Connection Established
Proxy-agent: blabla

SSH-2.0-OpenSSH_4.3p2 Debian-8

hehe :-)

socat cannot cumulate proxy and ssl, but we can cascade stuffs: 

socat TCP4-LISTEN:1234 OPENSSL:my.server:443,verify=0 &
socat TCP4-LISTEN:4321 PROXY:127.0.0.1:another.server:22,proxyport=1234 &
ssh -p 4321 127.0.0.1
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA key fingerprint is ff:cb:6d:f1:b8:a8:96:fe:08:1b:53:0f:dc:0f:6c:73.
Are you sure you want to continue connecting (yes/no)?
YESSS :-)

Server side: using Apache2 with authentication

Next step: proxy authentication 

<VirtualHost *:443>
  ...
  SSLEngine on
  ...
  ProxyRequests on
  AllowCONNECT 22
  <Proxy *>
     Order deny,allow
     Allow from all
     AuthType Basic
     AuthName "Password Required"
     AuthUserFile /path/to/htpasswd
     Require valid-user
  </Proxy> 
</VirtualHost>

By default AllowCONNECT only accepts 443 and 563 so you probably want to extend it to 22 and the other services you want to reach (VPN?)

Client side: using socat

Example: 

socat TCP4-LISTEN:2222,bind=127.0.0.1 OPENSSL:my.server:443,verify=0 &
socat TCP4-LISTEN:1111,bind=127.0.0.1 PROXY:127.0.0.1:another.server:22,proxyport=2222,proxyauth=user:pass &
ssh -p 1111 127.0.0.1

And as the goal is to go through an enterprise proxy, it becomes sth similar to: 

socat TCP4-LISTEN:3333,bind=127.0.0.1 PROXY:big.brother.proxy:my.server:443,proxyport=8080 &
socat TCP4-LISTEN:2222,bind=127.0.0.1 OPENSSL:127.0.0.1:3333,verify=0 &
socat TCP4-LISTEN:1111,bind=127.0.0.1 PROXY:127.0.0.1:another.server:22,proxyport=2222,proxyauth=user:pass &
ssh -p 1111 127.0.0.1

Using ProxyCommand, the last call to socat and ssh can be combined: 

Host test
 Hostname another.server
 Proxycommand socat - PROXY:127.0.0.1:%h:%p,proxyport=2222,proxyauth=user:pass

That's just for a 3 lines test, but now we know we can extend our initial script described at the beginning of this page.

A nice enhancement of socat would be to allow chaining and to allow among others PROXY and OPENSSL to use local file descriptors, e.g. allocated on-the-fly so at the end we could use one single command such as: 

socat TCP4-LISTEN:1111,bind=127.0.0.1 PROXY::another.server:22,proxyauth=user:pass OPENSSL::,verify=0 PROXY:big.brother.proxy:my.server:443,proxyport=8080 &

Or using ssh ProxyCommand: 

ProxyCommand  socat - PROXY::%h:%p,proxyauth=user:pass OPENSSL::,verify=0 PROXY:big.brother.proxy:my.server:443,proxyport=8080

Or using a nested notation: 

ProxyCommand  socat - PROXY:(OPENSSL:(PROXY:big.brother.proxy:my.server:443,proxyport=8080):,verify=0):%h:%p,proxyauth=user:pass

Version 1.5.0.0 says the lexical analysis tries to handle quotes and parenthesis meaningfully and allows escaping of special characters. If one of the characters ( { [ ' is found, the corresponding closing character - ) } ] ' - is looked for; they may also be nested
but also in the BUGS section
Addresses cannot be nested, so a single socat process cannot, e.g., drive ssl over socks. but maybe in a future version...
[Update] According to the developer I am very aware of the lack of this feature - yes, the bug mentioned in the docu refers to exactly your need. I have already considered and partially implemented different approaches for his, but none got ever near to release. But I still intend to realize this feature, because it would enable astonishing possibilities! Expect it to appear in a few years though... so maybe one day... :-)
[Update] version beta 2.0 supports it \o/ 

ProxyCommand socat - 'PROXY:%h:%p,proxyauth=user:pass|SSL,verify=0|PROXY:my.server:443,proxyauth=user:pass|TCP:big.brother.proxy:8080'

Client side: using the perl script

What socat cannot do, our script can! 

ProxyCommand  /usr/local/bin/ssh-tunnel.pl - 0 %h %p -e -R my.server:443 -U <user> -P <password> --noproxy

Make your own SOCKS5

Example: download geo-locked content.

youtube-dl

apt-get install youtube-dl

or 

wget https://yt-dl.org/latest/youtube-dl
chmod +x youtube-dl

SOCKS5

Just ssh to a box in the right area and enable SOCKS5 proxy: 

ssh -D 12345 remote_host

Get proxychains 

apt-get install proxychains

Edit /etc/proxychains.conf 

dynamic_chain
quiet_mode
tcp_read_time_out 15000
tcp_connect_time_out 8000
[ProxyList]
socks5 127.0.0.1 12345

It's also possible to redirect DNS through proxy ("proxy_dns") but if you don't need it, it will work smoother without.

Use it, e.g.: 

proxychains youtube-dl "Some geo-locked video web page"
Retrieved from "https://wiki.yobi.be/index.php?title=Bypass_Proxy&oldid=9470"