[hobbit] Feature request: SSL/TLS client/server negotiation

[Henrik Stoerner]

On Fri, Oct 13, 2006 at 10:40:42AM -0400, Jerry Yu wrote:

> 2. If you have a server (Hobbit's typical client) compromised, you have
> serious problem. DoS to the Hobbit server is much lesser a concern,  since
> it can be done as long as the target has public service (or is reachable
> over the net).  Potential compromise of the Hobbit server by a rogue client
> is more of an issue here.
> So, question to Henrik,  how well Hobbit server protects itself  from a
> misbehaving client ( bad-code, or malicious) with the bbd listening to
> client traffic via TCP/1984 and parsing (potentially malformed/malicious)
> data from the client. Any security audit has been done?

The only "authentication" that Hobbit has is that you can limit - by
IP-address - who is allowed to send status updates and administrative
requests (the --status-senders, --maint-senders, --www-senders and 
--admin-senders options to hobbitd). All except --admin-senders are
not enabled by default (admin requests are only allowed from the
local host where Hobbit is installed). The --status-senders option does
add some security against compromised clients (they can only affect the
status reports for the compromised host itself, not others).

There hasn't been any real audit done. I wouldn't mind if someone did a code 
review of the hobbit daemon - but I cannot do it, since I wrote it. It must 
be someone who looks at the code with fresh eyes.

hobbitd does try to protect itself from malicious traffic - checking
that the messages adhere the proper syntax for messages, dropping
connections that attempts to do data flooding. But there has to be some
bugs in that code; whether they can be found and exploited I probably
won't know until someone does. There have been a couple of security-
related bugs that got fixed during the 4.2 beta period.

I've tried to write code that is fairly robust against attacks. But
I have assumed that Hobbit is located on a fairly "friendly" network.
I would not recommend that you make port 1984 publicly available on
the Internet; at the very least, do some sort of firewalling to protect
your server from anonymous attacks.


Regards,
Henrik