GNOME Bugzilla – Bug 711602
Client TLS certificates not sent to SMTP and IMAP servers for authentication
Last modified: 2021-05-19 11:03:32 UTC
Since Evolution/EDS 3.9.5, client TLS certificates do not appear to be sent to remote SMTP (postfix) and IMAP (dovecot) servers for client certificate authentication. Versions of Evolution/EDS prior to 3.9.5 were OK. Later versions 3.9.9x displayed an end-of-file error when attempting to connect to either SMTP or IMAP servers requiring TLS client certificate authentication. Version 3.10.1 and the current git master as of November 7th 2013 simply fail with an access denied error. Mail server logs in TLS debug mode highlight the error as no TLS client certificate being sent by Evolution. Has something changed in Evolution/EDS 3.9.xx with regards to TLS connectivity?
No idea about this. The only related E-D-S change around that timeframe was https://git.gnome.org/browse/evolution-data-server/commit/?id=b3b4ca29572791b40f7ebd1bea0501305b9356c7 But you say it's broken on git master as well, and git master no longer uses NSS for secure network connectivity. It defers that stuff entirely to GLib, so that commit is no longer relevant in 3.11.x. Sounds like something a base library would handle for us, but you can prove me wrong by git bisecting evolution-data-server between a working and non-working version.
Thanks for the pointers Matt. I tracked the issue down and can explain the problem: For evolution-data-server 3.8 client certificate authentication appears to have been handled by the ssl_get_client_auth function in camel/camel-tcp-stream-ssl.c (refer to [1]). With the move to GIO (GTlsClientConnection) in evolution-data-server 3.10 it appears that this old client certificate authentication code has been removed/neglected. A quick grep of the source code (current git master) for the GIO equivalent client certificate handling functions g_tls_connection_set_certificate and g_tls_client_connection_get_accepted_cas does not return any hits. The correct approach would probably be to: 1. Allow the user to specify a specific client certificate for use with SMTP and IMAP/POP/etc connections for each account configured. This would require UI changes in the Account Editor dialog under the Security section of the Receiving Email and Sending Email tabs. 2. Call g_tls_client_connection_get_accepted_cas after in the callback function network_service_accept_certificate_cb (or perhaps earlier in function camel_network_service_starttls of camel/camel-network-service.c) to verify that the user-specified client certificate has a matching certificate authority chain to what the server is expecting. Documentation at [2] is unclear whether function g_tls_client_connection_get_accepted_cas can be called as a matter-of-course during a normal connection or whether it can only be called upon a handshake failing with return code G_TLS_ERROR_CERTIFICATE_REQUIRED. 3. After confirming a valid user-specified certificate exists to meet the expectations of the server, set the user-specified client certificate by using the g_tls_connection_set_certificate function. The call to function g_tls_connection_set_certificate would need to occur during the very initial stages of establishing the handshake (see usage documentation at [2]). Step 1 is required because IMAP/SMTP servers may take authentication user names from the CN (common name) field of validly signed certificates provided by connecting clients. It is possible that a connecting client has multiple accounts on these servers signed by the same certificate authority. Thus the need for the user to manually select the certificate with the correct common name or serial number for the particular account/server. It may also be possible with some limitations[3] to automatically guess the correct client certificate by brute force approach, caching/saving the result for all future connections to the server. Any thoughts on the above suggested solution? [1] https://git.gnome.org/browse/evolution-data-server/tree/camel/camel-tcp-stream-ssl.c?h=gnome-3-8#n143 [2] https://developer.gnome.org/gio/stable/GTlsConnection.html#g-tls-connection-set-certificate [3] Limitations include poor scalability for the border case of users with dozens of e-mail accounts, increased connection latency due to sequential initiation of multiple TCP/IP handshakes and the risk of an SMTP/IMAP server or intrusion detection system detecting the brute force certificate guessing attempts as a denial of service attack.
Relevant commit where the old client TLS certificate support was removed: https://git.gnome.org/browse/evolution-data-server/commit/?id=428b8dbe248e02baa22929fbc3ed8cbf453cc139
(In reply to comment #2) > For evolution-data-server 3.8 client certificate authentication appears to > have been handled by the ssl_get_client_auth function in > camel/camel-tcp-stream-ssl.c (refer to [1]). Well, note the #if 0 ... #endif surrounding the function. Seems we deferred that to a base library even in 3.8. > The correct approach would probably be to: > > 1. Allow the user to specify a specific client certificate for use with SMTP > and IMAP/POP/etc connections for each account configured. This would require > UI changes in the Account Editor dialog under the Security section of the > Receiving Email and Sending Email tabs. Agreed, and seems to jive with what Stef Walter proposed at GUADEC: http://stef.thewalter.net/2013/08/more-secure-with-less-security.html Though it's lacking a bit in detail for application authors. > 2. Call g_tls_client_connection_get_accepted_cas after in the callback > function network_service_accept_certificate_cb (or perhaps earlier in > function camel_network_service_starttls of camel/camel-network-service.c) > to verify that the user-specified client certificate has a matching > certificate authority chain to what the server is expecting. Documentation > at [2] is unclear whether function g_tls_client_connection_get_accepted_cas > can be called as a matter-of-course during a normal connection or whether it > can only be called upon a handshake failing with return code > G_TLS_ERROR_CERTIFICATE_REQUIRED. > > 3. After confirming a valid user-specified certificate exists to meet the > expectations of the server, set the user-specified client certificate by using > the g_tls_connection_set_certificate function. The call to function > g_tls_connection_set_certificate would need to occur during the very initial > stages of establishing the handshake (see usage documentation at [2]). Sounds correct (I'm not an expert), but also sounds like something GLib should be assisting with. That was kind of the point of dropping direct, low-level NSS usage for GLib's high-level TLS classes. Dan Winship or Stef Walter would be the ones to talk to about this stuff.
I should clarify the GTlsClientConnection stuff is new in 3.11; version 3.10 still uses NSS directly. Still haven't pinpointed what changed around the 3.9.5 timeframe. Maybe a change in NSS itself, which you happened to upgrade to at the same time?
One way to quickly narrow the scope would be to build an earlier 3.9.x release from source and see whether the issue persists. That would tell us if the change was external to E-D-S.
I'm adding Dan for his opinion on comment #2 to bottom.
Agreed that glib itself needs to provide more helpful API. (Improving the client certificate situation has been on the to-do list forever, but has progressed only very slowly.) Feel free to suggest specific APIs that would make things simple on the evo side.
*** Bug 753958 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/ Thank you for your understanding and your help.