RE: ldaps://

["Howard Chu" <hyc@highlandsun.com>]

I personally prefer a dedicated SSL port for the same reasons. However,
there's no need for stunnel to wrap OpenLDAP, just use ldaps://.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Derek Simkowiak

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