Re: MITM and proxy messages [was: Call for Adoption: draft-song-dns-wireformat-http]

On 7/08/2016 9:45 a.m., Adrien de Croy wrote:
> 
> Hi Mark
> 
> thanks for putting that together, it looks interesting.
> 
> My gut feel is that customers will continue to wish to present their own
> content/page to blocked users, containing things such as
> 
> * company and/or jurisdictional boilerplate / warnings etc
> * branding
> * organisation-specific links (e.g. to more info on policy, or request
> form to remove entry from block-list)

You can drop the first. Any variantions from the plain free-form text
paragraph offered by the template will invariably derive from branding
and PR marketing requirements.

You can drop the last. URL is already included. Variations might require
several (but wy when one can link to others?) or again tie back to some
branding PR marketing policy.

So, branding and marketing, branding, or marketing and branding. Take
your pick.

> 
> One other issue looming is that of the captive portal, which generally
> requires that the initial conversation use http/1.1 over port 80.  as
> more things move to https, this becomes more difficult.
> 
> So the ability to advertise a captive portal would be useful to add to
> this draft.
> 

I was just thinking 511 status needs adding to the list of recommended
responses to use the template with, to promote it a bit more.


> Then finally the issue around intercepted connections.  I really can't
> see these going away.
> 
> As far as the draft goes, I still don't really buy that browser vendors
> couldn't portray a block page in a way that is unambiguously NOT the
> target site - e.g. that cannot be made to look like or behave like the
> banking site (pop it in a dialog for example).  I think a little more
> commitment and imagination could have resolved this problem and not
> caused the large amount of pain that the chosen expedient path has ended
> up causing.
> 
> For a 30x response to CONNECT we need to decide whether such a thing
> makes any logical sense or even should be permitted.
> 

I can imagine it possibly being useful in the WebSockets CONNECT
responses. Based on prior Alt-Svc knowledge.

In HTTP it makes little sense. Even a 4xx with Alt-Svc does a bit better
logically.

I have been encouraging people to use 511 instead of any 30x they may be
tempted by. Last I heard there was no noticable browser support, so both
work equally badly there. But at least they will be ready when 511
arrives and is working for some other client tools already.


> You can't MitM from an unknown source without causing at least
> certificate warnings - with HSTS this is a show-stopper for an active
> network attacker, unless they intercept the very first request to that
> site.

I thought that too until last year. Without pinning and similar CA
restrictions HSTS can be blown away as easily as NAT'ing port 443. When
pinning is used, the flag which HSTS sets dynamically might as well be
part of the pinned data, not wasting space in each HTTP(S) message.


>  Sanctioned MitM in an organization can currently only be
> distinguished from end-to-end encryption by inspecting the certificate
> chain, and this is a crime against users, it should be simple to make it
> obvious to users when their https is being inspected.

This is the major reason I still like DANE. Anyone can check the domains
official CA certs tree and compare. Even if they have something saying
they have to trust this unexpected CA, clients can at least see that A != B.


>  E.g. tie the
> proxy configuration to the root of the cert tree - again this would only
> work for non-intercepted.

Hmm. Can you elaborate please about how that tie would work?

For some reason I think you mean something other than DNS WPAD with DANE
to verify the hostname from which to send a secret client-key (encoded
to that hosts DANE provided public host-key) and fetch a
Content-Encoded:aesgcm PAC-like file encoded to the secret client-key.


> 
> So I'm a little on the fence on this proposal for browsers, but for
> other agents, I think the machine-readable information could be very
> useful, so overall I'm in favour of such an approach. It could however
> alternatively be transported in a header, leaving the body for
> customization by the organization.

I expect that would lead to just as many complaints asking about why
their fancy body got ignored. If fancy body is possible, or even hinted
at being possible. It will be mandatory required somewhere for what turn
out to be marketing reasons.

> 
> One thing I would love to see more work done in is proxy discovery. 
> Many many of our users want to use interception, so they can avoid the
> deployment issues.  WPAD goes some of the way, but there are still
> problems with that.
> 
> If we continue to just wish that connection interception and MitM will
> just go away, we won't improve things for users.  There should be a way
> for a intercepting proxy to safely (from a client POV) impose itself
> with full knowledge and assent of the client.
> 

Aye. See above. The major parts are finally falling into place, but
there are still some holes to plug.

Amos

Received on Sunday, 7 August 2016 17:36:46 UTC