[Date Prev][Date Next]
Re: Forcing TLS encryption
On Dec 28, 2012, at 12:56 PM, Wiebe Cazemier <firstname.lastname@example.org> wrote:
> ----- Original Message -----
>> From: "Philip Guenther" <email@example.com>
>> To: "Wiebe Cazemier" <firstname.lastname@example.org>
>> Cc: "Dieter Klünter" <email@example.com>, firstname.lastname@example.org
>> Sent: Friday, 28 December, 2012 9:36:50 PM
>> Subject: Re: Forcing TLS encryption
>> On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
>>> I understand that, but this way, even when you're forcing TLS,
>>> users can
>>> still expose their passwords if their computers are mal-configured.
>>> SMTP, IMAP, FTP, etc don't allow this, because they reject the
>>> connection if LOGINNAME is given before STARTTLS.
>> That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or
>> IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both
>> the username and password without waiting for a response from the
>>> It's kind of a security issue. Is it because in LDAP, username and
>>> password are given as one command, and the server doesn't have the
>>> chance to abort at that point? If so, then I guess it's
>> Philip Guenther
>> ** Well, to be completely accurate, IMAP AUTHENTICATE requires a
>> response if the server doesn't support the SASL-IR capability
> Then why is the LDAPS port deprecated? If the connection is SSL from the start, you don't have this issue.
You still have the issue that the client might be configured for ldap://host:636 and Simple Bind or SASL PLAIN (generally by user mis-configuration).
In short, nothing in the server can prevent a poorly coded or poorly configured client from disclosing a user password in appropriately.
ldaps:// was never standardized and hence deprecated. There were many reasons why the IETF choose not to standardize ldaps://, one being interoperability issues between pre-existing implementations... another being that it viewed as not needed.