[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[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
- To: undisclosed-recipients: ;
- Subject: [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
- From: "Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>
- Date: Sat, 07 Jul 2018 01:51:23 -0000
- Auto-submitted: auto-generated
- Delivered-to: archiver@xxxxxxxx
- Delivery-date: Fri, 06 Jul 2018 21:51:36 -0400
- List-archive: <http://lists.torproject.org/pipermail/tor-bugs/>
- List-help: <mailto:tor-bugs-request@lists.torproject.org?subject=help>
- List-id: "auto: Tor bug tracker status mails" <tor-bugs.lists.torproject.org>
- List-post: <mailto:tor-bugs@lists.torproject.org>
- List-subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs>, <mailto:tor-bugs-request@lists.torproject.org?subject=subscribe>
- List-unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-bugs>, <mailto:tor-bugs-request@lists.torproject.org?subject=unsubscribe>
- Reply-to: no-reply@xxxxxxxxxxxxxx, tor-assistants@xxxxxxxxxxxxxx
- Sender: "tor-bugs" <tor-bugs-bounces@xxxxxxxxxxxxxxxxxxxx>
#26678: 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
------------------------------------+-------------------
Reporter: cypherpunks | Owner: n8fr8
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Applications/Orbot | Version:
Severity: Normal | Keywords:
Actual Points: | Parent ID:
Points: | Reviewer:
------------------------------------+-------------------
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
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26678>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
- Prev by Author:
Re: [tor-bugs] #24546 [Core Tor/Tor]: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses
- Next by Author:
Re: [tor-bugs] #26447 [Core Tor/Tor]: Add check-includes to check-local?
- Previous by thread:
[tor-bugs] #26677 [- Select a component]: 2015-03-01 16:11 GMT+09:00 Lodewijk andré de la porte <l at odewijk.nl>: > Of course it's possible. It's way harder than just, you know, regular > tracking! Cloudflare probably has advanced tracking in order to determine > the likelihood of being spam. Cloudflare also gets headers and IP > addresses, in addition to having many access points already betray the user > a little bit. The NSA only has to make sure to listen to every Cloudflare > in and output, and they'll get a ton of decent info. > Oh, I'm sorry, I didn't notice you meant this as tor-specific. That sure makes it a more difficult question. I think there is little information to go on, given many users use a single Tor exit node, and if all goes well that information should be inseparable. NoScript makes it much harder to see what happens on-page, without noscript there's a lot more profiling info (mouse movement, typing rates, scrolling, those sorts of habits). One could investigate if cloudflare can use a tracking-cookie (or similar) to combine visits from a single user, as that would give a lot more profiling opportunities. I assume every request passes through cloudflare, not just the first, so site-usage should give a much better profile than the initial captcha. Once you've found all the side-channels and their "discerning datapoint quantity" you could calculate how often the users of a single tor node are separable. The data is more complex, sadly, for a full observer, as there's far more information to go on. A partial or near-full network observer can combine timing attacks and the like with information gathered here.
- Next by thread:
[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
- Index(es):