GNOME Bugzilla – Bug 640083
Cannot configure LDAPS on port 636
Last modified: 2011-06-02 07:35:47 UTC
Evolution 2.32.1 on Fedora 14. I was trying to setup Evolution to retrieve address information from our LDAP server. Said server is only available via LDAPS on port 636, the designated port for LDAPS. This server does not allow TLS connections on Port 636, because that would be a violation of the SSL protocol. It does not listen on port 389 or any other port, as it does not listen for clear text connections. (We use LDAPS instead of LDAP with TLS because with the later, misconfigured clients could send passwords in cleartext to the server, which violates our security policy.) Via the address book settings dialogue I supplied Evolution with information on the server name, search base, search scope and sufficient credentials to log on to the LDAPS server. I could verify this setup by searching the server with the very same information and credentials on the CLI with the ldapsearch tool. I can also connect to the same server with the same settings in Thunderbird. However, when I told Evolution to use SSL encryption for the connection, I was surprised that the settings dialogue didn't automatically change the port to 636. I was even more surprised that after I changed the port to 636 manually, the dialogue changed the encryption method to TLS and the field was greyed out, so I couldn't change it back. When I tried to connect to the LDAPS server the connection failed with the error message that legitimation to the LDAP server had failed and that I should verify my login credentials. The server's log told quite a different story: 2011-01-20 17:02:59.351596500 conn=23569 fd=46 ACCEPT from IP=2001:470:9f47:1:f24d:a2ff:feda:bebd 33723 (IP=2001:470:9f47:1::1 636) 2011-01-20 17:02:59.352094500 TLS: can't accept. 2011-01-20 17:02:59.352096500 TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol s23_srvr.c:571 2011-01-20 17:02:59.352097500 conn=23569 fd=46 closed (TLS negotiation failure) As you can see quite clearly, the connection is established on Port 636, but Evolution tries to speak clear text LDAP to the server and initiate a TLS session. This is obviously wrong, Evolution should speak SSL from the start and only start LDAP communication after the SSL session has been established, this is the port for LDAPS after all and I was trying to tell Evolution to speak SSL on that port, but couldn't. As a side note: I looked into Evolutions configuration files to see wether I could somehow fix this via a config file. Please tell me that the format of files like ~/.gconf/apps/evolution/addressbook/%gconf.xml is not your understanding of XML. This is one of the worst uses of XML that I have ever seen outside of an Apple project: …snip… <stringvalue><?xml version="1.0"?> <group uid="1295536172.2676.1@LOCALHOST.LOCALDOMAIN" name="Auf LDAP-Servern" base_uri="ldap://" readonly="no"><source uid="1295536828.2676.25@LOCALHOST.LOCALDOMAIN" name="SERVERNAME" uri="ldap://SERVERNAME:636/dc=EXAMPLE,dc=COM??one?" relative_uri="SERVERNAME:636/dc=EXAMPLE,dc=COM??one?"><properties><property name="completion" value="true"/><property name="timeout" value="3"/><property name="offline_sync" value="1"/><property name="limit" value="100"/><property name="ssl" value="always"/><property name="remember_password" value="false"/></properties></source></group> </stringvalue> …snip… (I removed hostnames and the like, changes are in uppercase.) Even in gconf-editor it doesn't look much better.
Agreed with your side note. I'm in the process of rewriting all this. Target release is 3.2. You might be interested in [1], although some details have changed since that initial post. As for the bug itself, it looks like the dialog is forcing encryption to the wrong option for port 636. The LDAP backend should use LDAP-over-SSL if told to do so. If you can manage to change the "ssl" property in the XML blob to "whenever_possible", I think that might do it. <property name="ssl" value="whenever_possible"/> [1] http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html
Fixed for 2.32.2 and 2.91.6: http://git.gnome.org/browse/evolution/commit/?id=54a449adacdb24ffad2e64fe1962161e4ecb24a9 http://git.gnome.org/browse/evolution/commit/?h=gnome-2-32&id=8542059ec53e51f56ddc4b4ad720739ec075c72a
(In reply to comment #2) > Fixed for 2.32.2 and 2.91.6: > > http://git.gnome.org/browse/evolution/commit/?id=54a449adacdb24ffad2e64fe1962161e4ecb24a9 > > http://git.gnome.org/browse/evolution/commit/?h=gnome-2-32&id=8542059ec53e51f56ddc4b4ad720739ec075c72a Hi! Thanks for the reply and sorry that it took me so long to get back to you on this. I just couldn't find the time to build the new version. Unfortunately, the bug is not fixed in 2.32.2. The dialog box now _displays_ the correct settings, but it doesn't use them: 2011-02-14 16:15:58.056176500 conn=4200 fd=37 ACCEPT from IP=2001:470:9f47:1:f24d:a2ff:feda:bdf1 38389 (IP=2001:470:9f47:1::1 636) 2011-02-14 16:15:58.056451500 TLS: can't accept. 2011-02-14 16:15:58.056502500 TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol s23_srvr.c:571 2011-02-14 16:15:58.056631500 conn=4200 fd=37 closed (TLS negotiation failure) So in other words: If I set up a new ldap address book in evolution 2.32.2 and with my server's name and port (636) it sets the secure connection method to SSL in the GUI, but it still speaks TLS to the server who naturally refuses to play along. Also, the config file ~/.gconf/apps/evolution/addressbook/%gconf.xml now does not include any SSL properties, not even "<property name="ssl" value="whenever_possible"/>". I tried this with a completely new system account just to be sure. (BTW: Overwriting the setting in the config in 2.32.1 as suggested in your first comment didn't work. I testet that before I upgraded to 2.32.2. -- Besides that I think rewriting the configuration file layout is a very good idea, thank you in advance.)
I've encountered a similar problem to the OP - unable to get Evolution to talk LDAP/SSL. I've had a look through the source code and it's pretty clear that only TLS is implemented. In evolution-data-server/addressbook/backends/ldap/e-book-backend-ldap.c in the function e_book_backend_ldap_load_source() the use of the configuration options 'ssl.always' and 'ssl.whenever_possible' map to E_BOOK_BACKEND_LDAP_TLS_ALWAYS and E_BOOK_BACKEND_LDAP_TLS_WHEN_POSSIBLE respectively. It looks to me that ssl.always should mean SSL is used, and ssl.whenever_possible should mean TLS is negotiated. However as far as I can tell LDAP over SSL simply isn't implemented in the backend code at all.
Created attachment 181440 [details] [review] proposed eds patch for evolution-data-server; I'm not able to fully test this change, but I would like to ask you to give a try to it and report back whether it'll work for you. Thanks in advance.
It does not seem to work. According to the server's log file, the client still tries to start a TLS session. I also employed tcpdump to verify that. As for "only TLS is implemented": Why? Evolution can talk SSL with SMTP, IMAP and POP servers, so clearly the general ability to establish SSL connections is there somewhere. When I first encountered this bug, the first thing I did was opening up a fake SMTP server with OpenSSL's s_server using the same certificate the LDAP server is using on port 465, then I got Evolution to connect to that SMTP server. I did that to verify that this is not an issue with the certificate or the certificate chain, which it wasn't. I can understand if the mail handling parts of evolution are completely different from those handling LDAP, but shouldn't they all use the same basic routines to handle network traffic? I presume that all the TLS and SSL stuff is taken from the OpenSSL libraries anyway.
(In reply to comment #6) > I can understand if the mail handling parts of evolution are completely > different from those handling LDAP, but shouldn't they all use the same basic > routines to handle network traffic? I presume that all the TLS and SSL stuff is > taken from the OpenSSL libraries anyway. We use the OpenLDAP library, which has its own API for establishing a secure connection and is completely separate from all the other networking libraries we use, most of which have -their- own API for establishing a secure connection.
(In reply to comment #6) > It does not seem to work. According to the server's log file, the client still > tries to start a TLS session. I also employed tcpdump to verify that. Did you modify the ESource as described in comment #3? The patch counts with an unmodified source, or more precisely, forces SSL when the ldaps port is used. Could you also check it goes through new lines, please? You can achieve that by running e-addressbook-factory under gdb.
@comment #7: OK, that makes sense. Since we're using OpenLDAP's LDAP server slapd, at least we now know that SSL support should be in the library. @comment #8: OK, that's way over my head. comment #3 came from me and does not describe any modifications to the software. I simply got myself a tarball of 2.32.2, took the SRPM from my distro and adopted that SRPM so it would use the newer 2.32.2 tarball. A few days later Fedora had the same version in it's fedora-testing repository, which I tested as well (same result: didn't fix it). Which "ESource" am I supposed to modify? I just got me the latest evolution-data-server tarball from the 2.32 series, took the SRPM from my distro, adopted it to use the new tarball and to include your patch. As for gdb: I've never worked with that before, you'd have to give me much more information on how to do this. I'm sorry if this sounds ignorant, but I'm not familiar with your development process or your build process or your source. If you want to test your patch yourself, you don't have to setup an LDAP server, you just need a X509 certificate and key (which you can create yourself) and OpenSSL's s_server: - create a certificate and key (there's millions of howtos) - run openssl s_server: s_server -cert yourcert.pem -key yourkey.pem -accept 636 you might want to add '-no_tls1' to that, but you don't need to, since you'll see what the client is doing in s_server's output - connect with evolution to were you're running that server This will not simulate an LDAP server, but at least you'll see wether the client is speaking SSL or tries TLS.
I tried the s_server, but I'm also unsure in this part, so I'm rather asking: is the below console output showing the correct thing, that the eds LDAP client didn't try SSL as ought to be, or any error in my certificate generation or command I used to run the s_server? (I used your above, even I didn't have .pem files). > ACCEPT > ERROR > 140048552552256:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown > protocol:s23_srvr.c:593: > shutting down SSL > CONNECTION CLOSED > ACCEPT
Created attachment 189062 [details] [review] eds patch ][ for evolution-data-server; The previous patch wasn't correct, it didn't work to the downstream bug reporter, whom helped me with investigation on this. There is also a misbehaving of the UI editor, not setting proper values to the ESource, thus I'll update that side too.
Created attachment 189063 [details] [review] evo patch for evolution; Note that this patch reverts Matthew's change from comment #2 and it has also a very nice side-effect, the tooltip text finally matches option value.
Created commit 4c9cacd in eds master (3.1.2+) Created commit c5ae6cd in evo master (3.1.2+) Created commit 70466da in eds gnome-3-0 (3.0.3+) Created commit 069e2f8 in evo gnome-3-0 (3.0.3+)