Use as SSL-adding proxy

[Rhialto]

I am trying to use sslsplit as a little proxy to ADD SSL/TLS encryption to a plain-text connection. From the description I got the impression that this is possible to do with sslsplit. (Of course sslsplit is way overkill, but all other "SSL proxy" like things I have been able to find are terminating SSL connections, instead of originating them).

I tried the following:

sslsplit -k key.pem -c cert.pem \
         -e none \
         tcp 127.0.0.1 10333 ssl 127.0.0.1 333

(for this use, one should not need a certificate, yet sslsplit insists on it) (if I leave out -e none I get Connection not found in NAT state table, aborting connection when I make a connection, but I don't want to do anything with NAT)

Now when I telnet to port 10333, I get

SNI mode used for non-SSL connection; aborting connection

I'm not sure where it gets the idea from that it should use SNI. -D doesn't add any extra output to that, apart from the initialisation stuff before accepting the first connection.

My example looks like a variant on an example in the manpage:

       sslsplit -k ca.key -c ca.crt -l connect.log -S /tmp \
                ssl ::1 10993  ssl 127.0.0.1 10993 \
                tcp ::1 10143  tcp 127.0.0.1 10143

so I was expecting it to work. This is either a bug, I'm requesting a new feature, or I'm doing something wrong. I'm not sure which at this point :-)

$ sslsplit -V
SSLsplit 0.5.5 (built 2019-12-29)
Copyright (c) 2009-2019, Daniel Roethlisberger <daniel@roe.ch>
https://www.roe.ch/SSLsplit
Build info: V:FILE HDIFF:0 N:83c4edf
Features: -DHAVE_IPFILTER -DHAVE_IPFW -DHAVE_PF -DWITHOUT_MIRROR
NAT engines: pf* ipfw ipfilter
ipfilter: version 5010200
Local process info support: no
compiled against OpenSSL 1.0.2k  26 Jan 2017 (100020bf)
rtlinked against OpenSSL 1.0.2k  26 Jan 2017 (100020bf)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
OpenSSL has engine support
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: ssl3 tls10 tls11 tls12 
SSL/TLS algorithm availability: SHA0 RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.1.8-stable
rtlinked against libevent 2.1.8-stable
4 CPU cores detected

$ uname -a
NetBSD murthe.falu.nl 8.1 NetBSD 8.1 (GENERIC) #0: Fri May 31 08:43:59 UTC 2019  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

[sonertari]

SSLsplit does not support the setup you are trying to achieve, i.e. you cannot encrypt a plain TCP connection using sslsplit. Both the client and the server side of connections must use the same protocol.

Your command line creates two separete proxyspecs, one for TCP and another for SSL, that's all. And when you disable NAT engine using -e, sslsplit falls down to SNI mode to determine the target address, but gives a runtime error for the TCP connection, as expected.

Btw, if you need detailed debug logs you should recompile sslsplit by enabling appropriate DEBUG_* flags in GNUmakefile.

[Rhialto]

Ok thanks for the info. In the mean time somebody pointed me to socat, which looks promising for my purpose. I'm closing the issue.

[erik4711]

You can use PolarProxy to wrap any protocol in TLS. It's much more practical than socat.

You'll need to start PolarProxy with these arguments in order to run it as a TLS termination proxy: --terminate --connect 192.168.53.19 --nosni nosni.polarproxy.com

For more details, see this blog post: https://netresec.com/?b=19Ce12f

/erik

On Sun, Dec 29, 2019, 17:20 Rhialto The M. notifications@github.com wrote:

Ok thanks for the info. In the mean time somebody pointed me to socat, which looks promising for my purpose. I'm closing the issue.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/droe/sslsplit/issues/262?email_source=notifications&email_token=AFUPKKPXRBGJDPVK5FMYZVDQ3DE6DA5CNFSM4KA5TIK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHZC7RA#issuecomment-569520068, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFUPKKPRFFGEEKKRP2F6OPLQ3DE6DANCNFSM4KA5TIKQ .

[Rhialto]

@erik4711 Thanks, I looked at it but it seems like it does the reverse of what I want. I have a client (locally) that does not speak TLS (and I don't want to add code to it to teach it that, since that is tedious). I want the client to talk to some remote server that does support TLS (because the protocol involves authentication that is insecure otherwise). I am currently using

socat TCP-LISTEN:10333,fork OPENSSL:some.other.server:333

and telling my local client to connect to localhost:10333 instead of some.other.server:333. It seems to work well; I just need to clean up the running socat.

[erik4711]

@Rhialto Ah, sorry for the misunderstanding. Yes, PolarProxy does the reverse, i.e. it can be used to add TLS encryption to the server-side of the connection. In your situation socat is the way to go.