Feature #9302

Consider shipping claws-mail 3.10.1-2~bpo70+1

Added by sajolida 2015-04-30 07:21:52 . Updated 2015-08-25 14:06:22 .

Status:
Rejected
Priority:
Low
Assignee:
Category:
Target version:
Tails_1.4
Start date:
2015-04-30
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

As pointed out by Adam Burns on https://mailman.boum.org/pipermail/tails-dev/2015-April/thread.html, version 3.10 has a new option Automatically save message to Draft folder every … → Even if message is to be encrypted which allows to disable autosave of plain text messages.

This is only a partial fix but it could mitigate the issue in some cases.

  • Is it worth it?
  • Could this option then be made off by default in Tails and applied to all users who already configured? I don’t think we can count on people reading the release notes, so if we can’t automate that we should probably issue the security advisory about Claws as a separate blog post and after the release of 1.4.

Subtasks

Related issues

Related to Tails - Bug #9161: Write a security advisory about Claws leaking cleartext to IMAP server Resolved 2015-04-06
Related to Tails - Feature #8305: Evaluate shipping Claws Mail 3.11.1+ Rejected 2014-11-26
Related to Tails - Bug #6459: Claws Mail crashes too often Rejected 2013-11-30

History

#1 Updated by sajolida 2015-04-30 07:30:09

  • related to Bug #9161: Write a security advisory about Claws leaking cleartext to IMAP server added

#2 Updated by intrigeri 2015-04-30 07:48:16

  • related to Feature #8305: Evaluate shipping Claws Mail 3.11.1+ added

#3 Updated by intrigeri 2015-04-30 07:52:34

We should first check whether it weakens TLS certificate verification (Feature #8123#note-5).

#4 Updated by sajolida 2015-05-01 12:48:47

  • related to Bug #6459: Claws Mail crashes too often added

#5 Updated by sajolida 2015-05-01 12:50:03

  • Assignee set to intrigeri
  • QA Check set to Info Needed

I’m not sure to understand what you are referring nor what I should do about it.

The note you are pointing it refers to Claws 3.11 while I’m referring to Claws 3.10.1 which is the only backport I can see. I searched for the scary message that you are referring to (“This makes the complete certificate chain not available”) in the notes from that backports and couldn’t find anything.

I read the Changelog (https://sources.debian.net/src/claws-mail/3.11.1-3/NEWS/) and the only mentions about TLS, SSL, or stuff like that I found are not relevant I think:

* Complete SSL certificate chains are now saved, and if built with
  Libetpan 1.4.1, the IMAP SSL connection's certificate chain is made
  available. Both of these allow correct certificate verification
  instead of a bogus 'No certificate issuer found' status.

* Add an account preference to allow automatically accepting
  unknown and changed SSL certificates, if they're valid (that is,
  if the root CA is trusted by the distro).

* Support for GnuTLS priority string has been added. This is achieved
  via 2 hidden account preferences, gnutls_set_priority and 
  gnutls_priority. The former turning the option on or off, the
  latter containing the required priority string.

On the other hand, the changelog has plenty of bugfixes regarding various crashes, so we might get better at Bug #6459.

#6 Updated by intrigeri 2015-05-01 13:18:40

> I’m not sure to understand what you are referring nor what I should do about it.

Sorry for being unclear :(

> The note you are pointing it refers to Claws 3.11 while I’m referring to Claws 3.10.1 which is the only backport I can see.

Yes, with “the backport changelog” I was referring to the only backport available back then, which was indeed 3.10.something. It can be found there: http://metadata.ftp-master.debian.org/changelogs//main/c/claws-mail/claws-mail_3.10.1-2~bpo70+1_changelog

(Here’s how I’ve found it: https://tracker.debian.org/pkg/claws-mail, click on the 3.10.1-2~bpo70+1 link, then click on the Debian Changelog link.)

=> one should ask the backporter what they meant exactly, and/or try to find out by conducting tests. Rationale: it would be a little bit sad to trade “safer OpenPGP” for “half-broken TLS verification”, in case that’s implied by “the complete certificate chain not [being] available”.

#7 Updated by intrigeri 2015-05-01 13:19:17

  • Assignee changed from intrigeri to sajolida
  • QA Check deleted (Info Needed)
  • Type of work changed from Discuss to Research

#8 Updated by sajolida 2015-05-03 03:02:36

  • Assignee changed from sajolida to intrigeri
  • QA Check set to Info Needed

Thanks for the extra guidance. I was checking the upstream changelog and not the Debian one. Now I got it better.

Meta: I feel this is quite out of my zone of competence and what I’m trying to do here is to understand what should be documented in the security advisory (or better, included in Tails 1.4). I’ll raise these issues during the meeting tonight but the more info we get before, the better.

I understand this part of the Debian changelog as in direct relation with this other part of the upstream changelog:

  • changelog.Debian
Depend on on the versions of libetpan-dev and libgnutls-dev that
are available in stable - This makes the complete certificate
chain not available, which would require a version of libetpan not 
available in wheezy.
  • NEWS (3.10.0)
Complete SSL certificate chains are now saved, and if built with
Libetpan 1.4.1, the IMAP SSL connection's certificate chain is made
available. Both of these allow correct certificate verification
instead of a bogus 'No certificate issuer found' status.
certtool: Uses the new certificate verification functions for
--verify-chain.

certtool: Added new certificate verification functionality
using the --verify option. Combined with --load-ca-certificate
it can verify a certificate chain against a list of certificates.

I understand it means that the new feature described as “Complete SSL certificate chains are now saved” is not available in this backport. Which doesn’t mean a downgrade of SSL features in Claws but rather that we’re not benefiting from this new feature. But I don’t feel qualified to validate this hypothesis.

Does that make any sense?

#9 Updated by sajolida 2015-05-03 05:17:01

  • Assignee deleted (intrigeri)
  • QA Check deleted (Info Needed)

#10 Updated by _adamb 2015-05-03 09:34:26

In a Tails 1.3.2 VM, I’ve been testing the behaviour of the wheezy-backport 3.10.1 claws -mail

With the following default preference settings:

(off) Automatically save message to Drafts folder
(greyed) Even if message is to be encrypted

Action: Replying to an encrypted email, typing more than 50 new characters, clicking send immediately
Result: Message is encrypted and placed in Queued folder (unclear what order), sent over network (encrypted), placed in Sent folder (encrypted)

The default action most users will use appears to be reasonable, but was suspicious in what order it was doing things.

Action: Replying to an encrypted email, typing more than 50 new characters, clicking send later
Result: Message in Queued folder is stored in the clear in the Queued folder(!)

This result was expected from posts I had read on the claws users list. Not great. But maybe still usable.

I then repeated the tests with changed preferences

(on) Automatically save message to Drafts folder
(off) Even if message is to be encrypted

This had the same results.

I run my own IMAP server so I repeated the first step (clicking Send, not Send Later) running a crude bash script on the Queue folder server side, ie

while true; do cp * /root/tmp; done

And yes … facepalm, claws-mail 3.10.1 saves the unencrypted email to the Queue folder before it then encrypts it even with clicking send immediately.

So it appears the option of upgrading claws-mail to 3.10.1 provides a default option to stop the Draft email being saved to the server side folder, but for some unknown reason 3.10.1 saves to the server side Queue before encrypting the email and sending it out, then deleting the in-the-clear Queue message.

In summary, the advantage of the backport is really only a matter of timing.

With the existing 3.8.1 on Tails 1.3.2, the in-the-clear text is saved in the Drafts folder for as long as the user is composing and has not sent the file, once they send it, it’s then copied in-the-clear to the server side Queue folder, encrypted & sent, then the in-the-clear copy is deleted from the Queue folder.

On 3.10.1, no server side Draft saving involved, but server side Queue behaviour is the same.

#11 Updated by _adamb 2015-05-03 09:59:07

Footnote: Under Fedora 21, Claws 3.11.1 displays the same behaviour with saving messages to Queue folder before encrypting and sending them out over the network.

#12 Updated by _adamb 2015-05-03 11:37:52

I’ve repeated the creation of local MH mailbox https://labs.riseup.net/code/issues/8999#note-8 and applied the server side test, and confirm no IMAP server Draft or Queue directory gets written to.

If the FileAdd Mailbox>MH is entered as Persistent/Mail, then Advanced Configuration of the IMAP account changed for Drafts & Queue to their local couterparts, using the same technique as above, I can confirm that in-the-clear emails do not get sent out by claws over IMAP on the network.

As stated elsewhere, that means Drafts and Queue messages are stored in-the-clear, but at least that’s only on the encrypted persistence facility or in ram.

#13 Updated by intrigeri 2015-05-04 04:35:27

  • Status changed from Confirmed to Rejected

During the monthly meeting, we agreed that doing this is useless, given cleartext email will be sent to the server’s Queue folder anyway, unless manual configuration is done.

#14 Updated by BitingBird 2015-08-25 14:06:22

  • Priority changed from Elevated to Low