[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[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.
- To: undisclosed-recipients: ;
- Subject: [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.
- From: "Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>
- Date: Sat, 07 Jul 2018 01:51:09 -0000
- Auto-submitted: auto-generated
- Delivered-to: archiver@xxxxxxxx
- Delivery-date: Fri, 06 Jul 2018 21:51:19 -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>
#26677: 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.
--------------------------------------+--------------------
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:
--------------------------------------+--------------------
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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26677>
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] #26799 [Core Tor/Tor]: dir-spec: specify failure modes for the bandwidth-file-headers vote line
- Next by Author:
Re: [tor-bugs] #26651 [Core Tor/Tor]: Calling event_enable_debug_mode() a second time exits the process
- Previous by thread:
[tor-bugs] #26676 [- Select a component]: [tor-talk] New Report: The State of Internet Censorship in Egypt Maria Xynou maria at openobservatory.org Mon Jul 2 10:58:43 UTC 2018 Previous message (by thread): [tor-talk] Tor check not working or recognize TBB? Next message (by thread): [tor-talk] .onion eat http 413 errors Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hello, Today OONI and Egypt's AFTE published a joint research report on the state of internet censorship in Egypt. * Full report in English: https://ooni.io/documents/Egypt-Internet-Censorship-AFTE-OONI-2018-07.pdf * Full report in Arabic: https://ooni.io/documents/Egypt-Internet-Censorship-AFTE-OONI-2018-07.AR.pdf * Summary of the report in English: https://ooni.io/post/egypt-internet-censorship/ & https://blog.torproject.org/egypt-internet-censorship * Summary of the report in Arabic: https://ooni.io/documents/summary-egypt-internet-censorship-arabic.pdf You may remember that AFTE previously reported on hundreds of websites being blocked in Egypt. OONI and AFTE have now joined forces. We conducted a comprehensive study based on the analysis of OONI Probe measurements collected from multiple local vantage points over the last year and a half. More than 1, 000 URLs presented signs of network interference, 178 of which seem to most likely have been consistently blocked throughout the testing period. The majority of these URLs include media websites, human rights sites, circumvention tools and sites expressing political criticism. More than 100 URLs that belong to media organizations were blocked, even though Egyptian authorities have only officially ordered the blocking of 21 news websites. AFTE interviewed journalists working with Egyptian media organizations whose websites got blocked to examine the impact of censorship. Many Egyptian journalists reported that the censorship has had a severe impact on their work and that some media organizations have been forced to suspend their operations entirely as a result of persisting internet censorship. Egyptian ISPs primarily block sites through the use of Deep Packet Inspection (DPI) technology that resets connections. In some cases, instead of RST injection, ISPs drop packets, suggesting a variance in filtering rules. In other cases, ISPs interfere with the SSL encrypted traffic between Cloudflare's Point-of-Presence in Cairo and the backend servers of sites (pshiphon.ca, purevpn.com and ultrasawt.com) hosted outside of Egypt. Egyptian ISPs also appear to apply "defense in depth" tactics for network filtering by adding extra layers of censorship, making circumvention harder. This is suggested by the blocking of Egypt's Freedom and Justice Party's (FJP) site, which was blocked by two different middleboxes, as well as by the blocking of numerous circumvention tools. Apart from pervasive levels of internet censorship, Egyptian ISPs were found to hijack unencrypted HTTP connections and inject redirects to ads and cryptocurrency mining scripts. We first detected this back in 2016, when we reported that state-owned Telecom Egypt was hijacking unencrypted connections to porn sites and redirecting them to ads. The Citizen Lab significantly expanded upon this research in their latest Sandvine report. Now, following the analysis of thousands of measurements collected from the last year and a half, we have enough evidence to believe that (many) Egyptian ISPs are carrying out an ad campaign. The affected sites are diverse, including the sites of the Palestinian Prisoner Society, the Women's Initiative for Gender Justice, as well as a number of LGBTQI and Israeli sites. Even the sites of the UN were affected by this ad campaign! We will continue to monitor internet censorship in Egypt and around the world. We therefore welcome any feedback you may have. Thanks for reading! All the best, Maria. -- Maria Xynou Research and Partnerships Coordinator Open Observatory of Network Interference (OONI) https://ooni.torproject.org/ PGP Key Fingerprint: 2DC8 AFB6 CA11 B552 1081 FBDE 2131 B3BE 70CA 417E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20180702/d8a79228/attachment.sig> Previous message (by thread): [tor-talk] Tor check not working or recognize TBB? Next message (by thread): [tor-talk] .onion eat http 413 errors Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the tor-talk mailing list
- Next 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
- Index(es):