Connect to an SSL page through a Socat Proxy

So lets say you have a device, at a remote location, that has a SSL web page. You can only access it from the local subnet and you don't want to disrupt any users to kick them off their machine.... or you plan to bounce off a client there, maybe without their knowledge.

We will make the following conditions for this example:
You're in the 192.168.20.0/24 subnet.
You can access subnet 192.168.3.0/24
192.168.3.11 - device with an ssl page that is accessible ONLY from the 192.168.3.x/24 subnet 192.168.3.20 - device you have access to on that subnet
192.168.20.10 - your machine

We can use Socat to make the connection because it has the option for an openssl connection type.

Copy over Socat, and it's dependencies:
cygcrypto-0.9.8.dll
cygminires.dll
cygncurses-8.dll
cygreadline6.dll
cygssl-0.9.8.dll
cygwin1.dll
cygwrap-0.dll
to the 192.168.3.20 machine and issue the following command:

socat TCP-LISTEN:8100,fork OPENSSL:192.168.3.x:443,verify=0

This tells socat to start listening on 192.168.3.20 port 8100 (or whatever port is available), and fork incoming connections so it can handle multiple connections at a time.

*Fork is not really necessary for this example, probably better to leave it out, but if you need multiple connections to the device you need the fork option.

Then send that traffic over an openssl connection to 192.168.3.11 port 443 and NOT to verify the ssl cert for the page you're trying to connect to (verify=0).

*You can change it to verify the ssl cert (verify=1) but if the certificate is not correct, ie self signed, or intended to be used on a public site and you're accessing it internally, etc. the connection will not succeed.

Then on 192.168.20.10 open your browser and put in 192.168.3.20:8100. Viola you have access to your SSL site that requires a connection from the local subnet.

Now, before we go any further the connection between 192.168.20.10 and 192.168.3.20 is NOT encrypted, that means anyone sniffing the traffic will see everything that's sent between 192.168.20.10 and 192.168.3.20. That's bad. Especially since you're probably going to have to type in credentials to access the page, and if the sniffer misses that, then there's still the cookie that can be stolen as well.

Traffic between 192.168.3.20 and 192.168.3.11 IS encrypted, BUT since we have verify=0 it will accept a forged certificate. That's also bad. But if the device has an invalid cert to begin with there's nothing we can do about it.

You can secure your connection between 192.168.3.20 and 192.168.20.10 by generating ssl certificates Instructions can be found here but that requires access to a system with openssl or some other cert signing software and since you're likely to be dealing with windows machines that's unlikely to be handy, but it can be done. You would need to change TCP-LISTEN to OPENSSL-LISTEN also.