IETF Logo Mail Archive

Re: ietf.org unaccessible for Tor users

Christian de Larrinaga <cdel@firsthand.net> Tue, 15 March 2016 10:18 UTC

Return-Path: <cdel@firsthand.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12A112D900 for <ietf@ietfa.amsl.com>; Tue, 15 Mar 2016 03:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level:
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=neutral reason="invalid (public key: not available)" header.from=cdel@firsthand.net header.d=firsthand.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWXv7AEAhnkm for <ietf@ietfa.amsl.com>; Tue, 15 Mar 2016 03:18:28 -0700 (PDT)
Received: from bmtwo.vm.bytemark.co.uk (mail.firsthand.net [212.110.188.53]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCFB12D51A for <ietf@ietf.org>; Tue, 15 Mar 2016 03:18:27 -0700 (PDT)
X-No-Relay: not in my network
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=firsthand.net; b=UTHsmHTuJQjPvUd+JWX6tlKoCWKF1B4hp4ipKrayeIDw+Qy4j++0Ukob7DUS+ADq6qiF58sLm1TN+qkS6VjDhx6L6U2eFzu/xSFD+qrIgw6qF9eZsfAs8TauS0GX4FN6; h=X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from Christians-MacBook-Pro.local (60.88.155.90.in-addr.arpa [90.155.88.60]) by bmtwo.vm.bytemark.co.uk (Postfix) with ESMTPSA id 11328E03C4; Tue, 15 Mar 2016 10:18:25 +0000 (GMT)
Message-ID: <56E7E16C.4050803@firsthand.net>
Date: Tue, 15 Mar 2016 10:18:20 +0000
From: Christian de Larrinaga <cdel@firsthand.net>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
Subject: Re: ietf.org unaccessible for Tor users
References: <20160313143521.GC26841@Hirasawa> <m2a8m0y72q.wl%randy@psg.com> <F04B3B85-6B14-43BA-9A21-FC0A31E79065@piuha.net> <56E7E09D.7040100@cisco.com>
In-Reply-To: <56E7E09D.7040100@cisco.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/O5T9DfMN4jfXuRr3Id_XeShXm0U>
Cc: Yui Hirasawa <yui@cock.li>, IETF Disgust List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: cdel@firsthand.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2016 10:18:32 -0000

One Internet or something?

> Eliot Lear <mailto:lear@cisco.com>
> 15 March 2016 at 10:14
>
> I'll bite: why is it important that IETF documents be accessible via Tor?
>
> Eliot
>
>
> Jari Arkko <mailto:jari.arkko@piuha.net>
> 15 March 2016 at 08:20
> I don’t have a solution, but I wanted to say that I feel the pain.
>
> It is important that IETF documents are accessible via Tor. It is
> important that whatever CAPTCHA's are being employed, they are
> accessible to everyone. It is important that we at the IETF are able
> to deal with DoS attacks.
>
> I’m not ready to believe that the above requirements are fundamentally
> in conflict.
>
> I have a question thought and couple of other observations.
>
> The question: Yui: I was under the (perhaps mistaken) assumption that
> ietf.org is generally accessible to everyone in the usual way, but
> that some blacklisted nodes will have to go through a CAPTCHA process
> before being able to continue. Is this so, or is there an experience
> that says nodes are blocked and there isn’t even a possibility to go
> through a CAPTCHA? Or is the problem that there is a CAPTCHA but you
> do not feel that it is done in a way that is appropriate? Does all
> this relate to http or https traffic?
>
> The observations:
>
> o I do not feel that contracted running of multiple copies of our
> servers constitutes a man-in-the-middle arrangement.
>
> o I have asked the matter to be discussed in our IT/tools/IAOC
> meetings, but I’ll note that we may not have any more magical answers
> than what is already being discussed on the list.
>
> Jari
>
> Randy Bush <mailto:randy@psg.com>
> 14 March 2016 at 23:26
>
> i agree this is a problem. but i am not sure about the solution space.
> are we trading one form of security for another?
>
> what is the treat model which drives us to tls/https? authenticity of
> the data? privacy of what i access? in the scheme of things, how
> important are our data anyway and what are we trading for perceived
> protection?
>
> how much load-spreading and resilience do ietf web/wiki/archives
> actually need? if they need a cdn, and i am not so sure they do, can we
> have a cdn which supports tls without being a monkey in the middle? do
> we pay to deploy a half dozen anycasted instances of our own and
> maintain them [0]?
>
> some of this we have discussed before, maybe not as insightfully as we
> might have.
>
> randy
>
> 0 - sysadmin is similar to doing the dishes; you go to sleep with a
> clean kitchen, but there will be more dishes tomorrow.
>
> Yui Hirasawa <mailto:yui@cock.li>
> 13 March 2016 at 14:35
> Hello IETF,
>
> Today when I tried to go read a standard on the ietf.org website I was
> met with a CloudFlare CAPTCHA page.
>
> By using CloudFlare IETF is actively blocking Tor connections to IETF
> page. CloudFlare also works as man-in-the-middle and all encryption to
> ietf.org is null and void which means IETF is actively helping the
> authoritarian governments weaken the encryption on the Internet.
> CloudFlare also requires proprietary javascript to be run by Tor users
> who want to access websites which makes fingerprinting them very easy.
> Because CloudFlare is a man-in-the-middle it can also inject websites
> with malicious javascript, such as fingerprinting javascript. CloudFlare
> also collects all connection data and is subject to US secret courts and
> thus using it is directly contributing to the mass surveillance of the
> Internet.
>
> Tor project has also finally started noticing this[1]. And I wrote a
> small thing[2] about it on my website recently as well.
>
> IETF using CloudFlare is a very bad thing for the security and
> neutrality of the Internet and this should be fixed immediately.
>
> If you think there is some other place where I could notify people about
> this then please send me an email.
>
> [1]: https://trac.torproject.org/projects/tor/ticket/18361
> [2]: https://GNU.moe/thoughts/cloudflare.html
>

-- 
Christian de Larrinaga  FBCS, CITP,
-------------------------
@ FirstHand
-------------------------
+44 7989 386778
cdel@firsthand.net
-------------------------

v2.23.0 | Report a Bug | By Email