btb@bitrate.net wrote: > > On Oct 2, 2013, at 11.47, Michael Ströder <michael@stroeder.com> wrote: > >> btb wrote: >>> On 2013.10.02 07.29, Axel Grosse wrote: >>> >>>> when I test on the server itself .. >>>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile >>>> ./ssl/VordelCA.crt >>>> CONNECTED(00000003) >>>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake >>>> failure:s23_lib.c:188: >>> >>> ldaps [port 636] is deprecated. >>> use starttls with the standard port [389]. >>> to test, just use ldapsearch [see the reference to -Z in the man page] >> >> This is nonsense. >> >> From a security perspective there's no reason not to use LDAPS. Well, I'd even >> recommend LDAPS since SSL/TLS handshake is done *before* a client can send an >> LDAP PDU. >> With my deployments I always enable both but prefer LDAPS. >> >> I cannot imagine that any LDAP server or client will ever drop support for >> LDAPS since this would immediately rule out this implementation from broader >> market share. > > i'm not sure what exactly you mean by "this is nonsense". ldaps was never > offered as a formal specification, and *is* deprecated. I don't know of any document forbidding use of LDAPS. I don't know any server which implements StartTLS which is not capable of LDAPS (despite configuration choice). > that's a fact: http://www.openldap.org/faq/data/cache/605.html . FAQ entries are no formal specification. But you should read all of the FAQ: "Although there is no technical specification for ldaps:// it is widely used." > ldaps may well be in continued use even given its deprecation, but no one > is debating that, and it's continued use in light of being deprecated does > not change that it's deprecated. we all know it's still heavily used, and > probably will continue to be for, at the very least, quite some time. And because it's heavily used it's nonsense to teach everybody this pseudo argument about "deprecated". And as said I find it even to be more secure. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature