[liberationtech] Signal ignores proxy censorship vulnerability, bans researchers
Harry Halpin
hhalpin at ibiblio.org
Thu Feb 25 03:19:00 CET 2021
Again, if Sergey - who seems to be a perfectly nice Ph.D. student - wants
to fix TLS, that's fine. I would support fixes to TLS as would any sensible
person, including Moxie.
But that's not Signal's problem - TLS bugs are a lower-level network level
protocol whose bugs Signal inherits when it tries to use TLS. Sergey should
approach the TLS 1.3 Working Group at the IETF, no try to garner attention
for himself via media releases over his github comments. This reminds me of
the Israeli "security" firm that claimed they had "hacked" Signal by simply
accessing the keys in the phone, which can be done to *any* app on phone
that has a rootkit that doesn't use some-yet-not-really-working secure
enclave.
There are literally *no* server that is not susceptible to active probes
and machine-learning based traffic analysis attacks. If Sergey had a kind
of solution that actually did what Adam claimed it did "anti-censorship
tools that actually work at scale in censored regions are not susceptible
to active probes" then all of China would be using it. As it doesn't exist,
people aren't using them.
Censorship is a very hard problem, which is why Shava is basically right.
Cutting-edge usable tech here is still I believe obfs4proxy, and it's
well-known defeatable by nation-state level adversaries.
I do support the usage of Tor, and Tor also is susceptible to the precise
same kinds of attacks Signal is and thus doesn't work in China, Iran, and
many other places. Furthermore, it's not resistant to NSA-style traffic
analysis. But it is by better than most shady VPNs and proxies, and I hope
people use it where their nation-state hasn't starting censoring it yet.
Same with Signal. Most VPNs that work in these countries work insofar as
they are easily susceptible to attacks (i.e. see Moxie's older work on bugs
in PPTP or the myriad of authentication issues facing OpenVPN,
fingerprinting of Wireguard...). Again, more work is needed but aim work in
productive way, not cheap media hit pieces on Signal or Tor.
yours,
harry
On Thu, Feb 25, 2021 at 2:49 AM Shava Nerad <shava23 at gmail.com> wrote:
> Active probes are a problem to Tor bridges too, and have been for years.
> Tor is, by design, easily blocked by blocking the directory servers, to
> lessen abuse of the network to grief people. Bridges allow Tor, despite
> this, to be used as a circumvention tech inside countries where the
> directory servers are blocked (mostly).
>
> My understanding is that this is something where you just make the bridges
> volatile and hard to notice because they change so frequently and are
> individually assigned. As obfuscation that's worked fairly well for
> countries where you have to bridge into the directory servers for Tor.
>
> Is this something like what you are talking about? I honestly haven't
> looked into the papers -- the weather is very unstable at this point in
> California's spring and it's been giving me migraines, tbh.
>
> It's been something of an arms race for years:
>
> https://blog.torproject.org/learning-more-about-gfws-active-probing-system
>
> Although many users use VPNs to circumvent the Great Firewall of China,
> many Internet connections are now subject to deep packet inspection
> <https://en.wikipedia.org/wiki/Deep_packet_inspection>, in which data
> packets are looked at in detail. Many VPNs have been blocked using this
> method. Blogger Grey One suggests users trying to disguise VPN usage
> forward their VPN traffic through port 443 because this port is also
> heavily used by web browsers for HTTPS connections. However, Grey points
> out this method is futile against advanced inspection.[180]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-180>
> Obfsproxy[181]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-obsf-181> and
> other pluggable transports do allow users to evade deep-packet inspection.
> [182]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-182>
>
> The Tor <https://en.wikipedia.org/wiki/Tor_(anonymity_network)> anonymity
> network was and is subject to partial blocking by China's Great Firewall.
> [183]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-183>
> [184]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-184>
> [185]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-185>
> [186]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-186> The
> Tor website is blocked when accessed over HTTP
> <https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol> but it is
> reachable over HTTPS <https://en.wikipedia.org/wiki/HTTP_Secure> so it is
> possible for users to download the Tor Browser Bundle.[187]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-HowTorIsBlockingChina-187> The
> Tor project also maintains a list of website mirrors in case the main Tor
> website is blocked.[188]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-188>
>
> The Tor network maintains a public list of approximately 3000 entry
> relays; almost all of them are blocked.[187]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-HowTorIsBlockingChina-187> In
> addition to the public relays, Tor maintains bridges which are non-public
> relays.[189]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-189> Their
> purpose is to help censored users reach the Tor network. The Great Firewall
> scrapes nearly all the bridge IPs distributed through
> bridges.torproject.org and email. According to Winter's research paper
> published in April 2012, this blocking technique can be circumvented by
> using packet fragmentation or the Tor obfsproxy bundle in combination with
> private obfsproxy bridges.[181]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-obsf-181>
> [187]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-HowTorIsBlockingChina-187> Tor
> Obfs4 bridges still work in China as long as the IPs are discovered through
> social networks or self-published bridges.[190]
> <https://en.wikipedia.org/wiki/Internet_censorship_in_China#cite_note-190>
> Tor now primarily functions in China using meeks which works via
> front-end proxies hosted on Content Delivery Networks (CDNs) to obfuscate
> the information coming to and from the source and destination, it is a type
> of pluggable transport. Examples are Microsoft's Azure and Cloudflare.
>
> https://en.wikipedia.org/wiki/Internet_censorship_in_China
>
> More about meeks:
> https://blog.torproject.org/how-use-meek-pluggable-transport
>
> We generally talk about these systems as being resistant to active
> probes. No security researcher worth their salt will state outright that a
> system is proof against all attacks.
>
> We tend to judge that Tor is working as intended through the lack of
> reports of journalists, activists, etc using it being jailed, killed,
> disappeared and/or tortured. There are a great many theoretical attacks on
> Tor that security researchers have built reputations on. Very few are
> usable in the wild, but they make fascinating hypotheticals. Every so
> often one makes a really good point, and the crew mainlines caffeine for a
> week getting things patched, tested, and deployed.
>
> But whether they are hypothetical or practical, they are mostly proposed
> by top notch researchers with high profile papers (and often a great deal
> of publicity saying that TOR IS BROKEN, which fades in time as it's clear
> it is not -- but I'm sure the articles make great chits on a researcher's
> CV). That's kind of how this field works, as I've observed it.
>
> Among the general public, one of the greatest disincentives to using Tor
> is a boolean understanding of what software is "safe" or "not safe." Often
> a person has read one of these TOR IS BROKEN articles, and so instead of
> relative safety using Tor, they use *nothing*.
>
> Security software is always about assessed risks and human beings are
> notoriously bad at assessing risks.
>
> yrs,
>
> Shava Nerad
> shava23 at gmail.com
> https://patreon.com/shava23
>
>
> On Wed, Feb 24, 2021 at 2:37 PM Adam Fisk <afisk at getlantern.org> wrote:
>
>> So, I'm not even remotely trying to attack Moxie here. Signal clearly
>> does tremendous good in the world, and I personally like Moxie and actually
>> don't have much of an issue with him aggressively closing tickets and
>> whatnot.
>>
>> That said, we should be clear headed about the reality of the situation.
>> The researchers, including Sergey (please feel free to learn more about
>> Sergey's great work at https://sfrolov.io/), pinpointed a clear reason
>> that Signal's proxies would not last long in a real world censorship
>> scenario, namely that they are trivially identifiable through active
>> probes. Given that they are trivially identifiable through active probes,
>> censors can clearly block them all.
>>
>> In contrast, anti-censorship tools that actually work at scale in
>> censored regions are not susceptible to active probes.
>>
>> -Adam
>>
>> On Wed, Feb 24, 2021 at 2:05 PM Harry Halpin <hhalpin at ibiblio.org> wrote:
>>
>>> Furthermore, the problem with these supposed "attacks" on Signal is they
>>> ignore the nature of how censorship-resistance and obfuscation technologies
>>> work, blaming Signal where you should just blame TLS. So, of course Moxie
>>> deletes the bug. It just shows whoever 'discovered' it hasn't thought about
>>> the source of the bug.
>>>
>>> Basically, obfuscation will only work for a limited amount of time
>>> against an adversary that figures out it's being used. TLS - including TLS
>>> workarounds - naturally leaks all sorts of metadata, timing, and volume
>>> information. Thus, simplistic techniques like domain fronting formerly used
>>> by Signal eventually stop working.
>>>
>>> So, when I look at this "bug" in Signal, it's basically a bug in how TLS
>>> works. The same would be true for Wireguard, OpenVPN, etc. and whether or
>>> not it was used with Airbnb or Signal if Iran started censoring Airbnb.
>>> Sadly, the internet does not have privacy and censorship resistance on the
>>> protocol level baked in...yet.
>>>
>>> yours,
>>> harry
>>>
>>>
>>>
>>>
>>> On Wed, Feb 24, 2021 at 8:50 PM Yosem Companys <ycompanys at gmail.com>
>>> wrote:
>>>
>>>> Excellent intervention, Shava. I would also note that Moxie used to be
>>>> in LT (do not know if he still is), and all of us at Stanford continue to
>>>> be big fans of his work and accomplishments. (Same goes for Tor.)
>>>>
>>>> On Wed, Feb 24, 2021 at 11:43 AM Shava Nerad <shava23 at gmail.com> wrote:
>>>>
>>>>> I am not a cryptographer myself, but I have a bit of experience with
>>>>> anti-censorship tools.
>>>>>
>>>>> I know that my team, led by Roger Dingledine and Nick Mathewson, had
>>>>> great respect for Moxie back in 2007ish for the work he was doing then,
>>>>> including attacking Tor and helping us refine our tools -- and our
>>>>> messaging to end users.
>>>>>
>>>>> Moxie's been in this space for a good 15 years or so. Why are you
>>>>> talking about him as a newcomer?
>>>>>
>>>>> Respectfully,
>>>>>
>>>>> Shava Nerad
>>>>> shava23 at gmail.com
>>>>> https://patreon.com/shava23
>>>>>
>>>>>
>>>>> On Wed, Feb 24, 2021 at 9:30 AM Adam Fisk <afisk at getlantern.org>
>>>>> wrote:
>>>>>
>>>>>> Irrespective of the article, the claims are just obvious to anyone
>>>>>> with a reasonable enough knowledge of how censors detect proxies to have an
>>>>>> opinion.
>>>>>>
>>>>>> The article is largely irrelevant, and its removal doesn't obviate
>>>>>> the fact that the claims of the investigators, such as Sergey, that the
>>>>>> Signal proxies are vulnerable to active probes is, again, just there in
>>>>>> plain sight.
>>>>>>
>>>>>> This is, of course, not surprising, as the Signal team has almost no
>>>>>> experience with building effective anti-censorship tech. The idea that they
>>>>>> could realistically deploy a new proxy in a matter of days that would be
>>>>>> effective in those environments is frankly naive. That's all fine and good.
>>>>>> I don't have the experience they do with designing secure messaging
>>>>>> algorithms. It's cool, but we should have illusions about the reality of
>>>>>> the situation.
>>>>>>
>>>>>> -Adam
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 24, 2021 at 4:57 AM Charles M. Ess <
>>>>>> charles.ess at media.uio.no> wrote:
>>>>>>
>>>>>>> the most recent version of the article indicates that the original
>>>>>>> claims have been disputed and removed by BleepingComputer.
>>>>>>>
>>>>>>> Truth is difficult ...
>>>>>>> best,
>>>>>>> -charles
>>>>>>>
>>>>>>> On 24/02/2021 06:59, Myles Horton wrote:
>>>>>>> > Just for the record, the people who posted the vulnerability are
>>>>>>> hardly
>>>>>>> > trollers. First, the vulnerability is obvious and doesn't really
>>>>>>> need
>>>>>>> > any formal proof. Second, one of the researchers is Sergey Frolov,
>>>>>>> one
>>>>>>> > of the top people in the field.
>>>>>>> >
>>>>>>> > -Adam
>>>>>>> >
>>>>>>> > On Mon, Feb 8, 2021 at 6:02 PM bo0od <bo0od at riseup.net
>>>>>>> > <mailto:bo0od at riseup.net>> wrote:
>>>>>>> >
>>>>>>> > Nothing is concerned just trollers want to damage the image of
>>>>>>> signal
>>>>>>> >
>>>>>>> > Yosem Companys:
>>>>>>> > > The claims in this article are concerning if true. That
>>>>>>> said, I
>>>>>>> > will note
>>>>>>> > > that I remain supportive of Signal's efforts, both because
>>>>>>> its
>>>>>>> > founders and
>>>>>>> > > key developers have not only been longtime members of our
>>>>>>> > community but
>>>>>>> > > also proven themselves time and again indispensable at
>>>>>>> helping
>>>>>>> > high-risk
>>>>>>> > > activists in need, most notably during the Arab Spring.
>>>>>>> > >
>>>>>>> > > ****
>>>>>>> > >
>>>>>>> > > Signal, an end-to-end encrypted messaging platform was
>>>>>>> recently
>>>>>>> > blocked by
>>>>>>> > > the Iranian government.
>>>>>>> > >
>>>>>>> > > To help its users bypass censorship in Iran, the company
>>>>>>> > suggested a TLS
>>>>>>> > > proxy workaround.
>>>>>>> > >
>>>>>>> > > However, multiple researchers have now discovered flaws in
>>>>>>> the
>>>>>>> > workaround
>>>>>>> > > that can let a censor or government authority probe into
>>>>>>> Signal TLS
>>>>>>> > > proxies, rendering these protections moot and potentially
>>>>>>> bringing
>>>>>>> > > repercussions for Signal users located in repressive
>>>>>>> regimes.
>>>>>>> > >
>>>>>>> > > The researchers who reported these flaws via Signal's GitHub
>>>>>>> > repository
>>>>>>> > > have been banned by the company with their reported issues
>>>>>>> removed.
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>> https://www.bleepingcomputer.com/news/security/signal-ignores-proxy-censorship-vulnerability-bans-researchers/
>>>>>>> > <
>>>>>>> https://www.bleepingcomputer.com/news/security/signal-ignores-proxy-censorship-vulnerability-bans-researchers/
>>>>>>> >
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>> > --
>>>>>>> > Liberationtech is public & archives are searchable from any
>>>>>>> major
>>>>>>> > commercial search engine. Violations of list guidelines will
>>>>>>> get you
>>>>>>> > moderated: https://lists.ghserv.net/mailman/listinfo/lt
>>>>>>> > <https://lists.ghserv.net/mailman/listinfo/lt>. Unsubscribe,
>>>>>>> change
>>>>>>> > to digest mode, or change password by emailing
>>>>>>> > lt-owner at lists.liberationtech.org
>>>>>>> > <mailto:lt-owner at lists.liberationtech.org>.
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> --
>>>>>>> Professor Emeritus
>>>>>>> University of Oslo
>>>>>>> <http://www.hf.uio.no/imk/english/people/aca/charlees/index.html>
>>>>>>>
>>>>>>> Secretary, IFIP Working Group 9.8, Gender, Diversity, and ICT
>>>>>>> <http://ifiptc9.org/9-8/>
>>>>>>>
>>>>>>> Fellow, Siebold-Collegiums Institute for Advanced Studies,
>>>>>>> Julius-Maximilians-Universität Würzburg, Germany
>>>>>>>
>>>>>>> 3rd edition of Digital Media Ethics now out:
>>>>>>> <http://politybooks.com/bookdetail/?isbn=9781509533428>
>>>>>>>
>>>>>>> --
>>>>>>> Liberationtech is public & archives are searchable from any major
>>>>>>> commercial search engine. Violations of list guidelines will get you
>>>>>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt.
>>>>>>> Unsubscribe, change to digest mode, or change password by emailing
>>>>>>> lt-owner at lists.liberationtech.org.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> President
>>>>>> Brave New Software Project, Inc.
>>>>>> https://lantern.io <https://www.getlantern.org>
>>>>>> A998 2B6E EF1C 373E 723F A813 045D A255 901A FD89
>>>>>> --
>>>>>> Liberationtech is public & archives are searchable from any major
>>>>>> commercial search engine. Violations of list guidelines will get you
>>>>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt.
>>>>>> Unsubscribe, change to digest mode, or change password by emailing
>>>>>> lt-owner at lists.liberationtech.org.
>>>>>>
>>>>> --
>>>>> Liberationtech is public & archives are searchable from any major
>>>>> commercial search engine. Violations of list guidelines will get you
>>>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
>>>>> change to digest mode, or change password by emailing
>>>>> lt-owner at lists.liberationtech.org.
>>>>>
>>>> --
>>>> Liberationtech is public & archives are searchable from any major
>>>> commercial search engine. Violations of list guidelines will get you
>>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
>>>> change to digest mode, or change password by emailing
>>>> lt-owner at lists.liberationtech.org.
>>>>
>>> --
>>> Liberationtech is public & archives are searchable from any major
>>> commercial search engine. Violations of list guidelines will get you
>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
>>> change to digest mode, or change password by emailing
>>> lt-owner at lists.liberationtech.org.
>>>
>>
>>
>> --
>> --
>> President
>> Brave New Software Project, Inc.
>> https://lantern.io <https://www.getlantern.org>
>> A998 2B6E EF1C 373E 723F A813 045D A255 901A FD89
>> --
>> Liberationtech is public & archives are searchable from any major
>> commercial search engine. Violations of list guidelines will get you
>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
>> change to digest mode, or change password by emailing
>> lt-owner at lists.liberationtech.org.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ghserv.net/pipermail/lt/attachments/20210225/0c5cb169/attachment.htm>
More information about the LT
mailing list