[sslh] plug in =)

[Regis A. Despres]

Sounds good to me =]



--
Regis A. Despres

Le 25 févr. 2012 à 15:44, Yves Rutschle <yves at naryves.com> a écrit :

> On Fri, Feb 24, 2012 at 06:02:34PM +0100, Régis A. Despres wrote:
>> 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.
> 
> I thought about it as I was writing it :)
> 
>> 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)
> 
> Ok, having an additional optional external file on top of
> the hard-coded C probes sounds like a good solution. I'll
> add that soon then.
> 
>> 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 : [...]
> 
> Yes, but I'm just not sure how useful that would be with
> regards to the amount of work to make it work. I think I'll
> just use regular expressions for the time being, and we'll
> extend it somehow if we really need specific tests that
> can't be done with regexps.
> 
> For example a much simpler way would be to allow several
> patterns that would be matched in turn until one worked:
> 
> openvpn: ^\x00[\x0D-\xFF]$
> openvpn: ^\x00[\x0D-\xFF]\x38
> 
> "if the buffer is 2 characters long, and it matches, it's
> openvpn. if it's 3 or longer, and it matches the second
> rule, it's openvpn"
> 
> In that case sslh would just match the first packet of a
> connection against each pattern in the file until one
> protocol matched, if they all fail it moves to the
> hard-coded rules (that way it's also possible to override
> internal probes without re-compiling).
> 
> Y.