[sslh] libevent port?

[Yves Rutschle]

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.

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.

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.

> 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?

> - make hostname resolution in logs optional (limiting sslh visibility
>   and latency)

That's --numeric

> - have certain services available only from specified subnets

What's the use case?

> - 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.

> What do you think, is this worth pursuing/would you accept an
> implementation if I provided one?

No worries.

> What about making sslh compilable as a skeeter loadable
> module (when/if skeeter grows loadable module support)?

I'm honestly not sure what skeeter does, so I'll refrain
from commenting at this point :)

Cheers,
Y.