[erlang-questions] Adding StartTLS support to eldap (for use Ejabberd)

Gavin Henry <>
Tue Aug 7 21:27:54 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.
> Good thinking!
>> 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.

Yeah, true. But many systems don't enable port 686.

>> 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.

Yep, but they should know this one :-)

>> > 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.

Yeah, that's kind of a deal breaker then.

> 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.

I'm beginning to see this now.

>> >> 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
>> auth.
> 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!

Of course :-)

Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887

Open Source. Open Solutions(tm).


Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie,
Aberdeenshire, AB51 8GL.

Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

Do you know we have our own VoIP provider called SureVoIP? See

Did you see our API? http://www.surevoip.co.uk/api

More information about the erlang-questions mailing list