Using the same LDAP user's account witch require a password: - LDAPs (port 636) with checkbox SSL/TLS checked -> ok - LDAP (port 389) with checkbox SSL/TLS and STARTTLS unchecked -> ok - LDAPv3 (port 389) with checkbox STARTTLS checked -> KO Using "ldapsearch -H ldap://serverName -Z -D '<DN_of_the_user>' -w" is working fine, so no LDAP misconfiguration identified. Looking with packet sniffer: seems that even with the checkbox STARTTLS checked no STARTTLS is initiate but a standard SSL/TLS connection.
(In reply to comment #0) > Using the same LDAP user's account witch require a password: > > - LDAPs (port 636) with checkbox SSL/TLS checked -> ok > - LDAP (port 389) with checkbox SSL/TLS and STARTTLS unchecked -> ok > - LDAPv3 (port 389) with checkbox STARTTLS checked -> KO Which is the status of SSL/TLS checkbox in the third case? > Using "ldapsearch -H ldap://serverName -Z -D '<DN_of_the_user>' -w" > is working fine, so no LDAP misconfiguration identified. > > Looking with packet sniffer: seems that even with the checkbox STARTTLS > checked no STARTTLS is initiate but a standard SSL/TLS connection. Looking at current code STARTTLS is not initiated if SSL/TLS checkbox is enabled, so you may try to disable it and see if it works.
The two checkbox "SSL/TLS" and "STARTTLS" can't be checked together: - when "STARTTLS" is checked, "SSL/TLS" is grey, so you can't enable it. - In the same way when "SSL/TLS" is checked, "STARTTLS" is grey, so you can't enable it. This is behaviours is totally normal.
Created attachment 1825 [details] Probably better URI for LDAP with STARTTLS
(In reply to comment #2) > The two checkbox "SSL/TLS" and "STARTTLS" can't be checked together: > > - when "STARTTLS" is checked, "SSL/TLS" is grey, so you can't enable it. > - In the same way when "SSL/TLS" is checked, "STARTTLS" is grey, so you > can't enable it. > > This is behaviours is totally normal. Heh, that happens when you only look at the code and not at UI ;-) I don't have a STARTTLS enabled LDAP server at hand, so, can you check if attached patch fixes the issue for you? Thanks in advance,
The code modification in attachment 1825 [details] get this result from LDAP logs: conn=1961 fd=41 ACCEPT from IP=... conn=1961 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=1961 op=0 STARTTLS conn=1961 op=0 RESULT oid= err=0 text= conn=1961 fd=41 TLS established tls_ssf=256 ssf=256 conn=1961 op=1 EXT oid=1.3.6.1.4.1.1466.20037 conn=1961 op=1 STARTTLS conn=1961 op=1 RESULT oid= err=1 text=TLS already started => So it is better but not sufficient. To get more clues, when i do something like: ldapwhoami -H ldap://servername -Z -D "userDN" -W Here is the LDAP logs: conn=1963 fd=42 ACCEPT from IP=... conn=1963 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=1963 op=0 STARTTLS conn=1963 op=0 RESULT oid= err=0 text= conn=1963 fd=42 TLS established tls_ssf=256 ssf=256 conn=1963 op=1 BIND dn=... method=128 conn=1963 op=1 BIND dn=... mech=SIMPLE ssf=0 RESULT tag=97 err=0 text= EXT oid=1.3.6.1.4.1.4203.1.11.3 WHOAMI RESULT oid= err=0 text= UNBIND closed => So something is wrong in sequencing the connection.
Created attachment 1826 [details] Even better URIs for LDAP with STARTTLS
(In reply to comment #5) > The code modification in attachment 1825 [details] get this result from LDAP > logs: > > conn=1961 fd=41 ACCEPT from IP=... > conn=1961 op=0 EXT oid=1.3.6.1.4.1.1466.20037 > conn=1961 op=0 STARTTLS > conn=1961 op=0 RESULT oid= err=0 text= > conn=1961 fd=41 TLS established tls_ssf=256 ssf=256 > conn=1961 op=1 EXT oid=1.3.6.1.4.1.1466.20037 > conn=1961 op=1 STARTTLS > conn=1961 op=1 RESULT oid= err=1 text=TLS already started > > => So it is better but not sufficient. To get more clues, when i do > something like: [...] > => So something is wrong in sequencing the connection. Yep, patch was doing STARTTLS twice. I've updated the patch to do it only once. Please try again ;-) Thanks,
I have tested patch attachment 1826 [details] but now there is no STARTTLS any more.
(In reply to comment #8) > I have tested patch attachment 1826 [details] but now there is no STARTTLS > any more. That's a bit strange. With the binary which has the patch applied can you run "/path/to/your/claws-mail --debug > debug.log 2>&1", test connection to your LDAP and attach the debug.log file to this bug? Thanks in advance,
Created attachment 1827 [details] Test STARTTLS ok with pacth code in attachment 1826 [details] I have tested again patch code in attachment 1826 [details] and now it is working! (I should have made a mistake the previous time, sorry) Here is debug logs, to confirm that it is working for STARTTLS. Thanks
Changes related to this bug have been committed. Please check latest Git and update the bug accordingly. You can also get the patch from: http://git.claws-mail.org/ ++ ChangeLog 2017-12-18 21:22:02.673682976 +0100 http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=9b745cfacefcafbb022baf07604cc8f6d0361e56 Merge: d265708 174c03f Author: Colin Leroy <colin@colino.net> Date: Mon Dec 18 21:22:02 2017 +0100 Merge branch 'master' of file:///home/git/claws http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=174c03f1931636ba6a47415619c18ce5af572d69 Author: Ricardo Mones <ricardo@mones.org> Date: Mon Dec 18 21:20:25 2017 +0100 Fix Bug 3936: LDAP StartTLS does not work for addressbooks