[erlang-questions] Adding StartTLS support to eldap (for use Ejabberd)
Tue Aug 7 02:50:03 CEST 2012
On Mon, Aug 06, 2012 at 09:24:53PM +0100, Gavin Henry wrote:
> > I've changed the subject of this email in the hope that someone
> > from the ejabberd community might offer some advice.
> Ha, naughty! I've created a new thread as it was going off a bit.
> Yes, unfortunately most people that develop LDAP libs forget StartTLS and
> just go for LDAP over SSL which isn't a standard and is deprecated. StartTLS
> is a standard - http://www.rfc-editor.org/rfc/rfc4513.txt
Well, adding support for LDAP over SSL is pretty simple and we all
know how lazy programmers are! :-)
Both methods have their merits and they're both going to be around
a long time, so supporting both makes lots of sense.
> Then again, the whole point of TLS and *getting it right* is to
> validate certificates
> which a lot of libs don't offer or admins don't bother with.
Actually, it looks like eldap is currently hard-coded not to verify
the server's certificate when using LDAP over SSL, so this would
need to be updated as well.
> RFC 4513 is what needs to be read for this work and it's sponsorship, which
> also covers the SASL side too.
And probably parts of RFC 4511 too.
> > However, they might accept a patch that uses the OTP version of
> > eldap when it's available. Ultimately it would be more beneficial
> > for everyone if the STARTTLS and SASL functionality were added to
> > the OTP version. Certainly if I was writing a patch, I'd much
> > rather it was for the OTP version.
> My company would not sponsor the Ejabberd version of eldap. What would
> be the point,
> that helps no one and would be a shortsighted piece of sponsorship on
> our part :-)
Actually, the more I look at the ejabberd eldap version, the more I
get the feeling that there is no chance that they will opt to use
the OTP version as it stands. One of the first things they did with
the eldap code was to rewrite it be asynchronous so it can have multiple
ongoing requests to the LDAP server at the same time. The OTP eldap,
on the other hand, is synchronous - it blocks on each request to
the server waiting for a response. Clearly in the context of a large
multi-user XMPP server, having asynchronous communication with your
directory server is something you'd want.
I suspect there's a few other useful changes that they've made that
they (or you) wouldn't be willing to give up.
> If the patch is done right then I'm sure it wouldn't be too difficult
> to add initial
> support to the ejabberd eldap version at the same time, with a caveat that
> no further support will be provided and the ejabberd team would need
> to either bring
> in OTP eldap or maintain it themselves.
I wish this were the case. Unfortunately the two sets of code are vastly
different - at least to my eyes. I can't see how a patch for OTP eldap
would be of any use against the ejabberd version. Basically, you should
consider them two unrelated projects, at a code level that's what they
are. That said, if you wrote a patch for one of them, you'd have a good
idea of what you're doing when writing a patch for the other one.
> >> In our situation we're not using cliebt certificate based TLS with
> >> SASL EXTERNAL. But it should be added at the same time rather than an
> >> incomplete patch.
> > Yeah, I reckon it's worth having.
> It would certainly add excellent support for enterprises using eldap.
> Some of our OpenLDAP
> support customers will *only* use SASL EXTERNAL with X.509 certificate based
Yeah, I can well imagine. If you're going to put the money and effort
into a PKI, you'd be mad not to use it!
More information about the erlang-questions