[Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636

[SourceForge.net]

Bugs item #1466426, was opened at 2006-04-07 18:18
Message generated for change (Comment added) made by psychotrahe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General plugin execution
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Rouillard (rouilj)
Assigned to: Matthias Eble (psychotrahe)
Summary: 1.4.2 check_ldaps doesn't default to port 636

Initial Comment:
check_ldaps in the 1.4.2 release doesn't automatically
try to conect to port 636. It uses port 389 like
check_ldap does.

-- rouilj


----------------------------------------------------------------------

>Comment By: Matthias Eble (psychotrahe)
Date: 2007-06-20 13:15

Message:
Logged In: YES 
user_id=1694341
Originator: NO

I commited Holger's proposals a couple of minutes ago. I hope, i didn't
break backward compatibility, but I'm quite sure everything should work as
expected.
The --ssl and --starttls arguments are now valid for check_ldap, too. Not
only to check_ldaps. 

John, it would be great if you could checkout and try the latest cvs
version.

Thanks for your report.
Matthias

----------------------------------------------------------------------

Comment By: Holger Weiss (hweiss)
Date: 2007-06-19 19:02

Message:
Logged In: YES 
user_id=759506
Originator: NO

Personally, I'd find "--old-ldaps" a bit confusing, too.  I'd
suggest:

1) By default, keep the current behaviour for backwards
   compatibility.
2) Introduce two new flags:
   - "-T/--starttls", which forces, well, STARTTLS.
   - "-S/--ssl", which forces "SSL on connect" and sets the default
     port to 636 (even nicer would be to use getservbyname(3), but
     IIRC we do that nowhere, so that's a different story).  If
     "--ssl" seems too ambiguous, it could be called
     "--ssl-on-connect" or so, but I'd prefer "--ssl" as 
     "check_http", "check_tcp" and possibly other plugins use it.
   If either option is used, the plugin doesn't care about argv[0]
   nor about the specified port. If neither option is used, you get
   the current behaviour.
3) Document the default behaviour, and maybe also mark it as
   deprecated: "If this plugin is called via 'check_ldaps', 
   'STARTTLS' will be used, unless --port=636 is specified, in which
   case 'SSL on connect' will be used.  This behaviour is deprecated,
   please use 'check_ldap' with the '--starttls' or '--ssl' flags
   instead."

Just my 2¢, Holger

----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-06-19 18:30

Message:
Logged In: YES 
user_id=1694341
Originator: NO

For the records:

wikipedia claims:
>A common alternate method of securing LDAP communication is using an SSL
tunnel. This is >denoted in LDAP URLs by using the URL scheme "ldaps". The
default port for LDAP over SSL >is 636. The use of LDAP over SSL was common
in LDAP Version 2 (LDAPv2) but it was never >standardized in any formal
specification. This usage has been deprecated along with >LDAPv2, which was
officially retired in 2003

so if i got it right, starttls starts a tls connection on port 389, ssl on
connect uses ssl wrapped around normal ldap since tls was not included in
ldap that time

I'd say these steps need to be done?
- introduce an argument --old-ldaps to force direct connection to 636
- keep default behaviour if -p 636 is given -> ldaps
- set default port to 636 if --old-ldaps is defined
- introduce default behaviour (startTLS) in --help

what do you think?
matthias


----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-06-19 17:48

Message:
Logged In: YES 
user_id=1694341
Originator: NO

Today i have read about a user expecting ldaps to connect to 636 in a
forum.

But using the direct connection seems to be deprecated according to
http://www.openldap.org/lists/openldap-software/200409/msg00617.html

So startTLS should be the right way to make it. I couldn't find out if
ldap_start_tls_s() eventually makes a secure connect after the query on the
default port. IMO it should do so.







----------------------------------------------------------------------

Comment By: John Rouillard (rouilj)
Date: 2007-06-19 17:38

Message:
Logged In: YES 
user_id=707416
Originator: YES

I checked the code I used to compile the check_ldaps binary. It matches
the startls stuff that
hweiss detailed. I agree with psychotrahe that check_ldaps should use port
636
and not 389 with startTLS. At the very least it has to be documented.

I can verify the startTLS error:

  /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10

  Could not init startTLS at port 389!

when running against a non-TLS enabled server. I am starting to think
that
my port 389 test that worked was using startTLS. So my assertion:

> Sorry this is a valid bug. I saw one host work, but that
> system (incorrectly) runs both ldap and ldaps so it
> worked against the ldap port without ssl.

should have read:

 ...
 worked against the ldap port *with* ssl,
 but I expected it to use ldaps protocol and not ldap with startTLS.


-- rouilj


----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-06-19 17:25

Message:
Logged In: YES 
user_id=1694341
Originator: NO

Hi Holger,

you are right. I din't know about the startTLS functionality.

IMO check_ldaps lets people expect a to be connecting to a secure port.
startTLS seems to be intended to be used on a non secure port. It should
imo therefore  rather be an option to check_ldap instead of default
behaviour for check_ldaps.
I also couldn't find a hint that clarifies what check_ldaps was intended
to do.

However since we don't want to break backward compatibility, we should as
you said add some lines to --help. 





----------------------------------------------------------------------

Comment By: Holger Weiss (hweiss)
Date: 2007-06-19 16:29

Message:
Logged In: YES 
user_id=759506
Originator: NO

rouilj:

| I saw one host work, but that system (incorrectly) runs both ldap
| and ldaps so it worked against the ldap port without ssl.

Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? 
>From a quick look at the code, if you call "check_ldaps" without specifying
the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL
error if that fails (see check_ldap.c:139-181 from the 1.4.9 release).

psychotrahe:

AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to
trying STARTTLS, unless "--port=636" was specified, in which case it tries
LDAPS (that is, "SSL on connect").  The change you suggested would make the
plugin behave the other way round, so I guess this would then confuse the
STARTTLS users instead of the LDAPS users :-)  More importantly, it would
break existing configurations which don't specify the --port explicitely.

IMO, this is yet another example that such magic (guessing connection
protocols from ports or the other way round) is almost always a bad idea. 
However, for backwards compatibility, we should probably keep the existing
magic by default.  But maybe we should add options to explicitely request
"SSL on connect" or STARTTLS regardless of the port.  And in any case, we
should properly document the behaviour in the --help output.

----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-06-19 15:29

Message:
Logged In: YES 
user_id=1694341
Originator: NO

will fix this tonight.. 
there should be a warning if you connect to the ldaps port and don't get a
ldaps session.
So changing the port to 636 if argv[0] is "check_ldaps" will fix this,
too.

----------------------------------------------------------------------

Comment By: John Rouillard (rouilj)
Date: 2006-04-07 18:56

Message:
Logged In: YES 
user_id=707416

Sorry this is a valid bug. I saw one host work, but that
system (incorrectly) runs both ldap and ldaps so it
worked against the ldap port without ssl.

So that may be another bug, it should fail if it doesn't
get an encrypted session.

-- rouilj


----------------------------------------------------------------------

Comment By: John Rouillard (rouilj)
Date: 2006-04-07 18:51

Message:
Logged In: YES 
user_id=707416

Never mind. User error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880