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

RE: ldaps://

Generally, it's helpful if you read the manual for a program before you try
to use it, especially if you plan to use non-default options.... See
slapd(8).

	slapd -h 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: marc.bigler@day.com [mailto:marc.bigler@day.com]
> Sent: Thursday, October 17, 2002 12:05 AM
> To: Howard Chu
> Cc: openldap-software@openldap.org
> Subject: RE: ldaps://
>
>
>
> Thanks for all the comments, also for a security reason as
> mentioned by
> Derek I would prefer disabling port 389 and using only port
> 636 (ldaps) by
> all of my clients.
>
> Now the question is how can I do this, I don't want to use
> stunnel as you
> say you don't need it (less administration if you have less
> software to
> upgrade...). Do you have any pointers for that or maybe some
> quick steps ?
>
> Many thanks in advance
>
> Regards
> Marc
>
>
>
>
>
>
>
>
>
>
>                     "Howard Chu"         To:     "'Derek
> Simkowiak'" <dereks@itsite.com>, <marc.bigler@day.com>
>
>                     <hyc@highlands       cc:
> <openldap-software@OpenLDAP.org>
>
>                     un.com>              Subject:     RE:
> ldaps://
>
>
>
>
>                     10/16/02 08:48
>
>
>                     PM
>
>
>
>
>
>
>
>
>
>
>
>
> 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
> >
> >
> >
>
>
>
>
>
>
> --
>