[sslh] libevent port?

[ondra+sslh at mistotebe.net]

[Reposting reply to list, sorry for the noise]

On Mon, Sep 16, 2013 at 07:54:13AM +0200, Yves Rutschle wrote:
> Hi Ondra,
> 
> > So I went ahead and built a proof of concept implementation, [...]
> 
> Okay, that was too fast for me to reply to original e-mail :-)
> 
> No objections to your code, I just need some time to get
> into the libevent API to be able to review your code
> properly.
> 
> > I've recently started using sslh in my network and have been wondering
> > whether you'd be interested in me porting sslh to libevent. I've been
> > building a libevent based reverse proxy (mistotebe/skeeter on github)
> > and adapting it to sslh should be quite easy.
> 
> My biggest question is really whether libevent is the best
> way to go. I remember considereing it years ago (probably
> before starting sslh-select) and discarding the idea, but I
> don't remember why. Maybe it didn't work on Windows at the
> time, which was the primary goal of sslh-select.

Given that sslh's design is very simple, it can certainly make the code
cleaner and easier to read as there's fewer places that need to handle
all the complexity arising from having to properly handle the nuances of
select/read/write syscalls.

As for Windows, I do not have a way to test, but allegedly, bufferevents
can leverage the IOCP mechanisms as well.

> A quick research shows up at least two other competitors to
> libevent: libev and libuv, and both seem to say they're
> "better" (well, of course). It's not clear to me what are
> the pros and cons of all these.

Although I'm aware of them, the only one that I'm familiar with is
libevent having built a moderate amount of code on top of it. In terms
of API, libev provides a simple interface only, adding nothing else,
libuv seems to provide a comprehensive network/thread/filesystem event
building blocks and libevent is mostly network oriented with a few tools
like self draining buffers built on top of it.

> Then again, the volume of code for libevent seems to be less
> than I expected, so maybe going market research for these
> libraries is useless.
> 
> > This would allow some nifty features as well, like forking
> > only for ssh (for which the SSHd usually forks anyway so
> > the overhead would not be that high) and keeping the
> > others in process.
> 
> That's an interesting feature request independantly from any
> event library, actually.

I haven't really considered what changes need to be done to sslh-select
to support this.

> > Do you maintain a TODO list for sslh anywhere? If you do, here are a few
> > ponies I've collected since starting to use it:
> > - harden the probes to work with arbitrary ingres data (some probes
> >   use strstr and similar)
> 
> I'm confused: the string library functions are all used
> against constant strings, which I believe introduces no
> security issue. What are you thinking about?

The incoming data might have embedded NULs or might not be
NUL-terminated at all. I believe some probes will only work by chance
then.

> > - make hostname resolution in logs optional (limiting sslh visibility
> >   and latency)
> 
> That's --numeric

Ah, I'll take a look at that.

> > - have certain services available only from specified subnets
> 
> What's the use case?

A poor man's approach to hidden services, exposing different services to
different people. For example allowing some people access to a tor relay
while having it appear as a regular web server to the rest of the
internet. Given that tor is meant to be indistinguishable from HTTPS,
this would be the only way to achieve that (another one would be to
extend SilentKnock, but the implementation cost would be way higher, and
there are still NATs that usually interfere with the packet
characteristics).

> > - have probes annotated with minimum amounts of data needed to make a
> >   decision and/or let them return "cannot decide yet"
> 
> Ah, that'd be cleaner than the current method.

OK, I'll rework this part next.