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

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)

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.

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.

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.  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.  E.g. tie the 
proxy configuration to the root of the cert tree - again this would only 
work for non-intercepted.

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.

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.

Cheers

Adrien

------ Original Message ------
From: "Mark Nottingham" <mnot@mnot.net>
To: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
Cc: "Adrien de Croy" <adrien@qbik.com>; "Poul-Henning Kamp" 
<phk@phk.freebsd.dk>; "Patrick McManus" <pmcmanus@mozilla.com>; "HTTP 
Working Group" <ietf-http-wg@w3.org>
Sent: 6/08/2016 12:25:56 PM
Subject: MITM and proxy messages [was: Call for Adoption: 
draft-song-dns-wireformat-http]

>Would this help?
>
>https://mnot.github.io/I-D/proxy-explanation/
>
>Keep in mind that only helps for configured proxies.
>
>Sent from my iPhone
>
>>  On 5 Aug 2016, at 1:06 AM, Nicolas Mailhot 
>><nicolas.mailhot@laposte.net> wrote:
>>
>>  Same here, no block pages -> MITM
>>
>>  --
>>  Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma 
>>brièveté.
>
>

Received on Saturday, 6 August 2016 21:48:50 UTC