Re: [Tails-dev] TorBirdy: first impressions

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: Jacob Appelbaum
CC: tails-dev, Sukhbir Singh
Subject: Re: [Tails-dev] TorBirdy: first impressions
Hi,

Jacob Appelbaum wrote (20 Jun 2012 21:21:54 GMT) :
> I plan to package it for Debian in the next weeks.


Great news.

> Would you be willing to inspect my package?


Sure.

I suggest filing a RFS bug, and x-debbugs-cc it to me and dkg, who was
interested too, and has more experience than me in packaging XUL
extensions. I bet the maintainer of torbutton in Debian could be
interested too.

>> I don't understand why 127.0.0.1:8118 should be equivalent to "fail
>> closed": there may very well be a non-torifying proxy (such as
>> Privoxy) behind this port.


> There is no way to fail closed, sadly - without well, something there. :(


I beg your pardon for insisting, but using the default Privoxy port
here looks to me like playing with fire, and hoping not to get burnt.

If there is really no way to fail closed,
I'd rather see there, instead of the risky 8118,
a port where there are significantly less chances to have
a non-torifying proxy listening, such as 53 or 9418.

> In theory, I could put port 0 and that should fail almost always...


I'm curious why *almost* always, but perhaps I don't want to know
about the Thunderbird internals ;)

Wouldn't any of the following tricks work?

  - set 0.0.0.0 as proxy IP
  - set a port number that is larger than the max. legal TCP port
    number


> However, I think that it is absolutely imperative to use that option
> with gpg and thunderbird. Otherwise, we leak a cryptographic
> identity, directly, not indirectly. :(


I'm not sure what exactly you mean by leaking a cryptographic
identity, but perhaps it's because the last time I have read your
threat model was months ago.

I see two major problems with the default GnuPG behaviour:

  1. if an encrypted message is Bcc'd to several recipients,
     every recipient gets to know which other public OpenPGP
     keys the message was encrypted to.


  2. whoever can snoop along the email routing path can link recipient
     email addresses with OpenPGP public key IDs.


3. < insert here what I'm missing :) >

To clarify, which one is the cryptographic identity leak that makes it
absolutely necessary to switch to the --throw-keyids mode?

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc