Subject: [dns-privacy] A depraved test

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Jan 2015 22:31:32 -0500

HI there all.

I've created a quick and dirty test to try and get a better handle on
what middleboxes will do with non-DNS traffic on port 53.[0]

This is simply a webserver that listens on TCP port 80 and TCP port
53. It also includes the IP address it thinks you came from (just in
case some extra bizarre middlebox forwards all port 53 to some other
address than it NATs you to...)

Anyway, I turned it up, and pointed Chrome at
http://dpraved.snozzages.com:80/ and everything worked...
I then browsed to http://dpraved.snozzages.com:53/ and got a failure.
I figured this was a useful result - it looked like the middlebox /
NAT I was behind blocked non-DNS on TCP53... and then I looked at the
error message. Chrome was claiming:
"The webpage at http://dpraved.snozzages.com:53/ might be temporarily
down or it may have moved permanently to a new web address.
Error code: ERR_UNSAFE_PORT"

Odd. So I tried it in Safari, and got:
""Not allowed to use restricted network port" (WebKitErrorDomain:103)"

Apparently browsers prevent you from browsing to some subset of ports
for some security reason (which I haven't bothered looking into). You
can override this behavior by passing some flags to the browser on the
CLI, or just use lynx, curl or wget...

Anyway, if you would like to test and see if your CPE / NAT /
middlebox futzes with non-DNS traffic on port 53, run something like:

curl  http://dpraved.snozzages.com:53

Please report back the results if you do test. I think having some
data on how well things like TLS will traverse CPE on port 53 will be
useful / interesting...

W

[0]: I decided to attend an IEEE meeting to see what they are like. I
ended up playing with dprive testing and learning 'docker'. Make of
that what you will :-)
Actually, so far it has been really interesting, and the too have cookies...

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Jan 2015 20:43:06 -0800

> data on how well things like TLS will traverse CPE on port 53 will be

If that's what you want, then you need to run TLS on that port, not HTTP. You apparently aren't doing that, so people getting negative results will think that they are being blocked when in fact you set the test up incorrectly.

It is great that people want to do tests. Can we maybe agree to the test methodology before people start saying "this shows that doesn't work"?

--Paul Hoffman

---

From: David Dagon <[email-masked]>
Date: Tue, 13 Jan 2015 05:50:05 -0500

> ""Not allowed to use restricted network port" (WebKitErrorDomain:103)"

This is to prevent a species of abuse generally called the 'HTML Form
Protocol Attack':

  http://www.remote.org/jochen/sec/hfpa/hfpa.pdf

  http://www.kb.cert.org/vuls/id/476267

This technique was used by spammers, who would craft textarea content
(via js/onclick(), etc.) to match valid SMTP commands, and direct the
submit stream to a user's internal host:25, etc., to generate spam
messages from the user's networks.  The SMTP protocol was forgiving of
the non-valid html-derived portions of the mime stream (500 error),
and accepted the attacker's crafted textarea content---pill ads, virus
attachments, and other spam.

There was a fair amount of this type of spam in '06 or so, but it
required enticing local users to interact with a webpage.  This could
be done, but the technique was less virulent than a simple spamming
virus.  

Other mischief was soon discovered, however, and branded by the
security research community as "HFPA".  Demonstrations included
actions such as deleting mail spools and contacting IRCd servers, etc.
Properly branded, with a whitepaper no less, this was now an actual
security problem, as opposed to 'just lots of spam and viruses'
emanating from user networks.  So browser vendors finally responded by
restricting what pages browsers may use.  That's what you're now
measuring with your site.

I'm curious about the purpose of your study.

I suggest a larger-scale test could be accomplished by a 302 redirect
from an http-based botnet sinkhole, forcing tens of thousand of
victims (otherwise destined for $SINK:80 or $SINK:443) to reconnect to
$SINK:53.  This would avoid the browser HFPA restrictions, since most
malware just makes use of OS-based http libraries, which are generally
not restricted.  (And those viruses that don't use stock http libs
generally don't bother to implement 301/302 redirects.)  

This could be used to test, for example, whether victim origin
networks perform DPI or otherwise restrict non-DNS traffic over
tcp/53.  The measured output would be only the loss of the connection.
But since bots repeatedly reconnect, the eventual redirection of the
user to $SINK:80, post treatment, would let one infer that some
network edge/DPI device had interceded for $SINK:53 traffic.

Since the bots are passive participants in the study, and it is
otherwise impossible to get insights about their network (or even,
say, get the users to goddamn patch their machines), the only measured
effect would be the connect/no-connect patterns to successive 302s to
$SINK:53 and $SINK:80, pre- and post-treatment.

Since many victims are present in some networks, one could respond
selectively with 302s for $SINK:53 and $SINK:80 per CIDR.  One might
break victims into a solomon four group study set, randomized within
each containing prefix into one of four groups.  These groups would
receive either $SINK:53 or $SINK:80 treatments, three reconnection
time periods (t0, t1, t2) carefully chosen to avoid DHCP churn events.
(Say, if |t2 - t0| < 2 hours, there's low risk of DHCP-induced loss of
subsequent connections).

      t0             t1              t2
  A:  $SINK:80-pre,  $SINK:53-test,  $SINK:80-post
  B:  $SINK:80-pre,                  $SINK:80-post
  C:                 $SINK:53-test   $SINK:80-post
  D:                                 $SINK:80-post

(Blanks are 404 events, most likely).

The study group design would allow one to reason about network
filtration of non-DNS traffic over tcp/53, even without the ability to
contact large numbers of victims to inquire about their network
policies (of which they likely know little), and also reason about
other "what if" confounding factors.  (E.g., no doubt some traffic
will be stopped, since it originates from malware attempting to reach
the $SINK, and the solomon groups will let one measure this directly.)

Finally, since this only characterizes tcp/53 connections, one could
reason about corresponding udp/53 management by focusing on those
hosts using local (defined as "in-prefix") DNS recursives, uniquely
noted by randomizing the child labels under $SINK, e.g.,
$HASH(host).$SINK, similar to sinkdns and other dnspath measurement
projects.  The authority for the $SINK child zones could be configured
to only respond on tcp/53 (e.g., a CNAME with no additional fields,
and TC=1, perhaps, to invite tcp/53 retries).  For each such
variation, one would create yet another solomon grouping, within each
test group noted above.  (With millions of infected hosts on the
Internet, there's no danger of small sample sizes for large numbers of
test factors.)

But what are you trying to measure?  Since this mailing list is about
DNS privacy, I assume you're trying to measure policy
frameworks/filters used by various networks---filters and such.  If
so, you might begin with a survey of vendor appliances that enable
such policies.  It might be easier to survey for such devices, or
iteratively discover cache records uniquely related to their
operation/update.  I don't think HFPA browser port restrictions are a
type of censorship (though they did break some banks in the early
days.)

-- 
David Dagon
[email-masked]
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Jan 2015 08:35:22 -0500

> It is great that people want to do tests. Can we maybe agree to the test methodology before people start saying "this shows that doesn't work"?

Yup, I'll be happy to agree that doing this over TLS would have been
better - however, all I wanted as a quick and dirty, rough idea of
what we are looking at. So far I have gotten 6 (off-list) responses,
all of whom say that things worked just fine for them. To be honest,
this is not what I was expecting - I was thinking (from previous
testing of what CPE does to DNS itself) that we'd see more examples of
CPE doing funny things, and could then investigate those further.

I was originally hoping to make this into a real test, and ask Geoff
Huston to run on of his experiments using ads to get a wide scale
test. Unfortunately browsers refusal to fetch things from port 53
makes this unlikely to work.

So, yeah, crap test, but still interesting. When / if we find people
who are unable to fetch this, we can try it over TLS, figure out what
middlebox is breaking things, etc.

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jan 2015 10:14:43 -0500

On Mon, Jan 12, 2015 at 11:43 PM, Paul Hoffman <[email-masked]>
wrote:

> If that's what you want, then you need to run TLS on that port, not HTTP.
> You apparently aren't doing that, so people getting negative results will
> think that they are being blocked when in fact you set the test up
> incorrectly.
>
> It is great that people want to do tests. Can we maybe agree to the test
> methodology before people start saying "this shows that doesn't work"?

Why are we talking port 53 at all?

Well Known Port numbers were the original discovery mechanism for a
service. They are not a very good mechanism and not the one that is
relevant for the purpose of establishing a client-resolver connection.

We are going to end up with two DNS client resolver protocols

* Legacy, unencrypted
* Encrypted

The two will be incompatible in that it will be impossible for any legacy
client (or for that matter any client without the right key) to understand
the new protocol.

Ergo there must be some form of upgrade mechanism, whether in band or out
of band that allows a client to know to use the new protocol. And any
mechanism that can carry the information 'I do DPRIV' can at least in
theory carry 'I do DPRIV on port X'.

Now we might have use for port 53 in the upgrade mechanism. But I see that
as being a one time event. If my machine gets an OS upgrade to support
DPRIV, it might notice that my DNS server on 6.6.6.6 is sending out an
additional RR for a DPRIV service.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 14 Jan 2015 09:18:54 +0100

On Mon, Jan 12, 2015 at 10:31:32PM -0500,
 Warren Kumari <[email-masked]> wrote 
 a message of 56 lines which said:

> Chrome was claiming: "The webpage at
> http://dpraved.snozzages.com:53/ might be temporarily down or it may
> have moved permanently to a new web address.  Error code:
> ERR_UNSAFE_PORT"

Explanations in
<http://www-archive.mozilla.org/projects/netlib/PortBanning.html>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Jan 2015 11:24:59 -0500

> middlebox is breaking things, etc.

... and if folk would like to test TLS:
lynx https://dpraved-ssl.snozzages.com:53
or:
get -O- --no-check-certificate  https://dpraved-ssl.snozzages.com:53
or
openssl s_client -connect dpraved-ssl.snozzages.com:53
GET / HTTP/1.0

Note that this is still a crap test, but at least it it somewhat
closer to what traffic might look like...

http://i.imgur.com/YBa9VD2.jpg

W