After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711602 - Client TLS certificates not sent to SMTP and IMAP servers for authentication
Client TLS certificates not sent to SMTP and IMAP servers for authentication
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: general
3.10.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
: 753958 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-11-07 11:22 UTC by David Hicks
Modified: 2021-05-19 11:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Hicks 2013-11-07 11:22:48 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?
Comment 1 Matthew Barnes 2013-11-07 13:59:31 UTC
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.
Comment 2 David Hicks 2013-11-07 15:52:37 UTC
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.
Comment 3 David Hicks 2013-11-07 16:01:16 UTC
Relevant commit where the old client TLS certificate support was removed: https://git.gnome.org/browse/evolution-data-server/commit/?id=428b8dbe248e02baa22929fbc3ed8cbf453cc139
Comment 4 Matthew Barnes 2013-11-07 16:10:27 UTC
(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.
Comment 5 Matthew Barnes 2013-11-07 19:03:22 UTC
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?
Comment 6 Matthew Barnes 2013-11-07 19:06:47 UTC
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.
Comment 7 Milan Crha 2014-03-06 16:44:45 UTC
I'm adding Dan for his opinion on comment #2 to bottom.
Comment 8 Dan Winship 2014-03-06 17:37:58 UTC
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.
Comment 9 Milan Crha 2015-08-26 13:18:07 UTC
*** Bug 753958 has been marked as a duplicate of this bug. ***
Comment 10 André Klapper 2021-05-19 11:03:32 UTC
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.