Adrien, subtle font changes do not make for good communications.
Try reading the text/plain and see you can work out what points you
are trying to make.
Mark
In message <emaff75e18-2469-4abc-b7be-7456e3986423@bodybag>, "Adrien de Croy"
writes:
>
> --===============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==--
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
