[Server-devel] question on SSL enabling ejabberd
Martin Langhoff
martin.langhoff at gmail.com
Tue Nov 25 15:55:32 EST 2008
On Tue, Nov 25, 2008 at 6:17 PM, Patrick Giagnocavo <patrick at zill.net> wrote:
> Has anyone compared, or looked at, the performance of ejabberd with its
> builtin SSL/TLS support, versus using the "stunnel" program to run on
> the port, acting as an SSL-encrypting proxy?
Not really. However, the reason we use SSL/TLS is that the XMPP
protocol conflates compression and encryption together. That is: to
get compression, you need to negotiate with the server to use SSL/TLS
and pass 'compress' as one of the options.
So if the server is convinced it's not using encryption, it won't use
compression. Of course, an additional daemon could help with
compression too, but it's a lot of complication on the _client_ side,
as well as on the server side.
Luckily, the memory costs of SSL are getting fixed, and the last round
of testing by Douglas shows that it's the shared roster that is
costing us RAM right now.
> If no one has done this, I would offer to test it out, as I have
> configured stunnel before (for a different situation).
I'll keep stunnel in mind (and the good news that we have an expert
around :-) ). It doesn't seem to be the easiest path at the moment
(unless it can be done without changes on the client side...). On the
other hand, I could be missing something, don't let me discourage you
from trying if you want -- the key thing to check is that a vanilla XO
client can connect to ejabberd via an stunnel process running on the
server, with compression on, and that the thing takes less memory than
using the ejabberd ssl logic.
What do you think?
martin
--
martin.langhoff at gmail.com
martin at laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
More information about the Server-devel
mailing list