[tor-bugs] #26679 [- Select a component]: Hi, A good try at solving the problem but one which requires all mail server to get onboard in the presence of established alternatives. The proof of work system you propose doesn't address the problem of tampered email contents or if the email was wanted. It *might* prevent exits from being a source of blacklisting at exchanges. The suppression lists to which you refer aren't generated based on IP (at least not primarily). They're generated based on proof of sender authorization, proof of contents being untampered, and sender reputation (complaint, reject). I'm not certain about where you're sending your email from. > we're encountering a lot of issues related to > sending of email notification behind Tor, with > almost any email provider. Are you trying to send email from the GlobaLeaks domain? At the very least it means all mail servers on the internet would need to accept your proof-of-work as evidence of not being spam and not being tampered. Such emails could still be spam. The emails can still be tampered with by a misconfiguration of sending client (using TLS Wrapper instead of STARTTLS and being forced to fallback to insecure communications by traffic manipulation). In the end it takes more than proof-of-work for public mail servers online. They don't care if the email takes work to produce, they care about if the email is wanted in the first place and if the contents are as originally sent. They're motivated by $$$ and their reputation. If you're trying to send emails behind Tor from a domain you control you should use DKIM. Email servers online can then verify the email was both authorized and un-tampered during transit. Using DKIM

• Previous message (by thread): [tor-bugs] #26678 [Applications/Orbot]: Hash: SHA256 Hi Thanks for running a bridge. If you want to bind the same pluggable transport protocol to ipv4 and ipv6 (2 IP:port) I recommend one line for each pluggable transport, as follows: ServerTransportPlugin obfs2, obfs3 exec /usr/bin/obfsproxy managed ServerTransportListenAddr obfs2 [::]:42862 ServerTransportListenAddr obfs3 [::]:49991 This [::] will open ports on both ipv4 and ipv6 (all interfaces if you have multiple - like more IP addresses), if you have a dual stack server. I recommend you not to use obfs2, since it's too old. Better make an obfs3 and obfs4 bridge. For this, you can install the obfs4proxy package from torproject.org deb: echo "deb http://deb.torproject.org/torproject.org obfs4proxy main" >> /etc/apt/sources.list apt-get update && apt-get -y install obfs4proxy Substitute in your torrc /usr/bin/obfsproxy with /usr/bin/obfs4proxy Note this obfs4proxy is able to do both obfs3 and obfs4 pluggable transport, so you don't need the old python based obfsproxy package. This one is written in Golang. It cannot do obfs3. Tip: obfs4proxy package makes it easier for you to run pluggable transports on low (usually reserved) ports, like 80, 443 for our good fellows behind firewalls which allow only few ports. For this you can install libcap2-bin package form apt-get and use that. On 3/1/2015 10:43 PM, MegaBrutal wrote: > Could someone please help me with this? > > > 2015-02-19 20:39 GMT+01:00 MegaBrutal <megabrutal at gmail.com>: > >> Hi, >> >> I want Obfsproxy to listen on both IPv4 and IPv6 interfaces by >> using the following lines in torrc: >> >> ServerTransportPlugin obfs2, obfs3 exec /usr/bin/obfsproxy >> managed ServerTransportListenAddr obfs2 0.0.0.0:42862 >> ServerTransportListenAddr obfs3 0.0.0.0:49991 >> ServerTransportListenAddr obfs2 [2001:xxxx::63:7572:6c79]:42862 >> ServerTransportListenAddr obfs3 [2001:xxxx::63:7572:6c79]:49991 >> >> I noticed, only the first line gets interpreted for each >> Obfsproxy protocol. I can force to listen only on IPv6 by >> commenting out the lines for IPv4, but I'd prefer to have a >> dual-stack bridge. >> >> I don't remember having this behaviour the first time I installed >> an Obfsproxy bridge. If I remember correctly, it worked >> previously, but meanwhile it is broken. >> >> Anyway, I just noticed, there is a new protocol, obfs4, but I >> don't know anything about it. Should I adopt this new protocol? >> If so, how can I do that? Is it already available in the DEB >> repository at http://deb.torproject.org/torproject.org? What is >> the minimal Ubuntu release for which it is available? >> >> >> Regards, MegaBrutal >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJU84mLAAoJEIN/pSyBJlsRkZ8IAKdw8+Qaof242AZlRiorm+XT i2PIIkxkRA/hx34+ARbxZAvi9Ad7Gc/RHZvnmVwjNtylCFcyArt0pMUmLCcifUR/ WjCsvBf8Wg/xOHmtaU8sd/YwcfL5oB2tItrv2/1iX/kxOGF5qh+W1JptWvJC0VZL B703MC7Y7f+yadjmhmzNJtYoQKrykeNenhrOSvDvjlcAGh/sZ1n8aJ
• Next message (by thread): [tor-bugs] #26680 [- Select a component]: t that hidden service for as long as possible, so there's still going to be long-term storage somewhere in the chain. Putting it in the directories would mean that as many client as possible could be notified of the hidden service's revocation, even long after the initial revocation is published, in cases where the hidden service operator is unwilling or unable to continue to announce the revocation. Consider that for long-validity revocations, there would actually be less load placed on the network than for a regular short term descriptor. The hidden service would not need to frequently publish a new descriptor about itself. Once a client knows a hidden service is revoked, they do not need to ask about it again. Old revocations could conceivably be stored to disk. The need to revoke hidden service keys is real. It doesn't take long to dig up anecdotes and news reports of .onion sites that have been compromised, but even when detected there is no reliable way for a legitimate hidden service operator to notify the network his service cannot be trusted. Detecting if someone has stolen your hidden service key is easy and is hijacking your traffic is easy, you only have to look out for hidden service descriptors for your service that you did not publish, but there is currently not much that can be done with this information. The hidden service operator could include a notice on his hidden website warning of the compromise and telling users to divert to a different .onion address, but a user has no way of knowing if that warning was published by the attacker and directs to another malicious site. On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote: > Alternatively the original hidden service operator could publish hidden > service descriptors with a normal validity period which contain a > revocation field. A HSDir which receives a descriptor containing the > revocation could replace the (potentially malicious) HS descriptor > stored in its cache. > > A client could be show an alert that the hidden service they are > attempting to access has been compromised
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

#26679: Hi,  A good try at solving the problem but one which requires all mail
server  to get onboard in the presence of established alternatives.  The
proof of work system you propose doesn't address the  problem of tampered
email contents or if the email was wanted. It *might* prevent exits from
being a  source of blacklisting at exchanges. The suppression lists to
which you refer aren't generated based on IP (at least not primarily).
They're generated based on proof of sender authorization, proof of contents
being untampered, and sender reputation (complaint, reject). I'm not
certain about where you're  sending your email from.  > we're encountering
a lot of issues related to  > sending of email notification behind Tor,
with  > almost any email provider.  Are you trying to send email from the
GlobaLeaks domain?  At  the very least it means all mail servers on the
internet would need to  accept your proof-of-work as evidence of not being
spam and not being  tampered. Such emails could still be spam. The emails
can still be  tampered with by a misconfiguration of sending client (using
TLS Wrapper  instead of STARTTLS and being forced to fallback to insecure
communications by traffic manipulation). In the end it takes more than
proof-of-work for public mail servers online. They don't care if the  email
takes work to produce, they care about if the email is wanted in  the first
place and if the contents are as originally sent. They're  motivated by $$$
and their reputation.  If you're trying to send  emails behind Tor from a
domain you control you should use DKIM. Email  servers online can then
verify the email was both authorized and  un-tampered during transit. Using
DKIM
--------------------------------------+--------------------
     Reporter:  cypherpunks           |      Owner:  (none)
         Type:  defect                |     Status:  new
     Priority:  Medium                |  Milestone:
    Component:  - Select a component  |    Version:
     Severity:  Normal                |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |   Reviewer:
--------------------------------------+--------------------
 Hi,

 A good try at solving the problem but one which requires all mail
 server  to get onboard in the presence of established alternatives.

 The proof of work system you propose doesn't address the  problem of
 tampered email contents or if the email was wanted. It *might* prevent
 exits from being a  source of blacklisting at exchanges. The
 suppression lists to which you refer aren't generated based on IP (at
 least not primarily). They're generated based on proof of sender
 authorization, proof of contents being untampered, and sender
 reputation (complaint, reject). I'm not certain about where you're
 sending your email from.

 > we're encountering a lot of issues related to
 > sending of email notification behind Tor, with
 > almost any email provider.

 Are you trying to send email from the GlobaLeaks domain?

 At  the very least it means all mail servers on the internet would
 need to  accept your proof-of-work as evidence of not being spam and
 not being  tampered. Such emails could still be spam. The emails can
 still be  tampered with by a misconfiguration of sending client (using
 TLS Wrapper  instead of STARTTLS and being forced to fallback to
 insecure  communications by traffic manipulation). In the end it takes
 more than  proof-of-work for public mail servers online. They don't
 care if the  email takes work to produce, they care about if the email
 is wanted in  the first place and if the contents are as originally
 sent. They're  motivated by $$$ and their reputation.

 If you're trying to send  emails behind Tor from a domain you control
 you should use DKIM. Email  servers online can then verify the email
 was both authorized and  un-tampered during transit. Using DKIM

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26679>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

• Previous message (by thread): [tor-bugs] #26678 [Applications/Orbot]: Hash: SHA256 Hi Thanks for running a bridge. If you want to bind the same pluggable transport protocol to ipv4 and ipv6 (2 IP:port) I recommend one line for each pluggable transport, as follows: ServerTransportPlugin obfs2, obfs3 exec /usr/bin/obfsproxy managed ServerTransportListenAddr obfs2 [::]:42862 ServerTransportListenAddr obfs3 [::]:49991 This [::] will open ports on both ipv4 and ipv6 (all interfaces if you have multiple - like more IP addresses), if you have a dual stack server. I recommend you not to use obfs2, since it's too old. Better make an obfs3 and obfs4 bridge. For this, you can install the obfs4proxy package from torproject.org deb: echo "deb http://deb.torproject.org/torproject.org obfs4proxy main" >> /etc/apt/sources.list apt-get update && apt-get -y install obfs4proxy Substitute in your torrc /usr/bin/obfsproxy with /usr/bin/obfs4proxy Note this obfs4proxy is able to do both obfs3 and obfs4 pluggable transport, so you don't need the old python based obfsproxy package. This one is written in Golang. It cannot do obfs3. Tip: obfs4proxy package makes it easier for you to run pluggable transports on low (usually reserved) ports, like 80, 443 for our good fellows behind firewalls which allow only few ports. For this you can install libcap2-bin package form apt-get and use that. On 3/1/2015 10:43 PM, MegaBrutal wrote: > Could someone please help me with this? > > > 2015-02-19 20:39 GMT+01:00 MegaBrutal <megabrutal at gmail.com>: > >> Hi, >> >> I want Obfsproxy to listen on both IPv4 and IPv6 interfaces by >> using the following lines in torrc: >> >> ServerTransportPlugin obfs2, obfs3 exec /usr/bin/obfsproxy >> managed ServerTransportListenAddr obfs2 0.0.0.0:42862 >> ServerTransportListenAddr obfs3 0.0.0.0:49991 >> ServerTransportListenAddr obfs2 [2001:xxxx::63:7572:6c79]:42862 >> ServerTransportListenAddr obfs3 [2001:xxxx::63:7572:6c79]:49991 >> >> I noticed, only the first line gets interpreted for each >> Obfsproxy protocol. I can force to listen only on IPv6 by >> commenting out the lines for IPv4, but I'd prefer to have a >> dual-stack bridge. >> >> I don't remember having this behaviour the first time I installed >> an Obfsproxy bridge. If I remember correctly, it worked >> previously, but meanwhile it is broken. >> >> Anyway, I just noticed, there is a new protocol, obfs4, but I >> don't know anything about it. Should I adopt this new protocol? >> If so, how can I do that? Is it already available in the DEB >> repository at http://deb.torproject.org/torproject.org? What is >> the minimal Ubuntu release for which it is available? >> >> >> Regards, MegaBrutal >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJU84mLAAoJEIN/pSyBJlsRkZ8IAKdw8+Qaof242AZlRiorm+XT i2PIIkxkRA/hx34+ARbxZAvi9Ad7Gc/RHZvnmVwjNtylCFcyArt0pMUmLCcifUR/ WjCsvBf8Wg/xOHmtaU8sd/YwcfL5oB2tItrv2/1iX/kxOGF5qh+W1JptWvJC0VZL B703MC7Y7f+yadjmhmzNJtYoQKrykeNenhrOSvDvjlcAGh/sZ1n8aJ
• Next message (by thread): [tor-bugs] #26680 [- Select a component]: t that hidden service for as long as possible, so there's still going to be long-term storage somewhere in the chain. Putting it in the directories would mean that as many client as possible could be notified of the hidden service's revocation, even long after the initial revocation is published, in cases where the hidden service operator is unwilling or unable to continue to announce the revocation. Consider that for long-validity revocations, there would actually be less load placed on the network than for a regular short term descriptor. The hidden service would not need to frequently publish a new descriptor about itself. Once a client knows a hidden service is revoked, they do not need to ask about it again. Old revocations could conceivably be stored to disk. The need to revoke hidden service keys is real. It doesn't take long to dig up anecdotes and news reports of .onion sites that have been compromised, but even when detected there is no reliable way for a legitimate hidden service operator to notify the network his service cannot be trusted. Detecting if someone has stolen your hidden service key is easy and is hijacking your traffic is easy, you only have to look out for hidden service descriptors for your service that you did not publish, but there is currently not much that can be done with this information. The hidden service operator could include a notice on his hidden website warning of the compromise and telling users to divert to a different .onion address, but a user has no way of knowing if that warning was published by the attacker and directs to another malicious site. On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote: > Alternatively the original hidden service operator could publish hidden > service descriptors with a normal validity period which contain a > revocation field. A HSDir which receives a descriptor containing the > revocation could replace the (potentially malicious) HS descriptor > stored in its cache. > > A client could be show an alert that the hidden service they are > attempting to access has been compromised
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]