Bug #306
IMAP connection to imap.gmail.com returns self-signed certificate when SNI not set
| Status: | New | Start date: | 08/24/2018 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Hiroyuki Yamamoto | % Done: | 0% | |
| Category: | LibSylph | Spent 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 
- Support SNI, some servers (imap.gmail.com) seem to require it
(964 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
(1019 Bytes)
History
#1
Updated by Ricardo Mones about 1 year 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 about 1 year 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 about 1 year 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