Modify

Opened 6 years ago

Last modified 4 years ago

#3142 new defect

TLS doesn't work

Reported by: trac-hacks@… Owned by: eblot
Priority: normal Component: LdapPlugin
Severity: normal Keywords: tls
Cc: trash723723-forums@…, harbulot Trac Release: 0.10

Description

TLS support in the LDAP plugin is broken.

First of all, IIRC TLS works over port 389, not 636 (which is the SSL port, SSL != TLS). This should be fixed in api.py

Also, there are no options to set certificates in trac.ini. (It doesn't use the (CA) certificate set in /etc/openldap/ldap.conf, does it?) I guess to make TLS really work there is still some work to do.

Anyway, I didn't have time to dive into this any further. I hope this can be fixed by someone else.

Or perhaps I missed something, in which case the Wiki documentation should be updated to explain how TLS works with ldapplugin.

Thanks!

Attachments (1)

certverif-and-starttls.patch (3.2 KB) - added by harbulot 4 years ago.
Added support for START_TLS and certificate verification

Download all attachments as: .zip

Change History (4)

comment:1 Changed 6 years ago by cbonar

  • Cc trash723723-forums@… added

Hello

I've made the same assertion : startTLS doesn't seem to work with ldapplugin 0.10.

Here are some steps to reproduce the problem :

1) Installed openldap 2.4.11 (on Debian Lenny)

2) Slapd configured to accept startTLS connections on port 389 (as recommended in the manual)

(Running it with the following command, in order to have debug information :

slapd -d 65535

)

3) Tested ok with the following command :

ldapsearch -ZZ -b "dc=myroot" -D "cn=admin,dc=myroot" -x -w secret -h esgaroth

4) Installed ldapplugin 0.10 from svn

5) trac.ini of my project as follows :

...

[trac]
...
permission_store = LdapPermissionStore
...

[ldap]
enable = true
use_tls = true
host =esgaroth
port =389
basedn =dc=myroot
user_rdn =ou=people
group_rdn =ou=groups
store_bind =true
bind_user =cn=admin,dc=myroot
bind_passwd =secret


(Note : I've tried all kind of combinations, this is the most complete one, but all the others gave the same result)

6) When I connect to my project (let's say http://esgaroth/trac/myproject), I've the following error :

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 339, in send_error
    'text/html')
  File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 684, in render_template
    data = self.populate_data(req, data)
  File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 592, in populate_data
    d['chrome'].update(req.chrome)
  File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 169, in __getattr__
    value = self.callbacks[name](self)
  File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 460, in prepare_request
    for category, name, text in contributor.get_navigation_items(req):
  File "/usr/lib/python2.5/site-packages/trac/versioncontrol/web_ui/browser.py", line 295, in get_navigation_items
    if 'BROWSER_VIEW' in req.perm:
  File "/usr/lib/python2.5/site-packages/trac/perm.py", line 523, in has_permission
    return self._has_permission(action, resource)
  File "/usr/lib/python2.5/site-packages/trac/perm.py", line 537, in _has_permission
    check_permission(action, perm.username, resource, perm)
  File "/usr/lib/python2.5/site-packages/trac/perm.py", line 424, in check_permission
    perm)
  File "/usr/lib/python2.5/site-packages/trac/perm.py", line 282, in check_permission
    get_user_permissions(username)
  File "/usr/lib/python2.5/site-packages/trac/perm.py", line 357, in get_user_permissions
    for perm in self.store.get_user_permissions(username):
  File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 205, in get_user_permissions
    users += list(provider.get_permission_groups(username))
  File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 108, in get_permission_groups
    ldapgroups = self._get_user_groups(username)
  File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 149, in _get_user_groups
    ldap_groups = self._ldap.get_groups()
  File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 541, in get_groups
    groups = self.get_dn(self.basedn, 'objectclass=' + self.groupname)
  File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 564, in get_dn
    sr = self._search(basedn, filterstr, ['dn'], ldap.SCOPE_SUBTREE)
  File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 647, in _search
    self._open()
  File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 640, in _open
    raise TracError("Unable to open LDAP cnx: %s" % e[0]['desc'])
TracError: Unable to open LDAP cnx: Can't contact LDAP server

and, on the ldap server side :

daemon: activity on 1 descriptor
daemon: activity on:
slap_listener_activate(8):
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 busy
>>> slap_listener(ldap:///)
daemon: listen=8, new connection on 13
daemon: added 13r (active) listener=(nil)
conn=0 fd=13 ACCEPT from IP=127.0.1.1:43833 (IP=0.0.0.0:389)
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 13r
daemon: read active on 13
connection_get(13)
connection_get(13): got connid=0
connection_read(13): checking for input on id=0
ber_get_next
ldap_read: want=8, got=8
  0000:  16 03 02 00 58 01 00 00                            ....X...
ber_get_next on fd 13 failed errno=34 (Numerical result out of range)
connection_read(13): input error=-2 id=0, closing.
connection_closing: readying conn=0 sd=13 for close
connection_close: conn=0 sd=13
daemon: removing 13
conn=0 fd=13 closed (connection lost)
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on:
slap_listener_activate(8):
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 busy
>>> slap_listener(ldap:///)
daemon: listen=8, new connection on 13
daemon: added 13r (active) listener=(nil)
conn=1 fd=13 ACCEPT from IP=127.0.1.1:43834 (IP=0.0.0.0:389)
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 13r
daemon: read active on 13
connection_get(13)
connection_get(13): got connid=1
connection_read(13): checking for input on id=1
ber_get_next
ldap_read: want=8, got=8
  0000:  16 03 02 00 58 01 00 00                            ....X...
ber_get_next on fd 13 failed errno=34 (Numerical result out of range)
connection_read(13): input error=-2 id=1, closing.
connection_closing: readying conn=1 sd=13 for close
connection_close: conn=1 sd=13
daemon: removing 13
conn=1 fd=13 closed (connection lost)
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero

... I don't see any 'start_tls'...

7) When I change use_tls = true for use_tls = false in trac.ini, it works (I can reach my project's page).

Hope this helps..

Changed 4 years ago by harbulot

Added support for START_TLS and certificate verification

comment:2 Changed 4 years ago by harbulot

  • Cc harbulot added

I've just added a patch to support START_TLS and certificate verification. (For some reason, nothing appears in if you click on the link with the "pretty" view, but the patch is there if you the "Original Format" link at the bottom of the page.)

TLS and SSL are the same thing (or close enough in this context); what's fundamentally different is the use of START_TLS.

A direct TLS connection is done to a port expecting TLS connections initially (via ldaps://, port 636 usually for LDAP), whereas using START_TLS initiates a non-encrypted connection (ldap://, usually on port 389 for LDAP) and then switches on TLS on the same connection, using the appropriate START_TLS command.

I've thus added the use_start_tls option in this patch. START_TLS will be used if this is set to true and if use_tls=false. If use_tls=true, the initial connection will be made using TLS. (I've only made use_tls win over use_start_tls to keep compatibility with the previous settings.)

Since TLS connections (whether-or-not using START_TLS) are not actually secure if the client doesn't verify the server certificate, I've also added options to point to CA certificates:

  • tls_cacertdir=/path/to/ca/cert/dir: This option expects a directory containing trusted CA certificates. Unfortunately, this doesn't seem to be supported by GnuTLS, if your client library has been compiled against it.
  • tls_cacertfile=/path/to/ca/cert/file: This option expects a file containing a set of concatenated CA certificates (in PEM format). This works for me (especially, if this option is set and the certificate isn't trusted by one of the CAs, the connection fails as it should).

comment:3 Changed 4 years ago by harbulot

I should perhaps add the versions with which I've tested this:

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.