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

["Adrien de Croy" <[e-mail]>]

>>   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?


Basically the client browser would be configured to

a) use a proxy and
b) understand that https via that proxy will have a specific cert at the 
root of the cert hierarchy

Kinda like cert pinning for a proxy.

How this is configured / bootstrapped is another matter.

But say we solve that problem, then the client can know nothing else is 
between it and the proxy for https.


>
>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.

fair enough.

It may even be possible to allow for an image in the json.  As long as 
it can't be an anchor, you can't present a fake site with it.


>
>>
>>  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.


It's kinda crazy that browsers, which are supposedly so 
security-conscious are still happy to download and evaluate javascript 
from some source they don't really verify (e.g. result of DNS lookup for 
WPAD or DHCP option 252).

An active attacker could very easily get themselves set up as the proxy 
by spoofing DHCP INFORM responses, or intercept requests to the WPAD 
server.

I wonder what restrictions there are on the code that may be evaluated 
in FindProxyForURL(...)

Adrien


>
>Amos
>
>