On Tue, Feb 26, 2013 at 1:16 AM, <fwm@nym.hush.com> wrote:

>Sounds like the best way to do this is to write a module plugin
>system that takes a pre-defined plugin format. People could then
>contribute plugins that would allow fwknop to send packets that
>resemble anything (HTTP, DNS, ICMP, etc).
>
>This does make the job of the server-side parser a bit trickier
>however, and we want to keep complexity of that part to a minimum,
>lest vulnerabilities get introduced.

Agreed on keeping the server side implementation as simplistic as possible.  For this particular feature (SPA over HTTP, DNS, or other application protocol), one strategy might be to only compile in this code if enabled via a set of command line arguments to the autoconf configure script (--enable-spa-http, --enable-spa-dns, etc.).  That way, most users aren't any worse off since any potentially vulnerable code would not even be compiled into the fwknopd binary by default, and at the same time users that really want this feature have a way to enable it.  There are some similar things coming such as the ability to link against OpenSSL directly for encryption/decryption operations, but this would also not be enabled by default.  It would just provide a way for users that trust OpenSSL more than the alternative open source Rijndael + digest algorithm code that fwknop uses to have an alternative.  This is certainly a trade off though since OpenSSL has a lot more code doing a lot more things that fwknop will ever need, so it's certainly not clear that linking against OpenSSL would provide any security benefit. 

While we're on the OpenSSL topic for a bit - one thing that the next fwknop release will do is provide a way for the test suite to verify that SPA packets encrypted with libfko can be decrypted via OpenSSL and vice versa.  This provides a way for fwknop to ensure that the crypto operations are compatible with OpenSSL without linking against it directly.  This essentially means that fwknop can use the OpenSSL community as a provider of security research.  I.e., if a vulnerability is found in OpenSSL that causes them to change their implementation of Rijndael or anything else that fwknop depends on, then fwknop will be able to track this automatically through the test suite.  Most of this code is already finished in the hmac_support branch:

https://github.com/mrash/fwknop/commit/1d35c33d5214345118836146713b8c6fff8d211d
 
>// Seb
On unencrypted protocols the parsing would be simplified though, as
we would only be interested the fwknop digest, and not as much of
the information that is normally read into variables from the
packet.


I think the libfko routines would largely be the same, but there would need to some additional code to get to the SPA payload data within all supported applications (HTTP, DNS, etc.).  It turns out that the client can already send SPA packets over HTTP requests:

https://github.com/mrash/fwknop/blob/hmac_support/client/spa_comm.c#L507

But, this functionality is not yet tested through the test suite (will be included before the fwknop-2.5 release):

$ git grep send_spa_packet_http test/test-coverage/
test/test-coverage/iptables/zero_called_functions:../client/spa_comm.c.gcov:function send_spa_packet_http called 0 returned 0% blocks executed 0%

Thanks,

--Mike

 
--
ozmart


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Fwknop-discuss mailing list
Fwknop-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss



--
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F