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
everywhere.
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 context of http/2.0.
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 recognise a spoofed cert) or client certs
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
significant incentive for MitM deployment. We only added MitM features
to WinGate because 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.
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 masquerading as the
server.
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 instead to ignore the response, and show a
generic connectivity failure "friendly" 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 significant pain.
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 redirect 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 connect if it gets a
DNS lookup failure. DNS lookups will fail until the browser attempts a
connection and authenticates with the captive portal. This is where the
layering violation of DNS over HTTP is problematic.
It should be possible to detect that this is happening though, since the
response won't contain an encapsulated DNS response 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.
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
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 hardened,
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
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
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
probably
ought to be validating the encapsulated binary data before forwarding
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
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
