[sslh] plug in =)

[Régis A. Despres]

On Fri, Feb 24, 2012 at 4:27 PM, Yves Rutschle <yves at naryves.com> wrote:
> On Fri, Feb 24, 2012 at 03:33:15PM +0100, Régis A. Despres wrote:
>> Before I deep more in the code, would it be easy to include a
>> configuration file listing the protocols & their trigger.
>
> I see two ways to do it:
>
> - linked libraries. I don't really want to go that way, that'd be complicated,
> heavy and not very useful
>
> - configuring something similar to regular expressions tested on the first
> packet:
>
> ssh: ^SSH-
> tinc: ^0
> openvpn: \x00[\x0D-\xFF]
>
> That could be done, but I'm worried we'll hit protocols that can't easily fit
> in a regular expression. The OpenVPN probe is already borderline as it should
> depend on the length of the packet.
>
> Or did you have something else in mind?
>
> However:
>
>> The main goal of this : easing tests in order to add more protocols.
>
> This really is very easy. You only need to edit common.c,
> add an entry to the protocols[] array which defines the
> command line option name and the probe function to call,
> then add a function that'll get the the first packet as
> parameter.
>
> So if I want to add support for the foobar protocol, I add:
>
> [... in protocols[]]
>    { 0,         "foobar",        NULL,   {0}, is_foobar_protocol },
> [...]
> int is_foobar_protocol(const char *p, int len)
> {
>    if (!strncmp(p, "foobar:", 7)) {
>        return 1;
>    }
>    return 0;
> }
>
> (foobar packets contain the string 'foobar:', apparently).
>
> then make and run:
>
> make && ./sslh -v -f -p hostname:443 --ssh localhost:22 --foobar localhost:31415 --ssl localhost:443
>
> Hence I'm not sure moving to an external file would be better: we'd lose the
> flexibility of being able to do anything C can do, and not gain all that much
> in terms of ease of development.
>
> Y.

In a first place, thanks regarding the way to test described above.
It might be a good idea to place it somewhere the Home page and/or the README.

Secondly, i had in mind something similar to the "regular expression
thing" you mentionned.
But as for testing purpose it might be something optionnal called by
getopt (-f testing_file)

Afterwhat, looking a bit ahead and regarding the limitation you
mentionned, perhaps it would be possible to define some main trigger
(i.e. size, content, ...) and organize them as something like :

    - openvn : "size_length_operation&&string_content_operation"
or
    - openvpn: "size..||content.."
or
    - openvpn: "(size...&&content...)&&(size||content)"


Regards,


--
Regis A. Despres