Subject: IETF web site behind CloudFlare

From: Linus Nordberg <[email-masked]>
Date: Tue, 16 Sep 2014 13:52:32 +0200

Hi IETF,

It seems like www.ietf.org is behind CloudFlare:

$ dig +short www.ietf.org
www.ietf.org.cdn.cloudflare.net.
104.20.1.85
104.20.0.85

This is sad because it's now not possible to visit the site without
accepting JavaScript. At least if you get selected for solving a
CAPTCHA. Tor users is one group of users who are selected.

Is this permanent?
Will it hit more domains than www?
Where can I read about the decision to hide www behind CloudFlare?

Thanks,
Linus

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 16 Sep 2014 15:34:34 +0000

> www.ietf.org.cdn.cloudflare.net.

“hide”?

I think I might start by asking the IAD or the IAOC. I wasn’t involved, but the use of a CDN is usually a business decision, and they are the folks who make business decisions for the IETF. AMS has historically provided redundancy for www.ietf.org by hosting it at two sites, one of which was a secondary for the other. Just a guess, but it’s mine, Cloudflare probably offered the IETF a deal in which the IETF got redundant dual stack service and a good rate.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 16 Sep 2014 08:44:15 -0700

Hi Linus,
>It seems like www.ietf.org is behind CloudFlare:

[snip]

>Where can I read about the decision to hide www behind CloudFlare?

The IETF outsourced its web service to CloudFlare ( 
https://iaoc.ietf.org/documents/IAOC-Minutes-Public-2014-06-12.pdf 
).  It seems like it is going to be permanent.

Regards,
S. Moonesamy

---

From: David Conrad <[email-masked]>
Date: Tue, 16 Sep 2014 09:14:56 -0700

On Sep 16, 2014, at 8:34 AM, Fred Baker (fred) <[email-masked]> wrote:
>> ...

I believe a client gets thrown to a CAPTCHA when the source IP address is identified with a threat/attack of some sort in order to ensure there is a human behind the client. In as much as sites behind Tor are used to originate attacks, it isn’t too surprising that they get redirected to a CAPTCHA.

As for it being sad, I see it as a reasonable tradeoff in today’s Internet.

>> Is this permanent?

Few things in life are. I imagine if another company were to provide a better deal/meet the IETF requirements for CDN services, the IETF would probably switch.

> I think I might start by asking the IAD or the IAOC. I wasn’t involved, but the use of a CDN is usually a business decision, and they are the folks who make business decisions for the IETF. AMS has…

There is also http://www.latimes.com/business/technology/la-fi-tn-cloudflare-free-https-20140808-story.html

Regards,
-drc
(full disclosure: I used to work for Cloudflare a few years ago)

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 16 Sep 2014 18:25:02 +0200

David Conrad <[email-masked]> wrote
Tue, 16 Sep 2014 09:14:56 -0700:

| On Sep 16, 2014, at 8:34 AM, Fred Baker (fred) <[email-masked]> wrote:
| > On Sep 16, 2014, at 4:52 AM, Linus Nordberg <[email-masked]> wrote:
| >> It seems like www.ietf.org is behind CloudFlare:
| >> ...
| >> This is sad because it's now not possible to visit the site without
| >> accepting JavaScript. At least if you get selected for solving a
| >> CAPTCHA. Tor users is one group of users who are selected.
| 
| I believe a client gets thrown to a CAPTCHA when the source IP address
| is identified with a threat/attack of some sort in order to ensure
| there is a human behind the client. In as much as sites behind Tor are
| used to originate attacks, it isn’t too surprising that they get
| redirected to a CAPTCHA.

I hear about other CloudFlare customers who's users don't have to solve
CAPTCHA's in order to access their site. Can it be some sort of setting
that the customer is in control of? What are IETF's settings?

| As for it being sad, I see it as a reasonable tradeoff in today’s Internet.

I see few reasons for not falling back to not using JavaScript for
serving a CAPTCHA. There might be other reasons for requiring JavaScript
that I'm not aware of.

It would be pretty great if IETF, as a CloudFlare customer, would ask if
it's possible to serve content to people not executing JavaScript. How
can I help?

<snip>

| Regards,
| -drc
| (full disclosure: I used to work for Cloudflare a few years ago)

(full disclosure: I work for Tor now and then)

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Sep 2014 12:54:36 -0400 (EDT)

> As for it being sad, I see it as a reasonable tradeoff in today’s Internet.

How many attacks has ietf.org been under? Can the vendor not distinguish
between tor nodes towards ietf.org and tor nodes towards other sites? We
have contributors in countries where using tor to access IETF might
actually be a requirement.

How does this mechanism work when there is traffic using TLS? Is there a
MITM cert?

> Few things in life are. I imagine if another company were to provide a better deal/meet the IETF requirements for CDN services, the IETF would probably switch.

I would hope IETF would pick a CDN provides that does not require
insecure CNAME redirection which breaks some of our IETF protocols
(like DANE). Hopefully, they will address that soon.

Paul

---

From: David Conrad <[email-masked]>
Date: Tue, 16 Sep 2014 10:29:24 -0700

On Sep 16, 2014, at 9:54 AM, Paul Wouters <[email-masked]> wrote:
> How many attacks has ietf.org been under?

Dunno, but given how sadly easy it is to mount DOS attacks, I’d be surprised if there haven’t been some.

> Can the vendor not distinguish
> between tor nodes towards ietf.org and tor nodes towards other sites?

Is there a canonical list of Tor nodes? If so, then maybe, however it’s been a couple of years since I was at CloudFlare, so I’d just be guessing.

> We

No doubt.

> How does this mechanism work when there is traffic using TLS? Is there a

Probably best to ask the folks at CloudFlare.

Regards,
-drc

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 16 Sep 2014 13:41:10 -0400

On Tue, Sep 16, 2014 at 01:52:32PM +0200, Linus Nordberg wrote:
> accepting JavaScript. 
 
That effectively breaks the site for anyone using a text-only browser
or for anyone who (wisely) uses a browser add-on like NoScript. [1]  While
the use of JavaScript for *some* web site functions is reasonable, any
web site that doesn't provide basic functionality (including navigation)
without it is, in my opinion, completely inadequate for professional use.

---rsk

[1] Yes, such users can temporarily un-break it by allowing NoScript
to execute for the particular domain/hostname in question, however
my experience with Cloudflare is that one must permit a random-looking
Cloudflare hostname.  This provides little assurance that the same
hostname will work in the future, nor is there any indication of which
additional sites might be associated with that hostname -- and thus
which a user may be unwittingly permitting to run JavaScript.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 16 Sep 2014 14:28:49 -0400

On Tue, Sep 16, 2014 at 1:41 PM, Rich Kulawiec <[email-masked]> wrote:
> or for anyone who (wisely) uses a browser add-on like NoScript. [1]

while it's all nice to get upset about no text browsers and needing
javascript and what not... err, I'm not seeing captchas from a variety
of vantage points, so maybe this is something nearer to the OP and
less of an 'all over' problem?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Sep 2014 23:46:51 +0300

> How does this mechanism work when there is traffic using TLS? Is there a

No. They present a perfectly valid certificate for *.ietf.org signed by Starfield. 

So the delegation is done by CNAME record for HTTP and by a certificate for TLS. A typical CDN server is likely to store dozens or hundreds of such private keys and certificates. This was discussed at the DANE meeting in Toronto (and the minutes show you were there).

> (like DANE). Hopefully, they will address that soon.

Your browser has to get to the CDN server somehow. If not a CNAME, you’ll need to just let www.ietf.org resolve directly to that server. How is that better?

Yoav

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Sep 2014 15:00:02 -0600

I turned JavaScript off and seem to have access to www.ietf.org.

I can't find anything broken.

-- 

Doug Royer - (K7DMR.us / DougRoyer.com)
[email-masked]
714-989-6135

---

From: Shumon Huque <[email-masked]>
Date: Tue, 16 Sep 2014 20:38:58 -0400

On Tue, Sep 16, 2014 at 4:46 PM, Yoav Nir <[email-masked]> wrote:

> Your browser has to get to the CDN server somehow. If not a CNAME, you’ll
> need to just let www.ietf.org resolve directly to that server. How is
> that better?
>

I think you missed the qualifier "insecure". The CNAME record is itself
secure (i.e. DNSSEC signed), but the target of the CNAME is located in the
unsigned Cloudflare zone. The subsequent address lookup of the target is
thus not secure.

It's possible some aspects of DANE may still be secure. For example, as
currently configured, only the name www.ietf.org is mapped into Cloudflare.
So records like _443._tcp.www.ietf.org. TLSA (if it existed) could still be
wholly inside the signed ietf.org zone.

I believe Jari Arrko mentioned at the last IETF that Cloudflare is working
on deploying DNSSEC. It would be good to know if they have a specific or
estimated timeline for that.

--Shumon.

---

From: Tom Thorogood <[email-masked]>
Date: Wed, 17 Sep 2014 13:38:43 +0930

Did you actually try to access CloudFlare through a text-only browser?
Try it. `$ lynx http://ietf.org/` It works perfectly fine for me.
CloudFlare only /conditionally/ presents the captcha when it determines
a need. The only place I've ever seen that happen is using Tor. You
really don't need JavaScript unless you get caught by their rules (e.g.
Tor and maybe some NATs?) otherwise it won't bother you.

Regards,
Tom Thorogood.

[Disclosure: I'm a completely satisfied CloudFlare client of several years.]

---

From: Tom Thorogood <[email-masked]>
Date: Wed, 17 Sep 2014 13:50:52 +0930

> How does this mechanism work when there is traffic using TLS? Is there a

According to CloudFlare Support
(<https://support.cloudflare.com/hc/en-us/articles/200170416-What-do-the-three-SSL-options-off-Flexible-Full-mean->)
there are options for how SSL (or TLS rather) operates. It can be User
--TLS--> CloudFlare --> Server (as they put it: front-end over TLS,
back-end over TLS) or User --TLS--> CloudFlare --TLS--> Server (as they
put it: front-end over TLS, back-end unencrypted).

CloudFlare receive a valid certificate from GlobalSign (it would seem)
and present that to the browser. Although you do have the option to
upload your own private key for 'Business and Enterprise plans'. While
I'm can't find their justification for requesting them, I don't believe
it constitutes a MITM certificate. It's also likely that other CDN
providers have similar setups as well.

Regards,
Tom Thorogood.

[Disclosure: Fully satisfied CloudFlare customer.]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Sep 2014 16:40:09 +1200

The only issue I've noticed since the site was CloudFlared (well before
IETF 90) is that sometimes the mirror in Sydney, AU is out of date
when files are updated. For example if you upload a new version of
something to the meeting materials manager, the old version is served
from Sydney for some length of time (less than one hour, I believe).

otoh I don't use Tor.

Regards
   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Sep 2014 07:35:59 +0200 (CEST)

On Tue, 16 Sep 2014, Rich Kulawiec wrote:

> That effectively breaks the site for anyone using a text-only browser or 
> for anyone who (wisely) uses a browser add-on like NoScript. [1] While 

The fun^Winteresting part is that when I last year said I would like TCP 
window scaling turned on:

http://www.ietf.org/mail-archive/web/ietf/current/msg78090.html

I got shot down that the IETF web site needed to be accessed by everybody 
and that TCP window scaling might have bugs. Compared to the cloudflare 
move, that's... errr... I don't have words.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Wed, 17 Sep 2014 09:41:44 +0200

> less of an 'all over' problem?

Its a ToR thing. You get hit by captchas when you aproach from a ToR
exit node.

I think ToR users are fine with that (generally speaking).

I don't understand why you need JS for presenting a basic captcha. For
instance recaptcha doesn't need plugins:
https://developers.google.com/recaptcha/docs/display

	Cheers Leif

---

From: Rhys Smith <[email-masked]>
Date: Wed, 17 Sep 2014 08:14:22 +0000

> https://developers.google.com/recaptcha/docs/display

Well, it looks like maybe it’s *supposed* to work without JS - if you have JS disabled it presents the captcha in a slightly different way (saying "To make this process easier in the future, we recommend you enable Javascript.”), and then if you answer correctly it gives you a 186 character string to copy then paste into a second text box. When you do that, what happens with me in the Tor Browser is instead of letting you get to the site, it just starts the whole captcha process off again from scratch.

A bug in CloudFlare’s stuff?

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet, the UK's research and education network

email: [email-masked] / [email-masked]
GPG: 0x4638C985

---

From: Tom Thorogood <[email-masked]>
Date: Wed, 17 Sep 2014 18:01:52 +0930

Although I couldn't read the present string (because it was in what
appeared to be Polish), I can confirm that I can successfully access
<https://www.ietf.org/> through Tor after completing the captcah without
JavaScript. It worked without any problems (except the language bit but
that doesn't really count).

Regards,
Tom Thorogood.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Sep 2014 12:54:09 +0300

Linus,

The change to Cloudfare has been mentioned, for instance in the plenary. The decision was taken by IAOC, with input from the tools committee, based on our perception of the need to have a globally efficient access to IETF web content, with ability to scale as needed, and with the kind of support that we need. And obviously without having to build too much of it ourselves.  Note that the current setup involves static web content and not the data tracker.

See page 18 in for some measurements regarding the effects http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf and I think at least I personally have found the impact significant.

I was not personally aware of the captcha operation nor have I ever seen it while accessing the IETF web site from various places. But we can ask Ray to investigate if there are different, more suitable settings. However, I’d note that being able to deal with some dos attacks is actually a useful feature, and it is not unthinkable for the IETF to be a target. So any defence tactic inconvenience should be weighted against the risks and benefits.

> actually be a requirement.

That is interesting. Do you have details? Where?

Shumon:

> I believe Jari Arrko mentioned at the last IETF that Cloudflare is working on deploying DNSSEC. It would be good to know if they have a specific or estimated timeline for that.

TLS, DNSSEC, IPv6, etc are very important to us. TLS and IPv6 obviously has been there, and partially based on IETF request they are working on DNSSEC. Stay tuned - the date that I heard earlier this year is approaching, but we can again ask Ray to check the current situation.

> from Sydney for some length of time (less than one hour, I believe).

If we find a problem either with the IETF or Cloudfare setup - and test it to be a real problem - please communicate with Ray to get it reported.

Jari

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 17 Sep 2014 12:09:55 +0200

Tom, Rhys, thanks for testing this.

We seem to have three different experiences using Tor Browser for
accessing the IETF web site. I suppose this can have approximately as
many explanations as there are permutations of operating systems,
browsers, browser plugins and phases of numerous moons.

I think that the productive way forward from here is to open an issue
with the service provider, CloudFlare. I'm happy to provide end user
experience information in such a case.

Tom Thorogood <[email-masked]> wrote
Wed, 17 Sep 2014 18:01:52 +0930:

| Although I couldn't read the present string (because it was in what
| appeared to be Polish), I can confirm that I can successfully access
| <https://www.ietf.org/> through Tor after completing the captcah without
| JavaScript. It worked without any problems (except the language bit but
| that doesn't really count).
| 
| Regards,
| Tom Thorogood.
| 
| On 17/09/14 17:44, Rhys Smith wrote:
| > On 17 Sep 2014, at 08:41, Leif Johansson <[email-masked]> wrote:
| > 
| >> Its a ToR thing. You get hit by captchas when you aproach from a ToR
| >> exit node.
| >>
| >> I think ToR users are fine with that (generally speaking).
| >>
| >> I don't understand why you need JS for presenting a basic captcha. For
| >> instance recaptcha doesn't need plugins:
| >> https://developers.google.com/recaptcha/docs/display> 
| > Well, it looks like maybe it’s *supposed* to work without JS - if
| > you have JS disabled it presents the captcha in a slightly different
| > way (saying "To make this process easier in the future, we recommend
| > you enable Javascript.”), and then if you answer correctly it gives
| > you a 186 character string to copy then paste into a second text
| > box. When you do that, what happens with me in the Tor Browser is
| > instead of letting you get to the site, it just starts the whole
| > captcha process off again from scratch.
| > 
| > A bug in CloudFlare’s stuff?
| > 
| > Rhys.
| > --
| > Dr Rhys Smith
| > Identity, Access, and Middleware Specialist
| > Cardiff University & Janet, the UK's research and education network
| > 
| > email: [email-masked] / [email-masked]
| > GPG: 0x4638C985
| >

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 17 Sep 2014 12:44:48 +0200

Jari Arkko <[email-masked]> wrote
Wed, 17 Sep 2014 12:54:09 +0300:

| The change to Cloudfare has been mentioned, for instance in the
| plenary. The decision was taken by IAOC, with input from the tools
| committee, based on our perception of the need to have a globally
| efficient access to IETF web content, with ability to scale as needed,
| and with the kind of support that we need. And obviously without
| having to build too much of it ourselves.  Note that the current setup
| involves static web content and not the data tracker.

Sadly it covers also the mailing list archives at
https://www.ietf.org/mail-archive/web/ietf/, which is a real
bummer. Would providing an alternative way to reach the archives, in
addition to the above, be possible?

| See page 18 in for some measurements regarding the effects
| http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf
| and I think at least I personally have found the impact significant.

(If only I could access that document. ;))

Well, this is somewhat telling. Page 18 shows graphs and tables on HTTP
load time before and after switching CDN. I realise that people care
about performance but I think that we in this case care too little about
the safety of our users.

We serve static pages to users who risk having to talk to both
CloudFlare (every time regardless of "rating" actually) and Google (for
the captcha) and this with a browser executing javascript. While I do
applaud the support for TLS on the site, I think that we should take
more things than performance and DoS mitigation into consideration when
picking technology and setting up our services.

I realise the need for outsourcing of some things. I don't know if there
is a solution where users can pull the content from IETF servers
only. But wouldn't it be great if we used the power of the consumer to
try to make things better for web users? I would imagine that IETF is
somewhat listened to when it comes to this.

| I was not personally aware of the captcha operation nor have I ever
| seen it while accessing the IETF web site from various places. But we
| can ask Ray to investigate if there are different, more suitable
| settings. However, I’d note that being able to deal with some dos
| attacks is actually a useful feature, and it is not unthinkable for
| the IETF to be a target. So any defence tactic inconvenience should be
| weighted against the risks and benefits.

I agree. What worries me is that the risk of blocking legitimate users
is being underestimated.

Ray, please let me know how I can help with testing the settings
("Threat Scores" and "Security Level" seems to be relevant terms) from a
users point of view.

Jari, thanks for caring about this.

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 17 Sep 2014 06:48:26 -0400

On Wed, Sep 17, 2014 at 12:54:09PM +0300, Jari Arkko wrote:
> I was not personally aware of the captcha operation nor have I ever
> seen it while accessing the IETF web site from various places. But
> we can ask Ray to investigate if there are different, more suitable
> settings. However, I?d note that being able to deal with some dos attacks
> is actually a useful feature, and it is not unthinkable for the IETF
> to be a target. So any defence tactic inconvenience should be weighted
> against the risks and benefits.

If captchas actually *were* a viable defense mechanism, then it might be
reasonable to use them.  But they ceased being so years ago, and are now
deployed exclusively by those who either haven't been paying attention
or those who studiously refuse to acknowledge reality.  Some reading on this
point (many of these contain links that lead to further useful material):

	Stanford researchers outsmart captcha codes
	http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html

	CIntruder: pentesting tool to bypass captchas
	http://cintruder.sourceforge.net/

	How a trio of hackers brought Google's reCAPTCHA to its knees
	http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/

	Snapchat Account Registration CAPTCHA Defeated
	http://it.slashdot.org/story/14/01/23/2037201/snapchat-account-registration-captcha-defeated

	Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA
	http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html

	Troy Hunt: Breaking CAPTCHA with automated humans
	http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html

	Now Even Photo CAPTCHAs Have Been Cracked/
	http://it.slashdot.org/article.pl?sid=08/10/14/1442213

	Cheap CAPTCHA Solving Changes the Security Game
	https://freedom-to-tinker.com/blog/felten/cheap-captcha-solving-changes-security-game/

	Wiseguys Indicted in $25 Million Online Ticket Ring
	http://www.wired.com/threatlevel/2010/03/wiseguys-indicted/

Using captchas in 2014 is the security equivalent of Wile E. Coyote holding an
umbrella over his head as an enormous boulder falls toward him: it's a pointless
and futile gesture with zero actual value.

---rsk

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Sep 2014 14:01:30 +0300

> But wouldn't it be great if we used the power of the consumer to

And this was precisely what we did. We are not done, working on the DNSSEC part of it, but I’m optimistic. I learned about your problems regarding CAPTCHAs from this thread today, so I and I guess others have been unaware of those issues. As noted, we can see if some other settings are possible. And making the question little bit more generic, if the issue is that you are behind Tor, and that causes pain for some set of Internet services, is there something more general that the IETF or various networking companies could do about that?

Jari

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 17 Sep 2014 12:18:48 +0000

On 9/17/14, 7:01 AM, "Jari Arkko" <[email-masked]> wrote:

>And this was precisely what we did. We are not done, working on the
>DNSSEC part of it, but I¹m optimistic.

I really hope you can solve the DNSSEC issue! :-) If you can, that would
be broadly beneficial to the many other websites that use CDNs. And it¹d
really take away a major issue standing in the way of even wider DNSSEC
deployment.

- Jason

---

From: [email-masked] (Martin Rex)
Date: Wed, 17 Sep 2014 17:18:51 +0200 (CEST)

Rhys Smith wrote:
> Leif Johansson <[email-masked]> wrote:
> 

On the contrary, they ought to be rightfully upset about such crap.

>> 
>> I don't understand why you need JS for presenting a basic captcha.
> 
> A bug in CloudFlare?s stuff?

In principle, the dysfunction/inaccessibility of WebSites without
Javascript enabled is a rampant pandemic disease and a serious threat
to everybody, as least as bad, if not worse than the massive global
communications surveillance by Five Eyes and ilk.

Singling out TOR users and persuading them to enable Javascript adds
a different aspect, however.  We know from past publications that
FBI (and probably all other agencies) exploit browser bugs in attempt
to identify TOR users, and exploiting Browser bugs is **MUCH** easier
when Javascript is available.

So there likely is a desire within those agencies to condition
TOR users to enable Javascript, and the current CloudFlare
behaviour is not necessarily a genuine idea, but may have been
inspired/suggested/coerced from outside.

-Martin

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Sep 2014 08:56:15 -0700

Martin,

On Sep 17, 2014, at 8:18 AM, Martin Rex <[email-masked]> wrote:
> a different aspect, however.  

I would be quite surprised to learn that TOR users were being singled out.

At least in the past (and I’ve no reason to suspect it has changed), CloudFlare collects data on the sources of attacks of various kinds, e.g., zombies involved D(D)oS attacks, attempts (typically automated) to use known vulnerabilities like SQL injection, etc. If a connection attempt is made to a CloudFlare customer from a source IP address used in an attack, that connection is thrown over to a CAPTCHA.

As such, I suspect the reason TOR users get hit with the CAPTCHA is because the TOR exit node that appears to CLoudFlare’s system as the source IP address _was_ used in an attack attempt of some kind.  TOR users are not being singled out, they’re just using an infrastructure that happens to be used by script kiddies and others to attack other sites and suffering the consequences. I believe the exact same thing happens to folks who have the misfortune of being behind CGN.

> TOR users to enable Javascript,

Given the proliferation of Javascript on the web, “those agencies” don’t have to do _anything_.

> and the current CloudFlare

Sorry, this last bit strikes me as tinfoil hat territory.

Regards,
-drc
(who worked for CloudFlare 3 years ago but no longer works there)

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 17 Sep 2014 13:22:29 -0700

On Sep 17, 2014, at 8:56 AM, David Conrad <[email-masked]> wrote:
> If a connection attempt is made to a CloudFlare customer from a source IP address used in an attack, that connection is thrown over to a CAPTCHA.

Can the IETF not be trusted to secure it's own server(s)?  Why have we contracted to a 3rd party that chooses to act as a 'Nanny'?

	Ross.

---

From: John Kristoff <[email-masked]>
Date: Wed, 17 Sep 2014 15:30:34 -0500

On Tue, 16 Sep 2014 13:52:32 +0200

> CAPTCHA. Tor users is one group of users who are selected.

It is not just CloudFlare where the IETF resources have begun to be a
lot more particular about what your packets should look like. If you try
to browse to tools.ietf.org without presenting an acceptable User Agent
string you get a 403 forbidden.  I submitted a ticket about this
behavior about a year ago.

John

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Sep 2014 14:00:54 -0700

On Sep 17, 2014, at 1:22 PM, Ross Finlayson <[email-masked]> wrote:
> Can the IETF not be trusted to secure it's own server(s)?  

Sure. How much do you want to spend?

> Why have we contracted to a 3rd party that chooses to act as a 'Nanny’?

Odd phrasing. It’s a feature of the service CloudFlare sells. It is (or was, haven’t looked in a number of years) tunable.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Sep 2014 08:30:20 +1000

Well we could ask them to implement EDNS correctly let alone DNSSEC.
The following query should succeed but doesn't.

dig www.ietf.org.cdn.cloudflare.net @www.ietf.org.cdn.cloudflare.net +edns=1

There are no sane reasons to block EDNS negotiation.

Similarly there is no sane reason to drop EDNS queries with a Z flag bit set.
The following query also times out (requires dig from BIND 9.11.0 or later).

dig www.ietf.org.cdn.cloudflare.net @www.ietf.org.cdn.cloudflare.net +ednsflags=0x80

Dropping either +edns=1 or +ednsflags=0x80 results in a successful EDNS query.

The expected behaviour for both of these queries is well defined for EDNS(0)
servers.  Return BADVERS for +edns=1 and ignore the flag bit in the request.

If you let EDNS version 0 queries through a firewall there is zero reasons to
block either of these queries.

Mark

In message <[email-masked]>, David Conrad
 writes:
> 
> --Apple-Mail=_EE86F3A2-D263-4FF4-A325-9451DF4B0FF1
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
> 	charset=windows-1252
> 
> On Sep 17, 2014, at 1:22 PM, Ross Finlayson <[email-masked]> =
> wrote:
> >> If a connection attempt is made to a CloudFlare customer from a =
> source IP address used in an attack, that connection is thrown over to a =
> CAPTCHA.
> > Can the IETF not be trusted to secure it's own server(s)? =20
> 
> > Why have we contracted to a 3rd party that chooses to act as a =
> 'Nanny=92?
> 
> Odd phrasing. It=92s a feature of the service CloudFlare sells. It is =
> (or was, haven=92t looked in a number of years) tunable.
> 
> Regards,
> -drc
> 
> 
> --Apple-Mail=_EE86F3A2-D263-4FF4-A325-9451DF4B0FF1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
> 	filename=signature.asc
> Content-Type: application/pgp-signature;
> 	name=signature.asc
> Content-Description: Message signed with OpenPGP using GPGMail
> 
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - https://gpgtools.org
> 
> iQEcBAEBCgAGBQJUGfaGAAoJENV6ebf0/4rXphoIAOcl/sYFFinEcSFBBRXPtQPE
> OwAGZikILbgninZ7P8ElJVQz5SkhBcAitz/UgjuGWQUxzogMV8N6RywQLQPsufXe
> XjfWDu/9NtETWA/B3rcOW6ga3frq9YlGZcb1BTe/gBrfoEbY/AMWaUWnVUrwz3eI
> E76uR4iKMyJO71FOWob8HwCxUuvX0kHLF05Cyt40+GFlOEhkdekXiHsCEw1/rBHO
> rON4PRpmhUzE7CC7QJiQhzliZI6+FQBIcH/fUtwJrg9BTY3i1bbsSzQ37SPLOVIf
> uSdby19cWaKvZeSkw5ecRiFEYbqe9pFyyYRvdRVA4LzXaLZVhgrUk80tsoL19Js=
> =p2mY
> -----END PGP SIGNATURE-----
> 
> --Apple-Mail=_EE86F3A2-D263-4FF4-A325-9451DF4B0FF1--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Sep 2014 08:57:34 +1000

I mispoke.  ENOCOFFEE

That said there is still no logical reason to block EDNS version 1 queries
or queries with Z flag bits set.

Mark

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Sep 2014 18:43:28 +0300

John, Mark, Ross,

As you know, the IETF web services are provided through a combination of commercial services (secretariat services, service providers) and volunteer efforts (e.g., tools). In other words, no matter what we do, we actually delegate the task of providing the service to various other parties.

I think the right thing in this case is happening: we’ve learned of an issue with Tor, and both our network managers at AMS and Cloudfare are looking into it to determine what we can do. I think it is incredibly helpful to provide feedback on situations that do not work. Particularly on areas where technology is being pushed. Lets take this as an opportunity to do that. 

I can not promise that we can deal with all situations immediately, however. For instance, we know the provider is working hard on DNSSEC (as our request). And the IETF is a regular target of DoS attacks, and whether our services are run by ourselves or someone else, some tools are going to be needed to deal with those. 

Finally, the volunteer services. They run extremely well, but like commercial services, they are not perfect. Generally speaking, our volunteer services tend to migrate to officially maintained IETF services over time, and that is one opportunity to address additional needs. But a lot is done by volunteers, obviously! Hopefully you can participate the Code Sprint event, and possibly help address any issues within the volunteer servers.

In any case, I have reported both the EDNS0 issue and the User Agent string issue to the relevant folks.

Thanks,

Jari

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 18 Sep 2014 18:23:39 +0200

Hi John,

> behavior about a year ago.

If you want to be fair, you should also mention that I replied and explained
the issue.  And it's not a matter of needing to present an _acceptable_ 
User Agent, it's a matter of me having be forced to block some ill-behaved
robots that I only could identify by them not presenting any User Agent at all.

Regards,

	Henrik

---

From: John Kristoff <[email-masked]>
Date: Thu, 18 Sep 2014 13:00:26 -0500

On Wed, 17 Sep 2014 15:30:34 -0500
John Kristoff <[email-masked]> wrote:

> lot more particular about what your packets should look like. If you
> try to browse to tools.ietf.org without presenting an acceptable User
> Agent string you get a 403 forbidden.  I submitted a ticket about this

Sometimes it pays to publicly complain.  After seeing my list post,
Henrik Levkowetz informed me that he received the ticket and conveyed
the explanation for why tools.ietf.org behaves that way.

His remarks never made it through the initial front line support and
into the ticketing system back to me. I still don't like having my
browser being blocked like a bot, but I apologize to Henrik for
incorrectly implying the he or the tools team were unresponsive.
Email has its limitations.

John

---

From: Doug Barton <[email-masked]>
Date: Thu, 18 Sep 2014 11:38:51 -0700

> Finally, the volunteer services. They run extremely well, but like commercial services, they are not perfect. Generally speaking, our volunteer services tend to migrate to officially maintained IET…

Jari,

When the volunteer services are adequate to the task, all is well. When 
they are not, consideration has to be made to bring those services under 
the supported umbrella with haste. It's all well and good that this is 
in large part a volunteer organization, but if we're going to be taken 
seriously on the world stage things have to work, period. "But we're 
just a bunch of volunteers!" is not only not an adequate excuse, it's a 
serious negative in that space.

That said, I'm speaking generally; without any specific team, function, 
etc. in mind.

Doug

---

From: manning bill <[email-masked]>
Date: Thu, 18 Sep 2014 11:44:29 -0700

unstated is whom it is who decides “adequate”…  and your broad brush “world stage”  and the innuendo of “negative” perception appears to be FUD at best.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 18September2014Thursday, at 11:38, Doug Barton <[email-masked]> wrote:

> When the volunteer services are adequate to the task, all is well. When they are not, consideration has to be made to bring those services under the supported umbrella with haste. It's all well and good that this is in large part a volunteer organization, but if we're going to be taken seriously on the world stage things have to work, period. "But we're just a bunch of volunteers!" is not only not an adequate excuse, it's a serious negative in that space.
> 
> That said, I'm speaking generally; without any specific team, function, etc. in mind.
> 
> Doug
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Sep 2014 01:18:44 +0100

Doug,

Not attacking your POV, but I would like to try pose another perhaps
more positive take on this...

On 18/09/14 19:38, Doug Barton wrote:
> "But we're just a bunch of volunteers!" is not only not an adequate
> excuse, it's a serious negative in that space.

"We are volunteers and we work well and hard on stuff that we find
useful, (some of which has changed the world)" seems to me to be a
better characterisation of the situation and also something to shout
from an occasional rooftop. That others might not get or think badly
of that is frequently not our problem, and is often theirs. I figure
that applies to tooling just as much as the rest of what we do (when
we do it well:-)

Cheers,
S.

---

From: Doug Barton <[email-masked]>
Date: Thu, 18 Sep 2014 18:05:02 -0700

> that applies to tooling just as much as the rest of what we do (when

Your words are awesome, and well-stated. But tragically meaningless in 
the context of things like WSIS, IGF, etc. The governments and other 
entities that would like to control the Internet look for, and exploit, 
every weakness they can find to assert their claims, whether that's 
"fair" or not.

"The IETF is a professional, well-run organization that produces widely 
accepted standards on which the Internet operates. Many of its functions 
are performed by volunteers." That is a powerful, world-changing narrative.

"The IETF does the best it can with what it has, and we often do really 
cool stuff, plus we care, a super-duper lot!" doesn't even get you a cup 
of coffee.

It's fine and dandy for you to say "They just don't get it," and "That's 
their problem." My point is that it will, in time, become OUR problem, 
whether we want it to or not.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2014 21:34:22 -0400

On Sep 18, 2014, at 9:05 PM, Doug Barton <[email-masked]> wrote:
> Your words are awesome, and well-stated. But tragically meaningless in the context of things like WSIS, IGF, etc. The governments and other entities that would like to control the Internet look for, and exploit, every weakness they can find to assert their claims, whether that's "fair" or not.

We don't control the Internet.   Maybe NANOG et al. do, but we do not.   We just wrote some protocol specs that are key to the operation of the Internet.   The value proposition that keeps us relevant is continuing to do good work, not "controlling the internet."

---

From: Doug Barton <[email-masked]>
Date: Thu, 18 Sep 2014 19:07:42 -0700

On 9/18/14 6:34 PM, Ted Lemon wrote:
> We don't control the Internet.   Maybe NANOG et al. do, but we do not.

Reductio ad absurdum. There are no circumstances under which I want this 
bunch controlling the Internet. :)

> The value proposition that keeps us relevant is continuing to do good work

Um, yeah, that's pretty much my point.

The actual risk I'm attempting to raise awareness about is the fact that 
there are people out there who DO want to control the Internet; who 
think that the very concept of something so important being run by 
volunteers, "multi-stakeholder models," etc. is not only stupid, but 
dangerous; and will use any example of failure by those who comprise 
that model (partly, us) as a reason why they are right, and we are wrong.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 06:15:11 -0400

On Sep 18, 2014, at 10:07 PM, Doug Barton <[email-masked]> wrote:
> The actual risk I'm attempting to raise awareness about is the fact that there are people out there who DO want to control the Internet; who think that the very concept of something so important being run by volunteers, "multi-stakeholder models," etc. is not only stupid, but dangerous; and will use any example of failure by those who comprise that model (partly, us) as a reason why they are right, and we are wrong.

Haters gonna hate.   I don't think we (the IETF) can prevent this, although we can certainly make our positions clear and do our best to steer things in the right direction, as with the NTIA transition effort.   But if the worst thing that these folks can say about us is that our DNS setup on our CDN, like all other CDNS, is a bit weird, or that it requires Javascript captcha for suspect nodes, I don't think that's a problem: it's highly unlikely that their public-facing web presence is better than ours, although it may be prettier (or may not, depending on the SDO).

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Sep 2014 13:57:45 -0700

Hello,

The mailing list subscription confirmation notice currently shows an 
IP address assigned to the CloudFlare CDN network instead of the IP 
address from which the HTTP request originated.

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Sep 2014 13:58:45 +0200

> www.ietf.org.cdn.cloudflare.net.

When you get the CAPTCHA page, does it come with a non-2xx HTTP status code?
Best regards, Julian

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 25 Sep 2014 22:14:43 +0200

Julian Reschke <[email-masked]> wrote
Thu, 25 Sep 2014 13:58:45 +0200:

| When you get the CAPTCHA page, does it come with a non-2xx HTTP status code?
| Best regards, Julian

Yes, 403.

--8<---------------cut here---------------start------------->8---
$ curl -v -s -A '' -x socks4a://127.0.0.1:9050/ https://www.ietf.org/ > www.ietf.org.html
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* SOCKS4 communication to www.ietf.org:443
* SOCKS4a request granted.
* Connected to 127.0.0.1 (127.0.0.1) port 9050 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server key exchange (12):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*        subject: OU=Domain Control Validated; CN=*.ietf.org
*        start date: 2014-07-25 19:02:22 GMT
*        expire date: 2015-08-11 23:12:50 GMT
*        subjectAltName: www.ietf.org matched
*        issuer: C=US; ST=Arizona; L=Scottsdale; O=Starfield Technologies, Inc.; OU=http://certs.starfieldtech.com/repository/; CN=Starfield Secure Certificate Authority - G2
*        SSL certificate verify ok.
> GET / HTTP/1.1
> Host: www.ietf.org
> Accept: */*
< HTTP/1.1 403 Forbidden
* Server cloudflare-nginx is not blacklisted
< Server: cloudflare-nginx
< Date: Thu, 25 Sep 2014 20:09:34 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=df905f6d4fc2798f596872df7b98498501411675774571; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.ietf.org; HttpOnly
< Cache-Control: max-age=2
< Expires: Thu, 25 Sep 2014 20:09:36 GMT
< CF-RAY: 16f9dc37031e0c23-AMS
< 
{ [data not shown]
* Connection #0 to host www.ietf.org left intact
$ 
--8<---------------cut here---------------end--------------->8---

---

From: t.p. <[email-masked]>
Date: Fri, 26 Sep 2014 12:42:28 +0100

Is this why all the https:// ietf pages now give
'The page is not available'
on my elderly version of Internet Explorer?

I see no Captcha nor a status code.  I think that it was working in
August:-(

Tom Petch