Created attachment 1927 [details]
Patch for experimentation only. Needs patched libetpan.
It would be rather nice if Claws Mail supported the Server Name Indication TLS extension, so as to be given the correct certificate when connecting with TLS to `virtual hosted' IMAP / POP / SMTP servers that service multiple domains from a single IP address.
This is eminently doable for POP and SMTP connections, for which gnutls is used directly. IMAP is a little harder since libetpan handles the TLS session and will need extension to also support SNI.
I have just created a pull request for a candidate extension to libetpan (https://github.com/dinhviethoa/libetpan/pull/310) and attach an experimental patch that utilises it, plus adds the necessary internal support for POP & SMTP, for anybody who likes to live on the bleeding edge to try.
Obviously I'm not asking for a review of the patch yet. I'll update this issue and the patch if and when libetpan gains SNI support.
Notes for brave explorers:
- It's a git patch; use `git apply' or `patch -p1' (note NOT -p0 as https://claws-mail.org/devel.php?section=projects asks for)
- You'll need to compile and link against my aforementioned experimentally extended libetpan from GitHub
- I've only built and tested it on Linux and only connecting to IMAP and SMTP as that's all I have easy access to. Works for me but your mileage may vary!
Libetpan 1.9.2 has been released with SNI support (https://github.com/dinhviethoa/libetpan/releases/tag/1.9.2).
However, I am wondering whether using SNI unconditionally is a good idea from security point of view, since it sends the domain name in plaintext. I certainly don't need it for my personal servers.
(In reply to comment #1)
> However, I am wondering whether using SNI unconditionally is a good idea
> from security point of view
No, I was always planning to make it optional in the proper patch. The experimental patch I attached was very much the bare minimum necessary to allow people to test and provide feedback as to whether the low-level changes work or not.
I'm thinking of adding a check box to the SSL/TLS page of the account settings window so that SNI can be enabled only on those accounts that need it, or at least, can be disabled on accounts that don't need it.
I'm leaning towards making it on by default on the following grounds:
- The privacy / security implications of the name being transmitted in the clear are most relevant where SNI *is* needed; typically if it isn't needed then the destination IP address uniquely maps to a single domain name anyway and hence the information can typically be obtained regardless.
- Those who know that SNI is not needed and who care about hiding which domain name the connection is for are reasonably likely to have the knowledge and experience required to find and turn off the option.
- Some widely used services like gmail require it so those who will need it and will want things to "Just Work(tm)" without much effort may be the majority.
- A future TLS version is likely to fill the known hole in SNI so at some point the concern may well go away of its own accord.
Arguments to the contrary welcome!
Yes, an account preference, enabled by default, is what we agreed upon on IRC as well, so full agreement there. :)
We are planning a quick bugfix release this week, but since adding the checkbox to account preferences dialog would mean adding new translatable string(s), I think it would be best to introduce it as a hidden preference (controllable only by directly editing accountrc file) for now, and add the proper checkbox in a future release.
Any other opinions on this? We definitely need to add that preference from the get go, in order to avoid issues for users who might be using servers without SNI support.
Completely agree with you guys :)
Created attachment 1943 [details]
Attached a new patch, based on Alex' original patch:
- added "use_tls_sni" account pref
- added libetpan version check
- use sockinfo->hostname instead of sockinfo->canonical_name, since the latter usually contains non-canonical (go figure) name resolved from the IP address, e.g. "gmail-pop.l.google.com", which we do not want to set our SNI to
Changes related to this bug have been committed.
Please check latest Git and update the bug accordingly.
You can also get the patch from:
++ ChangeLog 2018-12-21 10:31:05.788909400 +0100
Author: Andrej Kacian <firstname.lastname@example.org>
Date: Fri Dec 21 10:21:10 2018 +0100
Add Server Name Indication support to TLS connections, if applicable.
Adds a hidden pref "use_tls_sni".
Patch by Alex Smith.
Closes bug #4103: TLS SNI (Server Name Indication) support for IMAP, POP & SMTP