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

[Gavin Henry]

> On Mon, Aug 06, 2012 at 05:14:48PM +0100, Gavin Henry wrote:
>> Hi Rory (sorry for top posting. My mail client sucks),
>
> Ha, it's been so long since I replied to anything on a list that
> I'd forgot the rules!

This list is tame, as on others we'd both have been nailed!

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

>> That's what I thought. I'm not sure why though or whether it can be
>> pulled out again.
>
> Well, it looks like the current release of ejabberd is supported
> running on Erlang/OTP versions from R10B9 to R15B, and eldap was
> only added to the R15B01 release. Also, it looks like the 3.0.0
> alpha and beta versions of ejabberd are being supported on
> Erlang/OTP R12B5 and above, so they won't be dropping their own
> eldap implementation any time soon.

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

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.

RFC 4513 is what needs to be read for this work and it's sponsorship, which
also covers the SASL side 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 :-)

> There might be another problem with adding this functionality to
> the ejabberd eldap. I'm not 100% sure about this, but I think
> that the ssl application that was used in Erlang before R14B (the
> old default ssl application), did not have the ability to start
> running SSL over an already established TCP connection. I think
> this was actually one of the main reasons for the big rewrite of
> the ssl application in recent years. Basically what this means is
> that it will not be possible (or just wise) to use STARTTLS when
> using versions of Erlang/OTP before R14B. Any patch to the ejabberd
> eldap would need to offer this functionality only when a suitable
> version of Erlang was running.

Understood. I'm not up to date on the history.

> However, the main downside to patching the OTP version - assuming
> it even gets accepted - is that you will only have the STARTTLS
> functionality if you are running ejabberd on top of some future
> version of Erlang (or a patched R15B01+ version). Would this suit
> you?

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.

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

Thanks,

Gavin.

-- 
Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry@REDACTED

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

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
http://www.surevoip.co.uk

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