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
