Re: Clarification on SSL/TLS and GQ problem

["Mark H. Wood" <mwood@IUPUI.Edu>]

On 3 Mar 2003, Tony Earnshaw wrote:
> man, 2003-03-03 kl. 07:42 skrev Jayson Henkel:
> > I'm attempting to do what it seems like everyone else on this list. Do
> > the single sign on auth via LDAP. I've read a ton of documentation and
> > have been able to get simple authentication working with pam-ldap. I'm
> > going to eventually implement postfix and courier as well. However,
> > before that I want to protect the traffic being passed back and forth.
> > I've read all sorts of docs on ssl, sasl, tls, ldap and ldaps, and to be
> > quite honest I'm very confused as to how each fits in.
>
> ssl is wire encryption of (normally) tcp traffic on any port you want,
> default is 636 for ldap.

No, that's ldaps: .  That is, an LDAP session entirely encapsulated in an
SSL session.

>                          Encryption is always "on" and a number of
> mechanisms are available. The best site I know of to obtain info on how
> it works, how to configure it etc. is www.openssl.org. ssl is used for
> web server https point-to-point encryption and other similar encrypted
> connections.

> tls is wire encryption using the same mechanism as ssl

TLS is in fact SSLv3 with a few tweaks.  Arguably the most significant
difference is that TLS is an IETF standard and SSL is a vendor "standard".

>                                                        on any port you
> want, default is 389 for ldap. The main difference is that the client
> does a vanilla connection and gives a 'starttls' command, after which
> all traffic is encrypted.

I believe that upward negotiation is orthogonal to TLS-or-SSLv3.

>                           This means that both client and serer have to
> support the tls protocol.

As with the deprecated separate-ports model (ldap: vs. ldaps:) of course.

[snip]
> One thing I've noticed, is that when using ldapsearch (tried this just
> now with 2.1.13 ldapsearch) with the -ZZ option, although the man page
> talks about tls, all encrypted traffic goes via port 636 - which is ssl,
> not tls.

No, as I said, TLS/SSL is orthogonal to encapsulation/upward-negotiation.
The TLS handshake can result in the negotiation of SSLv3 rather than the
nearly identical, though not interoperable, TLSv1.  The same handshake is
done whether using encapsulation (port 636) or upward negotiation (port
389, Start TLS).  See section 3.3 of RFC2830.  See also RFCs 2817
(Upgrading to TLS Within HTTP/1.1) and 2818 (HTTP Over TLS), which define
HTTP carried by TLS via both methods in an analogous fashion.

Specific ports are not mandated by TLS; they are part of the service
definition for each service defined to run over TLS.

Sorry, I know this is going offtopic, but there's enough confusion on this
issue without allowing it to spread further.  Private responses to my
flame will be cheerfully accepted.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".