Re: [Tails-dev] TorBirdy: first impressions

Delete this message

Reply to this message
Autore: Jacob Appelbaum
Data:  
To: intrigeri
CC: tails-dev, Sukhbir Singh
Oggetto: Re: [Tails-dev] TorBirdy: first impressions
On 06/20/2012 06:24 PM, intrigeri wrote:
> 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.


Thanks!

>
> 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'll file an ITP when I'm ready - I'll try to remember to do the above.

>
>>> 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.
>


Yeah, I agree.

> 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.
>


I think zero is the right choice.

>> 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 ;)


Well - in theory, you can have a server listening on port 0. In
practice, well, I think no one does it.

>
> 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


I'm not sure, I bet it would work. I could also do something like
127.0.0.2 or something similar.

>
>> 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.

>


This.

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

>


This.

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


Also the mail servers who receive the message.

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


All three above - especially if the mail servers in question do not use
TLS or STARTTLS or if the user is using 0.2.2.x Tor without the Isolated
Streams work.

All the best,
Jake