[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldaps://

> I've just read the FAQ part about ldap:// and ldaps:// and wanted to make
> sure I understood it correctly.

	This is a short opinion about StartTLS vs. pure TLS (like using
stunnel).

	I'm doing a new setup and this question has presented itself for
both LDAP and SMTP and IMAP -- force standard SSL on a high port, like
636, using stunnel, or offer standard services on the standard ports, and
configure the server applications such that "StartTLS" is required.

	Here's my argument AGAINST the "StartTLS" method, and FOR a forced
SSL connection on a high port (regardless of IANA revoking those high port
numbers for SSL connections).  I'll use SMTP as the posterchild example.
This assumes the server is on a public network (which is usually the
impetus for messing with SSL in the first place).

	There are many Bad Guys who will scan my port 25, looking to see
what version of software I'm using (for the purpose of exploiting known
bugs/buffer overflows), as well as server misconfiguration (i.e., is this
an open relay that we can spam from).

	Every time one of these Bad Guys probes me, then with the StartTLS
option, the server has to accept the connection, wait for the (necessary
by config file) StartTLS command, and then eventually timeout and
disconnect the Bad Guy when no StartTLS comes.  Their initial TCP
connection is successful before we have any chance to verify client certs,
and furthermore, they know what service I'm offering.  Since they can
determine my O.S. from the way my TCP/IP stack behaves, they could narrow
down the list of potential SMTP servers to the most popular ones (with
SMTP, that would be sendmail, postfix, or qmail.  With LDAP, running on
Linux, you have a very high likelihood of it being OpenLDAP.)

	If instead you are running pure SSL on a high port, then for one,
you can set your firewall rules for port 25 to not repond at all -- the
spammers will not even know there's a computer at that I.P. address, let
alone a mail server.  This costs my server absolutely nothing at all, and
the Bad Guys have to wait for their TCP/IP stack to timeout before
deciding that there is no computer there (at least, not on that port).

	If they scan ALL my ports, all they will see is an SSL listener on
the high port.  They will have no idea what service (or what server
software!) is running.

	And when valid users do connect on the high port, it's pure TLS
from the get-go, meaning we can verify their client certificate before any
connection at all is even established to the SMTP/LDAP/IMAP server.

	So for those reasons, I think just having SSL on a high port is
preferable.  Your users need to configure the server name in their clients
anyhow, so it is practically no extra work to tell them to set the port to
636 (or whatever).

	I'd be very interested to hear what others have to say about this.
For me, this means I'm using stunnel to wrap OpenLDAP, instead of using
OpenLDAP's native TLS support.  If I choose a port number above 1024,
stunnel doesn't even need to be suid root.


Thanks,
Derek Simkowiak