15:58:12 <cohosh> #startmeeting tor anticensorship meeting
15:58:12 <MeetBot> Meeting started Thu Mar  4 15:58:12 2021 UTC.  The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:12 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:15 <hanneloresx> hey
15:58:22 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:29 <agix> hey
15:59:25 <cohosh> the snowflake survey announcement was from last week
15:59:43 <cohosh> last i heard from dunqan we'd gotten a lot of responses
16:00:28 <dunqan> hello! yup, let me see if I can get a live update...
16:00:37 <cohosh> :D
16:00:52 <dcf1> what is the plan for processing and interpreting survey responses?
16:01:03 <dunqan> 540 completions so far :)
16:01:26 <dunqan> (I haven't checked the individual responses for validity though)
16:01:30 <cohosh> i'm not sure what the plan is, but i'm willing to help
16:01:44 <cohosh> 540 is a lot to go through
16:02:14 <dunqan> yes, we're going to have to do some fancy query-writing for the TB user survey anyway so I'm sure we can help out with Snowflake too
16:02:40 <dunqan> My initial thoughts is we'll split up the responses by keywords and response length and then maybe go from there
16:02:57 <dunqan> the initial demographics are easy to view online though
16:03:27 <cohosh> cool
16:03:56 <cohosh> should we close the survey?
16:04:32 <dunqan> Yup we can do – I'd like to wait until the next alpha release so we can close the survey and take down the banner simultaneously
16:04:42 <dunqan> however that won't be until 23-03-2021
16:04:57 <dunqan> I've asked the browser team to remove the banner for the TB user survey then too
16:04:59 <cohosh> okay sounds good
16:05:17 <dunqan> great! I'll let them know :)
16:06:03 <cohosh> thanks dunqan!
16:06:14 <dunqan> no prob!
16:06:42 <cohosh> next on the agenda is discussing a digital tor censorship library
16:07:37 <cohosh> at the moment the place to go to find writeups of tor blocking events is the metrics timeline
16:07:50 <cohosh> which due to the trac migration is a bit hard to find
16:09:17 <cohosh> the question here is whether it's worth it to have a dedicated central place somewhere on torproject.org to put writeups of censorship events
16:09:46 <cohosh> specifically Tor censorship events
16:10:14 <hanneloresx> was there something like this on the old wiki before gitlab?
16:10:15 <dcf1> There used to be a "Censorship analysis" component on Trac, which is here now (I know cohosh knows because #40002 is there): https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues?state=all
16:10:41 <dcf1> There also used to be a "block" keyword on Trac that I would tag blocking events with: https://gitlab.torproject.org/legacy/trac/-/issues?label_name[]=block
16:11:26 <cohosh> yeah, i also wonder how accessible that is given these discussions are in various places in gitlab. this repository is also not so easy to stumble across
16:11:27 <dcf1> hanneloresx: the metrics timeline is now at https://gitlab.torproject.org/tpo/metrics/timeline, but it's not about censorship exclusively
16:11:36 <dcf1> it also only has short description and links, not full writeups
16:12:02 <dcf1> I'm planning to publish a blog post about the metrics timeline: https://lists.torproject.org/pipermail/metrics-team/2021-February/001186.html
16:12:19 <dcf1> In fact it's already in draft form in the blog, just not published yet
16:12:49 <cohosh> dcf1: nice!
16:13:03 <dcf1> but yeah, these repos/tags kind of died after moving to gitlab
16:14:44 <dcf1> and while I understand the technical reasons for it, it's a bummer that there are 2 versions of every old ticket, and the "Legacy/Trac" version has tags but the "Anti-censorship/censorship-analysis" version does not
16:15:02 <dcf1> https://gitlab.torproject.org/legacy/trac/-/issues/28898 https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/28898
16:15:16 <cohosh> yep >.<
16:16:07 <dcf1> OONI has a big repository of censorship analyses, also somewhat confusingly divided between blog posts and reports: https://ooni.org/blog/ https://ooni.org/reports/
16:16:37 <dcf1> But OONI is not exclusively focused on Tor blocking
16:17:45 <dcf1> And a long time ago there was https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki, which I think was a similar effort at making a library of censorship events, but it hadn't been maintained for a long time
16:18:21 <cohosh> i suppose we could coordinate with OONI in writing up some of the results from the censorship-analysis repository
16:19:12 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/6149#note_2600762 "'Censorship-timeline'" for Tor
16:19:21 <dcf1> "Opened 8 years ago by Philipp Winter"
16:20:05 <cohosh> haha wow
16:20:32 <hanneloresx> i think this censorship wiki was what i was thinking of, but looks like the links are mostly blank now  https://gitlab.torproject.org/legacy/trac/-/wikis/doc/OONI/censorshipwiki
16:21:26 <dcf1> hanneloresx: ah yes, that's what I was just looking for. Yeah, it looks like all the page titles with '/' are broken.
16:22:06 <cohosh> i do think ideally it would be nice to have a webpage that links to a wiki or gitlab repositories/issues that is more easily accessible
16:22:13 <cohosh> but that is also hard to maintain
16:22:23 <dcf1> https://web.archive.org/web/20190727033454/https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki
16:22:24 <cohosh> wikis are great because they can be maintained by a large community
16:23:41 <hanneloresx> or even a web page that lists all the existing repos/wikis that we just dug up
16:24:19 <cohosh> yeah, i would not have been able to find all of these links
16:25:32 <cohosh> these broken wikis are really frustrating
16:27:21 <cohosh> hmm
16:28:37 <cohosh> i might talk to hiro about how difficult it would be to get torproject.org page for censorship reports/timeline
16:29:06 <hiro> we can no problems
16:29:12 <cohosh> like censorship.torproject.org or circumvention.torproject.org
16:29:20 <cohosh> okay cool :)
16:29:31 <hiro> you only have to pick if you are ok with a lektor page
16:29:31 <dcf1> I just updated https://gitlab.torproject.org/tpo/metrics/timeline#other-data-sources with the links we have been talking about
16:29:38 <hiro> or you want a hugo page like status.tpo
16:29:39 <cohosh> thanks dcf1
16:30:16 <cohosh> and then i'll send a mail to one of our mailing lists with a proposal on what to put on that page
16:32:14 <cohosh> anything else for discussion today?
16:32:28 <dcf1> also there is https://gitlab.torproject.org/tpo/anti-censorship/state-of-censorship, not very extensive
16:32:58 <cohosh> hiro: i might reach out to you about what you think of this as well XD
16:32:59 <ggus> i have a user feedback from china. but we can discuss in other channel
16:33:13 <hiro> ok cohosh sure
16:34:02 <cohosh> ggus: do you want to bring it up in the meeting today?
16:34:22 <ggus> yes
16:34:40 <cohosh> okay go for it :)
16:35:21 <ggus> so, some days ago i asked this person to test tor browser alpha with snowflake in china mainland as they are already using different proxy/vpns/anticensorship tools.
16:35:30 <ggus> it took 3 minutes to connect and worked
16:35:59 <ggus> but today they are reporting that meek-azure, snowflake and other ways to circumvent is not working
16:36:39 <cohosh> hm okay
16:36:58 <ggus> i've checked metrics.tpo and it looks something is happening. i will ask them to try a private obfs4
16:37:12 <cohosh> thanks ggus
16:39:07 <cohosh> we'll have to look into it more after the meeting
16:39:36 <ggus> ok :)
16:40:30 <cohosh> should we move on to the reading group?
16:41:22 <cohosh> i forgot to reach out to the censored planet group to see if they could join
16:42:13 <dcf1> I mentioned it to roya and she said that agix had contacted them, I think
16:42:41 <cohosh> oh nice, are they here today?
16:43:34 <cohosh> also did anyone prepare a summary?
16:45:18 <cohosh> i can paste a quick one if not
16:45:45 <cohosh> <summary>
16:46:19 <cohosh> for a few months in the summer of 2019, Kazakhstan performed a mitm attack on HTTPS connections to some websites
16:46:45 <cohosh> this was carried out by forcing users to install a root CA in order to access these sites
16:47:33 <cohosh> the messaging around this installation informed users that the installation was meant to "inhance security"
16:48:23 <cohosh> the domains targeted were mostly social networking sites
16:49:15 <cohosh> through more indepth tests, the researchers found that the blocking was triggered by these sites appearing in the TLS SNI extension
16:50:24 <cohosh> and only occurred if the traffic passed through ASN9198
16:50:40 <cohosh> it's since been turned off but unknown whether they will turn it back on again
16:50:46 <cohosh> </summary>
16:51:05 <dcf1> since then it has been turned on once again
16:51:11 <dcf1> https://censoredplanet.org/kazakhstan/live
16:51:26 <dcf1> 2020-12-06, and stopped after less than a day
16:51:46 <dcf1> https://bugzilla.mozilla.org/show_bug.cgi?id=1680927
16:53:06 <cohosh> that's recent
16:53:55 <dcf1> A point that was interesting to me:
16:54:32 <dcf1> "Although nobody was forced to install the Qaznet root CA, most of the affected sites employed Strict Transport Security, so users who did not were unable to access these sites at all, even by clicking through security warnings." p.2
16:55:55 <dcf1> Another big question I have, unanswered as far as I know, is how many users in Kazakhstan actually downloaded and installed the cert?
16:56:09 <dcf1> My thinking is:
16:56:20 <cohosh> hmm, so strict transport security led users to take steps to make the mitm attempt less visible
16:56:54 <dcf1> Even in, say, a business with an IT department, it would be hard to get all the employees to install a TLS cert, if they had to do it themselves
16:57:54 <dcf1> It's definitely possible for a business with a high degree of central IT management, but for users with diverse devices that they administrate themselves, I think you would have a hard time getting 100% installation even with technically trained people
16:58:54 <dcf1> So in KZ the gov't issued an order, which the ISPs relayed, that every Internet user needed to follow a difficult technical procedure, and the benefits or drawbacks of doing so were not made clear
16:59:16 <cohosh> huh
16:59:37 <dcf1> So part of my mind wonders if the MITM experiment failed in part because it's just hard to order people to do something like this -- many, I'm sure, could not comply even if they wanted to
16:59:48 <cohosh> this is probably a lot easier if you can control browser software
17:00:03 <cohosh> (do browsers still maintain their own root CA lists?)
17:00:18 <Ram> dcf1: In my opinion the process isn't too technically difficult though. To access a website, click a link, your device will ask you whether you want to install the cert, click yes, and you're basically good to go
17:01:03 <dcf1> It would be like giving an order: "you shall not use encryption". Most people who use encryption don't know they are using encryption, they would not even know what to do to stop
17:02:02 <cohosh> aha okay so the strict transport security thing meant that these websites were effectively just bloked
17:02:06 <cohosh> *blocked
17:02:07 <dcf1> Ram: still, though, it's like usability testing. You give what you think are clear instructions, and still people will interpret them reasonably but in ways that cause the procedure to fail, in ways you never anticipated
17:02:20 <cohosh> because the easiest way to accept the mitm is to click through the security warnings
17:03:39 <dcf1> Ram, do you have an opinion on why the MITM experiment lasted as long (as short) as it did?
17:03:58 <Ram> dcf1: Yeah, you're right, we tried very hard to see if we could get an estimate of the number of users who actually installed the certificate, but the MitM was on and off so quick that we couldn't find any data
17:04:49 <dcf1> cohosh: yeah and ironically they would have been safer if they had just been able to click through each time, because while they would still be vulnerable to interception those times, they wouldn't have the cert installed afterward
17:05:01 <Ram> cohosh: the strict transport security was a byproduct I think.
17:06:53 <Ram> dcf1: No clear idea on the duration of the interception, but their official announcement mentioned that all of their testing was complete, and we did see that they changed minor details about the MitM (such as validity period of the certificate) during the period. I suppose its a combination of retaliation and bad press + possibly not being able to cover as much of the network as they wanted to
17:07:30 <cohosh> i'm also curious about how this scales on their end for intercepting more sites
17:08:38 <dcf1> My read on the official announcement of the end of the test was that they were clearly just trying to save face.
17:09:22 <dcf1> There are some translated tweets by the President here: https://github.com/net4people/bbs/issues/6#issuecomment-519131315
17:09:53 <Ram> cohosh: Since they were using SNI to select the connections they wanted to intercept, I suppose scaling up would be difficult depending on how much traffic their interception system would handle. There's also the question of what the MitM is planning on doing with the data. If they're storing it, then there is a storage problem.
17:11:41 <dcf1> But it seems like they have been wanting to do this for a long time. "In November 2015, Kazakhstan amended its communications law to require ISPs to adopt a “national security certificate” for all traffic to or from foreign destinations, with the intent of allowing the government to decrypt the communication."
17:11:41 <Ram> dcf1: I think you're right, but to some extent, I believe that this was a pilot, since there was only a select portion of the network that was targeted. They recently also performed the same testing/trial over a day or so.
17:11:46 <dcf1> https://www.dentons.com/en/insights/alerts/2015/december/30/security-certificate-of-the-republic-of-kazakhstan
17:13:54 <Ram> Yeah they submitted a request to Mozilla to add their CA to their trusted store: https://groups.google.com/g/mozilla.dev.security.policy/c/wnuKAhACo3E/m/cpsvHgcuDwAJ
17:14:55 <dcf1> What about key pinning? Browser use CA certs, but I imagine that e.g. the Facebook app uses TLS with its own pinned certificates. In that case, MITM would break the app, with no way for the user to override it.
17:17:00 <cohosh> heh and it is pretty difficult to access sites that have apps with a browser on a mobile phone these days
17:17:32 <dcf1> I also liked this part: "We tried contacting some targeted services for information about how many users were affected, but none were able to share their data."
17:17:45 <Ram> I don't think key pinning is widely adopted, and I suppose there need to be workarounds (to deal with the benign case of security software that encrypts/decrypts all connections).
17:17:55 <dcf1> I really wonder what happened internally at e.g. Google and Mail.ru, if they were able to detect compromised logins and what they did about it.
17:18:55 <dcf1> Ram: hmm, my impression was just the opposite, that apps from the big companies tend to pin their own keys and not use the OS truststore. That's just my impression though, from reading some reverse engineering posts.
17:20:03 <cohosh> i'm guess their interception would be more technically difficult without being able to read the SNI?
17:20:22 <cohosh> but not impossible, especially with a small list of intercepted sites
17:20:48 <cohosh> since they could do a reverse DNS lookup of IPs or just maintain a mapping of domains to IP addresses
17:20:56 <cohosh> although maybe some services will be more difficult than others
17:21:19 <dcf1> that's a good point, I hadn't thought of that
17:21:22 <cohosh> i'm not very familiar with how google manages IPs and certs
17:22:05 <Ram> dcf1: Ahh okay, I always thought there would be a fallback, since interception for security is quite common: https://jhalderm.com/pub/papers/interception-ndss17.pdf
17:23:04 <dcf1> This is good work, Ram
17:23:14 <cohosh> yeah thanks for joining us!
17:23:41 <dcf1> You had a Russian speaker on your team. Did you find the language expertise useful, or is Kazakh too different from Russian?
17:24:22 <Ram> +cohosh: You're right, I think it depends on whether the services they wanted to target are hosted on CDNs. In that case, multiple popular domains may be hosted on the same IP, and would increase traffic that the MitM captured
17:24:23 <dcf1> I'm wondering because these kinds of studies benefit from whatever degree of local expertise you can get, and I'm thinking of ways that future research can help cultivate that
17:24:57 <cohosh> i wonder if they will block ESNI because of this
17:25:05 <dcf1> I think the point cohosh is making is, how does the MITM box know what fake certificate to present, if it doesn't have SNI
17:25:15 <cohosh> yeah
17:26:32 <dcf1> In the past, I have forwarded some reports about Tor blocking in KZ to someone linked to the Freedom House report, but that's the most connection I have
17:26:51 <dcf1> It would be so great to be able to correspond with e.g. local journalists in cases like this (if it can be done safely)
17:26:52 <Ram> Thanks! I think darkk_s expertise was crucial for this project, especially language, background knowledge, connections, and technical expertise! I'm definitely behind the idea of more local expertise, as that is invaluable
17:28:09 <cohosh> +1
17:28:40 <Ram> dcf1, cohosh: yeah, in that case, I think relying on the IP (and maybe using previous connection statistics, if available) would be the only way to identify connections to intercept.
17:32:34 * cohosh waits to see if there is any more discussion before closing the meeting
17:33:46 <cohosh> alright i'll end it here, thanks everyone!
17:33:54 <cohosh> #endmeeting