[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

• Previous message (by thread): [tor-bugs] #24145 [Core Tor/Tor]: Tor Browser crash on Windows 7
• Next message (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.
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

#26676: [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
--------------------------------------+--------------------
     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

 I am working on a web site that allow users to post big files.

 Because some people don't use javascript, and because I don't want to use
 the
 PHP limit where an error message such as "Sorry uploads are limited to
 1MB"
 appears *after* the user spent many hours uploading a 1GB file, I am
 trying to
 use the good old 413 errors generated by apache LimitRequestBody
 directive, or
 simmilar stuff from nginx.

 It works ok when I use TorBundle to post on my regular
 https://example.com/
 site. I get my nice HTTP 413 error page with custom explanations.

 But when I use the .onion address to do a big post, I always get a generic
 "The connection was reset" message, and no http error code, nor customized
 error message.
 It's a bit like if the browser doesn't even try to read the answer before
 the
 connection with the POST is hang by the server, when the .onion is used.

 Did any one already experience that behaviour?
 Any known work around?

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

• Previous message (by thread): [tor-bugs] #24145 [Core Tor/Tor]: Tor Browser crash on Windows 7
• Next message (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.
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]