Project

General

Profile

Bug #306

IMAP connection to imap.gmail.com returns self-signed certificate when SNI not set

Added by Antonio Ospite over 2 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Hiroyuki Yamamoto
Category:
LibSylph
Target version:
-
Start date:
08/24/2018
Due date:
% Done:

0%

Estimated time:

Description

Hi,

since Debian unstable updated OpenSSL to 1.1.1~~pre9 I am getting a self-signed certificate from image.gmail.com:

LibSylph-Message: 10:07:12.055: creazione della connessione IMAP4 a imap.gmail.com:993 ...

sock_connect_async_thread_wait: waiting thread
Reloading /etc/resolv.conf
sock_connect_async_func: connected
sock_connect_async_func: exit
sock_info_connect_async_thread_wait: thread exited with status 0
Connessione SSL usando ECDHE-RSA-CHACHA20-POLY1305
SSL protocol version: TLSv1.2
Certificato del server:
  Oggetto: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
  Distributore: /OU=No SNI provided; please fix your client./CN=invalid2.invalid
  SHA1 fingerprint: 42:59:51:7c:d4:e4:8a:28:9d:33:2a:b3:f0:ab:52:a3:66:32:28:24
  MD5 fingerprint: 90:4a:c8:d5:44:5a:d0:6a:8a:10:ff:cd:8b:11:be:16

I am not sure this is because this OpenSSL version prefers TLSv1.3 and/or something changed on gmail servers.

This is the same issue as in https://bugzilla.redhat.com/show_bug.cgi?id=1611815

The attached patch fixes the issue.

I can send a v2 of the patch which checks the return value if this is preferred.

Thanks,
Antonio

Files

0001-libsylph-ssl.c-Support-SNI-some-servers-imap.gmail.c.patch (964 Bytes) 0001-libsylph-ssl.c-Support-SNI-some-servers-imap.gmail.c.patch Support SNI, some servers (imap.gmail.com) seem to require it Antonio Ospite, 08/24/2018 05:59 PM
v2-0001-libsylph-ssl.c-Support-SNI-some-servers-imap.gmai.patch (1019 Bytes) v2-0001-libsylph-ssl.c-Support-SNI-some-servers-imap.gmai.patch Support SNI (v2), some servers (imap.gmail.com) seem to require it Antonio Ospite, 09/06/2018 11:40 PM

History

#1

Updated by Ricardo Mones over 2 years ago

Is that function available in all OpenSSL versions?

If not the patch needs checking for that function in configure.ac and setting an appropriate variable (e.g. HAS_SSL_set_tlsext_host_name) and surround the added line with #if HAS_SSL_set_tlsext_host_name ... #endif.

Alternatively you can check for the required version of OpenSSL where this function appears in configure.ac.

Otherwise when building with library versions lacking that function it will fail.

#2

Updated by Antonio Ospite over 2 years ago

Ricardo Mones wrote:

Is that function available in all OpenSSL versions?

By looking at the git history, the function was added in commit ed3883d21b (Support TLS extensions (specifically, HostName), 2006-01-02):
https://github.com/openssl/openssl/commit/ed3883d21bb4ddfc21ec9d154e14e84c85db164d#diff-438f1b0413c10e826c8a334445f9d30eR113

The result of "git tag --contains ed3883d21b" tells that it's available since OpenSSL_0_9_8k.

The Windows port of Sylpheed relies on 0.9.8zh:

  • 3.5.0 (stable)
    ... * Win32: OpenSSL was updated to v0.9.8zh.

So this part is covered.

Debian is also OK as shown by "rmadison openssl".

However I agree that some safeguard check can be put in place for older systems.

If not the patch needs checking for that function in configure.ac and setting an appropriate variable (e.g. HAS_SSL_set_tlsext_host_name) and surround the added line with #if HAS_SSL_set_tlsext_host_name ... #endif.

Alternatively you can check for the required version of OpenSSL where this function appears in configure.ac.

Otherwise when building with library versions lacking that function it will fail.

We can either use "#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME" or set the minimum supported version of openssl in configure.ac to what Hiro-san decides.

I'll submit a patch with the former option for distributions to use now, and wait for Hiro-san for the final upstream version.

Would that be OK?

Thanks,
Antonio

#3

Updated by Antonio Ospite over 2 years ago

Antonio Ospite wrote:

I'll submit a patch with the former option for distributions to use now, and wait for Hiro-san for the final upstream version.

Attaching v2 of the patch.

Ciao,
Antonio

#4

Updated by George Koehler about 1 year ago

OpenBSD's package of sylpheed now patches this bug. It is the v2 patch from the previous comment, plus an additional error check on SSL_set_tlsext_host_name(). I left the check #ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME in the patch, but we don't need this check in OpenBSD. This is the patch in OpenBSD:

Index: libsylph/ssl.c
--- libsylph/ssl.c.orig
+++ libsylph/ssl.c
@@ -258,6 +258,13 @@ gboolean ssl_init_socket_with_method(SockInfo *sockinf
         return FALSE;
     }

+#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
+    if (!SSL_set_tlsext_host_name(sockinfo->ssl, sockinfo->hostname)) {
+        g_warning("Error setting servername extension\n");
+        return FALSE;
+    }
+#endif
+
     SSL_set_fd(sockinfo->ssl, sockinfo->sock);
     while ((ret = SSL_connect(sockinfo->ssl)) != 1) {
         err = SSL_get_error(sockinfo->ssl, ret);

Also available in: Atom PDF