--===============5443949507881977805==
Content-Type: multipart/alternative;
boundary="------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44"
--------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Can you explain this further?
TLS is designed to provide data integrity and privacy, even in the
face
of man-in-the-middle attacks.
I don't know if dnsop is the place to rehash old arguments about
TLS=20
everywhere.
There are a few places in the archives of the http WG where it was=20
discussed heatedly (for IETF) at length, especially around the de
facto=20
implementation of mandatory TLS everywhere in the context of
http/2.0.
TLS was designed to provide data integrity and security, but not in
the=20
face of MitM attacks. The only way to prevent these is with cert=20
pinning (so the client can recognise a spoofed cert) or client
certs=20
which the intermediary can't spoof in a way that the server will
trust.
Google's push for https everywhere has in our experience provided=20
significant incentive for MitM deployment. We only added MitM
features=20
to WinGate because google and facebook went https-only. Prior to
that=20
it was hard to morally justify deploying a MitM to spy on people's=20
banking traffic.
The other significant driver we see of MitM deployment was the=20
deplorable decision by browser vendors that they would no longer
trust=20
non-200 responses to tunneling (CONNECT) requests. This meant the
only=20
way to not have an awful (support incident generating) user
experience=20
when blocking connections to https sites at a proxy, was to MitM
it,=20
receive the request and send back a block response masquerading as
the=20
server.
The irony of this is completely wasted on the people who made
these=20
decisions. The perceived threat was some page coming back from a=20
CONNECT request which could get a broken browser to follow a
redirect,=20
or display the body as if it came from the https server (thereby=20
allowing through broken browser design a masquerade opportunity). =20
Instead of actually fixing the browsers, they all (FF, Chrome and IE
and=
=20
probably others) chose instead to ignore the response, and show a=20
generic connectivity failure "friendly" page, which sends IT
support=20
people into a frenzy looking for broken network equipment. The
MitM=20
response to this requires the proxy to masquerade as the origin
server,=20
which was exactly the issue the browser authors were trying to avoid
by=20
deciding to ignore non-200 responses in the first place, meanwhile=20
causing proxy vendors and users significant pain.
As for the issue with captive portals. Since the client needs to=20
resolve names using DNS prior to making a connection, and since
the=20
captive portal will intercept port 80 and redirect it to a
challenge=20
page etc until the portal has been satisfied, you have a bit of a=20
chicken and egg problem. A browser won't try to connect if it gets
a=20
DNS lookup failure. DNS lookups will fail until the browser attempts
a=20
connection and authenticates with the captive portal. This is where
the=
=20
layering violation of DNS over HTTP is problematic.
It should be possible to detect that this is happening though, since
the=
=20
response won't contain an encapsulated DNS response in its message
body.=
=20
One option then could be to return some fake A record to the DNS=20
client, so that an attempt to connect will be made.
I rather think this will increase the attack surface area rather than
decreasing it, because now you have an additional place processing
DNS
packets.
My main concern was that the HTTP <-> DNS gateway was likely behind
the=20
firewall that was otherwise protecting the DNS server from malicious
DNS=
=20
packets. By putting in the gateway, you may be providing a back
door=20
for attacks on the DNS server. Sure, DNS servers should be
hardened,=20
but they may not realise they can't trust requests from the gateway.
Adrien
------ Original Message ------
From: "Shane Kerr" <sh...@time-travellers.org>
To: "Adrien de Croy" <adr...@qbik.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Sent: 5/05/2016 2:18:24 a.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for=20
draft-song-dns-wireformat-http-03.txt
>Adrien,
>
>Thanks for your comments.
>
>At 2016-05-03 05:14:31 +0000
>"Adrien de Croy" <adr...@qbik.com> wrote:
>
>> Some general comments:
>>
>> I don't think you can claim that https provides data integrity or
>> privacy any more, since MitM proxies are abundant.
>
>Can you explain this further?
>
>TLS is designed to provide data integrity and privacy, even in the
face
>of man-in-the-middle attacks.
>
>> I think some thought should be given to how a DNS stub might
deal=20
>>with a
>> captive portal or http proxy authentication.
>
>I guess this makes sense. I don't know that we can offer much help
>though. Perhaps something like this:
>
> A captive portal or any other middlebox that interferes with
HTTP
> may break this protocol, and DNS over HTTP will have to be
disabled
> until HTTP is restored.
>
>> I think also that any HTTP server that receives such a request=20
>>probably
>> ought to be validating the encapsulated binary data before
forwarding=
=20
>>it
>> to any DNS server.
>
>I rather think this will increase the attack surface area rather
than
>decreasing it, because now you have an additional place processing
DNS
>packets.
>
>> I wonder why you'd want to keep truncation, as the request should
be
>> able to benefit from the fact that fundamentally it's made over
TCP=20
>>to
>> the HTTP agent.
>
>If the client side is acting as a DNS proxy then we need to look
like
>DNS. The stub resolvers will send UDP packets and expect normal
>truncation behavior. While it may be possible for the client DNS
proxy
>to perform truncation and send responses back to the stub resolvers,
>this is a significantly more complicated design.
>
>> I would also suggest looking into how such requests might be best
>> blocked by an http proxy, because this will be a requirement of
proxy
>> operators, and it would be good to consider user experience for
when
>> this happens, so that a consistent approach can be taken (rather
than
>> every different proxy blocking it some other way so that the user
>> experience becomes awful).
>
>In the case of unencrypted HTTP (not recommended), then the proxy
can
>look for the well-known URI, right?
>
>In the case of TLS, then the proxy cannot block the traffic, can it?
It
>doesn't know the URI that the site is visiting, nor the contents of
the
>query or answer....
>
>Cheers,
>
>--
>Shane
--------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><style id=3D"eMClientCss">blockquote.cite { margin-left:
5px;=
margin-right: 0px; padding-left: 10px; padding-right:0px;
border-left: =
1px solid #cccccc }=0Ablockquote.cite2 {margin-left: 5px;
margin-right: =
0px; padding-left: 10px; padding-right:0px; border-left: 1px solid
#cccccc;=
margin-top: 3px; padding-top: 0px; }=0A.plain pre, .plain tt {
font-family=
: monospace; font-size: 100%; font-weight: normal; font-style:
normal;}=0A=
a img { border: 0px; }body {font-family: Tahoma;font-size:
12pt;}=0A.plain=
pre, .plain tt {font-family: Tahoma;font-size:
12pt;}=0A</style><style></s=
tyle>=0A<meta http-equiv=3D"Content-Type"
content=3D"text/html;charset=3D=
utf-8">=0A</head>=0A<body scroll=3D"auto"
class=3D""><div> </div><div>=
</div><div><span
id=3D"xc0cf9ede73494b998358d57572c98064"><tt><div>Ca=
n you explain this further?</div><div> </div><div>TLS is
designed to=
provide data integrity and privacy, even in the face</div><div>of
man-in-t=
he-middle attacks.</div></tt></span></div><div> </div><div>I
don't =
know if dnsop is the place to rehash old arguments about TLS
everywhere.</d=
iv><div> </div><div>There are a few places in the archives of
the http=
WG where it was discussed heatedly (for IETF) at length,
especially=
around the de facto implementation of mandatory TLS everywhere in
the cont=
ext of http/2.0.</div><div> </div><div>TLS was designed to
provide =
data integrity and security, but not in the face of MitM
attacks. =
The only way to prevent these is with cert pinning (so the client can
recog=
nise a spoofed cert) or client certs which the intermediary
can't spoo=
f in a way that the server will
trust.</div><div> </div><div>Google's=
push for https everywhere has in our experience provided significant
incen=
tive for MitM deployment. We only added MitM features to
WinGate beca=
use google and facebook went https-only. Prior to that it was
hard=
to morally justify deploying a MitM to spy on people's banking
traffic.&nb=
sp; </div><div> </div><div>The other significant driver we see
of MitM=
deployment was the deplorable decision by browser vendors that they
would=
no longer trust non-200 responses to tunneling (CONNECT)
requests. =
This meant the only way to not have an awful (support incident
generating)=
user experience when blocking connections to https sites at
a proxy,=
was to MitM it, receive the request and send back a block response
masquer=
ading as the server. </div><div> </div><div>The irony of
this=
is completely wasted on the people who made these decisions.
The =
perceived threat was some page coming back from a CONNECT request
which =
could get a broken browser to follow a redirect, or display the body
as =
if it came from the https server (thereby allowing through broken
browser=
design a masquerade opportunity). Instead of
actually fixing=
the browsers, they all (FF, Chrome and IE and probably others) chose
inste=
ad to ignore the response, and show a generic connectivity failure
"friendl=
y" page, which sends IT support people into a frenzy looking for
broken =
network equipment. The MitM response to this requires the proxy
to=
masquerade as the origin server, which was exactly the issue the
browser=
authors were trying to avoid by deciding to ignore non-200
responses=
in the first place, meanwhile causing proxy vendors and users
signifi=
cant pain.</div><div> </div><div>As for the issue with captive
portals=
. Since the client needs to resolve names using DNS prior to
making=
a connection, and since the captive portal will intercept port 80
and redi=
rect it to a challenge page etc until the portal has been satisfied,
you=
have a bit of a chicken and egg problem. A browser won't try
to conn=
ect if it gets a DNS lookup failure. DNS lookups will fail
until the=
browser attempts a connection and authenticates with the captive
portal.&n=
bsp; This is where the layering violation of DNS over HTTP is
problematic.<=
/div><div> </div><div>It should be possible to detect that this
is =
happening though, since the response won't contain an encapsulated
DNS resp=
onse in its message body. One option then could be to return
some =
fake A record to the DNS client, so that an attempt to connect will
be made=
.</div><div> </div><div><span
id=3D"xcb9999ba2d4841499709412d57cc6986"=
><tt><div>I rather think this will increase the attack surface area
rather=
than</div><div>decreasing it, because now you have an additional
place =
processing
DNS</div><div>packets.</div><div> </div></tt></span></div><=
div>My main concern was that the HTTP <-> DNS gateway was
likely behi=
nd the firewall that was otherwise protecting the DNS server from
malicious=
DNS packets. By putting in the gateway, you may be providing a
back=
door for attacks on the DNS server. Sure, DNS servers should
be hard=
ened, but they may not realise they can't trust requests from the
gateway.<=
/div><div> </div><div> </div><div>Adrien</div><div> </div><d=
iv> </div><div> </div><div> </div>=0A<div>------
Original=
Message ------</div>=0A<div>From: "Shane Kerr" <<a
href=3D"mailto:shane=
@time-travellers.org">sh...@time-travellers.org</a>></div>=0A<div>To:=
"Adrien de Croy" <<a
href=3D"mailto:adr...@qbik.com";>adr...@qbik.com</a=
>></div>=0A<div>Cc: "dnsop@ietf.org" <<a
href=3D"mailto:dn...@ietf.or=
g">dnsop@ietf.org</a>></div>=0A<div>Sent: 5/05/2016 2:18:24
a.m.</div>=
=0A<div>Subject: Re: [DNSOP] Fwd: New Version Notification for
draft-song-d=
ns-wireformat-http-03.txt</div><div> </div>=0A<div
class=3D"plain" =
id=3D"x9b5db85066b1495a90de3c5461bbe4a3"><blockquote class=3D"cite2"
cite=
=3D"20160504161824.25db8...@pallas.home.time-travellers.org"
type=3D"cite">=
=0A<tt><div>Adrien,</div>=0A<div> </div>=0A<div>Thanks for your
commen=
ts.</div>=0A<div> </div>=0A<div>At 2016-05-03 05:14:31
+0000</div>=0A=
<div>"Adrien de Croy" <<a
href=3D"mailto:adr...@qbik.com";>adr...@qbik.co=
m</a>> wrote:</div>=0A<div> </div>=0A<blockquote
class=3D"cite2"=
type=3D"cite">=0A<div> Some general
comments:</div>=0A<div> </di=
v>=0A<div> I don't think you can claim that https provides data
integr=
ity or</div>=0A<div> privacy any more, since MitM proxies are
abundant=
.</div>=0A</blockquote>=0A<div> </div>=0A<div>Can you explain
this =
further?</div>=0A<div> </div>=0A<div>TLS is designed to provide
data=
integrity and privacy, even in the face</div>=0A<div>of
man-in-the-middle=
attacks.</div>=0A<div> </div>=0A<blockquote class=3D"cite2"
type=3D=
"cite">=0A<div> I think some thought should be given to how a
DNS stub=
might deal with a</div>=0A<div> captive portal or http proxy
authenti=
cation.</div>=0A</blockquote>=0A<div> </div>=0A<div>I guess this
makes=
sense. I don't know that we can offer much help</div>=0A<div>though.
Perha=
ps something like
this:</div>=0A<div> </div>=0A<div> =
A captive portal or any other middlebox that interferes with
HTTP</di=
v>=0A<div> may break this protocol, and DNS
over =
HTTP will have to be
disabled</div>=0A<div> until=
HTTP is restored.</div>=0A<div> </div>=0A<blockquote
class=3D"cite2"=
type=3D"cite">=0A<div> I think also that any HTTP server that
receive=
s such a request probably</div>=0A<div> ought to be validating
the =
encapsulated binary data before forwarding it</div>=0A<div> to
any =
DNS server.</div>=0A</blockquote>=0A<div> </div>=0A<div>I rather
think=
this will increase the attack surface area rather
than</div>=0A<div>decrea=
sing it, because now you have an additional place processing
DNS</div>=0A=
<div>packets.</div>=0A<div> </div>=0A<blockquote class=3D"cite"
type=
=3D"cite">=0A<div> I wonder why you'd want to keep truncation,
as the=
request should be</div>=0A<div> able to benefit from the fact
that=
fundamentally it's made over TCP to</div>=0A<div> the HTTP
agent.</di=
v>=0A</blockquote>=0A<div> </div>=0A<div>If the client side is
acting=
as a DNS proxy then we need to look like</div>=0A<div>DNS. The stub
resolv=
ers will send UDP packets and expect normal</div>=0A<div>truncation
behavio=
r. While it may be possible for the client DNS proxy</div>=0A<div>to
perfor=
m truncation and send responses back to the stub
resolvers,</div>=0A<div>th=
is is a significantly more complicated
design.</div>=0A<div> </div>=
=0A<blockquote class=3D"cite2" type=3D"cite">=0A<div> I would
also =
suggest looking into how such requests might be
best</div>=0A<div> blo=
cked by an http proxy, because this will be a requirement of
proxy</div>=
=0A<div> operators, and it would be good to consider user
experience=
for when</div>=0A<div> this happens, so that a consistent
approach=
can be taken (rather than</div>=0A<div> every different proxy
blockin=
g it some other way so that the user</div>=0A<div> experience
becomes=
awful).</div>=0A</blockquote>=0A<div> </div>=0A<div>In the case
of=
unencrypted HTTP (not recommended), then the proxy
can</div>=0A<div>look=
for the well-known URI, right?</div>=0A<div> </div>=0A<div>In
the =
case of TLS, then the proxy cannot block the traffic, can it?
It</div>=0A=
<div>doesn't know the URI that the site is visiting, nor the contents
of=
the</div>=0A<div>query or
answer....</div>=0A<div> </div>=0A<div>Chee=
rs,</div>=0A<div> </div>=0A<div>--</div>=0A<div>Shane</div>=0A</tt>=
=0A=0A</blockquote></div>=0A</body></html>
--------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44--
--===============5443949507881977805==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--===============5443949507881977805==--
