Bug #306

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

Added by Antonio Ospite 26 days ago. Updated 12 days ago.

Status:NewStart date:08/24/2018
Priority:NormalDue date:
Assignee:Hiroyuki Yamamoto% Done:

0%

Category:LibSylphSpent time:-
Target version:-

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

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

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

History

#1 Updated by Ricardo Mones 13 days 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 12 days 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 12 days 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

Also available in: Atom PDF