[sslh] sslh on RedHat

[Yves Rutschle]

Hi Michael,

On Thu, Jan 03, 2013 at 09:23:25AM +0100, Michael Lang wrote:
[...]
> with this modification it would be possible to do something like
> $ make install DESTDIR=/tmp/buildroot

Ok, I can do that.

> protocols:
> (
>      { name: "ssh"; service: "ssh"; host: "localhost"; port: "22";
> probe: "builtin"; },
>      { name: "tinc"; service: "tinc"; host: "localhost"; port:
> "655"; probe: "builtin"; },
>      { name: "openvpn"; host: "localhost"; port: "1194"; probe:
> "builtin"; },
>      { name: "http"; host: "localhost"; port: "80"; probe: "builtin"; },
>      { name: "ssl"; host: "localhost"; port: "443"; probe: "builtin"; }
> );
> 
> would always end at localhost:443 if connecting with openvpn and or tinc

I just tried this exact configuration and can connect with
openvpn, ssh, http, and ssl... I don't have tinc.

So we have some sort of issue here. Do ssh and http work at
all?

> i've seen your probe settings in the example.cfg but I'm missing an
> explanation how to be able to see what I should be matching there...
> do you know what I mean ? I can understand that for example jabber
> will be in the plain-text protocol of xmpp but what matches can be
> done against encrypted packages ? and what to look at those packages
> ? (maybe you could explain how you figured out the openvpn regex ?)

Ok, basically for each protocol the configuration file lists
a list of regular expressions which sslh will try to match
on the first packet it receives from the connection. If any
of those patterns match, it'll connect to that protocol.

The openvpn probe is a regex translation of the C code in
openvpn's source code to test if an incoming connection is
openvpn or not (function "is_openvpn_protocol" in ps.c).
(Incidentally this is no longer the code we use in the
builting openvpn probe, as it turned out that that code
doesn't work with pre-shared secrets).

I see three ways to go about writing new probes, in
decreasing order of preference:
- Reading the protocol documentation and work out what the
  packets should look like
- Read the source code (preferably server-side, I guess) and
  work out what it's expecting
- Look at an incoming connection with tcpdump and work out
  what to test on

Now if the packet is encrypted... well, we're limited here.
E.g. with OpenVPN and SSL we're fine because OpenVPN doesn't
actually use SSL and the beginning of the connection looks
different. 

Now if you were to try and match HTTPS (HTTP over
SSL) and SMTPS (SMTP over SSL), then I am afraid you've
reached the limit of what sslh can do. You can still,
however, put an SSL proxy (e.g. stunnel) to handle these
connections, decrypt them, and then use sslh to forward them
to the right place.

HTH,
Y.