[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Clarification on SSL/TLS and GQ problem
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. 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 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. This means that both client and serer have to
support the tls protocol. A good example of another use for tls is
encrypted esmtp communication between a mail client and a mail server
(the client can also be another mail server.)
sasl works independently from ssl/tls, but both can (and should) be
combined. sasl is a common denominator for various strong authentication
methods, see rfc2222, rfc2444, rfc2195, rfc2245, rfc2595, rfc2831 and
others for encryption standards. Work has also been done by Microsoft
and Novell (Leach and Gayman.)
> I've gone through
> the mailing list archives and it seems I'm not alone. Perhaps a security
> guru can take the time to explain how all these fit together in the
> context of openldap, I for one would really benefit.
This has already been done to a certain extent by contributors to this
list - Turbo Fredriksson and Adam Williams spring to mind. I'm sure
they'll answer you separately. Also, Howard Chus has explained a lot
very patiently with step-by-step instructions on this list and
particular reference to DIGEST-MD5 and Kerberos authentication, you'll
have to consult the archives.
> As it stands now I
> think I've got tls working, I apt-get source'd the debian packages and
> changed them to with-tls, read up on openssl docs, which I must admit
> I'm a newbie at as well, but I think I got it done. I created the
> certificates, hurdled the CN= issue gracefully and managed to start my
> slapd with all sorts of wonderful TLS options. I apt-get source'd the
> ldap-utils package and rebuilt it with tls on my mailserver. Did a
> ldapsearch with -ZZ and got a success message however.....
>
> I run tcpflow -i eth0 -c port 389 on my directory server and attempt to
> browse the directory, much to my dissapointment I can cleary read
> strings and values in the tcpflow window.
Then the traffic is probably not encrypted.
> My password is of course
> prefixed with {crypt} and is infact crypted, but I don't think I'm
> getting tls security.
Your password may be encrypted wherever it is stored, but will always be
sent in clear text over the wire, unless either encryption has been
started or an sasl mechanism such as DIGEST-MD5 or Kerberos is being
used - in which case no password is ever sent over the wire. Read the
rfcs :)
> Pursuing the ldaps:// business it appears
> something is listening on 636, however netstat -a --numeric-ports | grep
> 389 and 636 yeild the following:
> rauru:~# netstat -a --numeric-ports | grep -i 389
> tcp 0 0 0.0.0.0:389 0.0.0.0:*
> LISTEN
> tcp 1 0 127.0.0.1:33266 127.0.0.1:389
> CLOSE_WAIT
> tcp 0 0 127.0.0.1:33566 127.0.0.1:389
> ESTABLISHED
> tcp 0 0 127.0.0.1:33564 127.0.0.1:389
> ESTABLISHED
> tcp 0 0 127.0.0.1:33572 127.0.0.1:389
> ESTABLISHED
> tcp 0 0 127.0.0.1:33570 127.0.0.1:389
> ESTABLISHED
> tcp 0 0 127.0.0.1:33569 127.0.0.1:389
> ESTABLISHED
> tcp 1 0 127.0.0.1:33501 127.0.0.1:389
> CLOSE_WAIT
> tcp 1 0 127.0.0.1:33498 127.0.0.1:389
> CLOSE_WAIT
> tcp 1 0 127.0.0.1:33499 127.0.0.1:389
> CLOSE_WAIT
> tcp 0 0 127.0.0.1:389 127.0.0.1:33564
> ESTABLISHED
> tcp 0 0 127.0.0.1:389 127.0.0.1:33566
> ESTABLISHED
> tcp 0 0 127.0.0.1:389 127.0.0.1:33569
> ESTABLISHED
> tcp 0 0 127.0.0.1:389 127.0.0.1:33570
> ESTABLISHED
> tcp 0 0 127.0.0.1:389 127.0.0.1:33572
> ESTABLISHED
> rauru:~# netstat -a --numeric-ports | grep -i 636
> tcp 0 0 0.0.0.0:636 0.0.0.0:*
> LISTEN
> rauru:~#
The above shows that all active traffic is going over port 389. Although
there is a daemon listening on port 636, there is no traffic to that
port.
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.
You'll surely have many more questions, others will answer in their own
way. There IS *more than enough* info on the Internet and in the
archives for this list, it's a question of finding it.
Best,
Tony
--
Tony Earnshaw
All the world is mad, exceptin thee and me
and even thee's a little queer
e-post: tonni@billy.demon.nl
www: http://www.billy.demon.nl