Fwd: Call for Adoption: draft-song-dns-wireformat-http

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Fwd: Call for Adoption: draft-song-dns-wireformat-http

Tim Wicinski

Happy HTTP folks

This draft came up in Buenos Aires and there was interest in the group from contributing.  I was double booked in Berlin and wasn't able to attend, but mnot politely reminded me about this.

The draft went through adoption and has been adopted by DNSOP.  It's still can be worked on, and any and all comments on the ideas etc would be happily accepted.

thanks
tim
 
---------- Forwarded message ----------
From: Tim Wicinski <[hidden email]>
Date: Mon, Jul 11, 2016 at 6:33 PM
Subject: Call for Adoption: draft-song-dns-wireformat-http
To: dnsop <[hidden email]>


This starts an official Call for Adoption for
         draft-song-dns-wireformat-http

The draft is available here:
https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/

Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

We wanted this Call to coincide with the Berlin meeting so if there is opinions that needed to be voiced, they can do so.

This call for adoption ends: 25 July 2016

Thanks,
tim wicinski
DNSOP co-chair

Reply | Threaded
Open this post in threaded view
|

Re: Call for Adoption: draft-song-dns-wireformat-http

Martin Thomson-3
It would be really awesome if someone could summarize the reasons that
the alternative proposals (those cited in the doc) were not adopted.
I see a few red flags in the doc:

"The protocol is intended to serve as a sort of DNS VPN" -- there's a
long history of abuse of HTTP of exactly this form; probably because
it's easier.  See the above question regarding potentially better
alternatives.

"in this approach wire-format data is wrapped with a HTTP header and
transmitted on port 80 or 443."  -- two things: the wire format seems
to go in the body; and using port 80 is a terrible idea.

I don't see any reason that this needs to use a .well-known resource.

What happens when you get a response where the ID doesn't match the request?


On 3 August 2016 at 10:23, tjw ietf <[hidden email]> wrote:

>
> Happy HTTP folks
>
> This draft came up in Buenos Aires and there was interest in the group from
> contributing.  I was double booked in Berlin and wasn't able to attend, but
> mnot politely reminded me about this.
>
> The draft went through adoption and has been adopted by DNSOP.  It's still
> can be worked on, and any and all comments on the ideas etc would be happily
> accepted.
>
> thanks
> tim
>
> ---------- Forwarded message ----------
> From: Tim Wicinski <[hidden email]>
> Date: Mon, Jul 11, 2016 at 6:33 PM
> Subject: Call for Adoption: draft-song-dns-wireformat-http
> To: dnsop <[hidden email]>
>
>
> This starts an official Call for Adoption for
>          draft-song-dns-wireformat-http
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
>
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> We wanted this Call to coincide with the Berlin meeting so if there is
> opinions that needed to be voiced, they can do so.
>
> This call for adoption ends: 25 July 2016
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>

Reply | Threaded
Open this post in threaded view
|

Re: Call for Adoption: draft-song-dns-wireformat-http

Tim Wicinski
Martin,

I think one of the things which came up during the discussion was to drop port 80 all together. 

I'm circling back with the authors and I know we've covered this ground so I'll work with them to summarize.

There was another draft which discussed various methods of DNS over HTTP

We didn't choose to put it up for adoption, but it may be worthy to merge some of that into this document.

thanks
tim


On Tue, Aug 2, 2016 at 8:39 PM, Martin Thomson <[hidden email]> wrote:
It would be really awesome if someone could summarize the reasons that
the alternative proposals (those cited in the doc) were not adopted.
I see a few red flags in the doc:

"The protocol is intended to serve as a sort of DNS VPN" -- there's a
long history of abuse of HTTP of exactly this form; probably because
it's easier.  See the above question regarding potentially better
alternatives.

"in this approach wire-format data is wrapped with a HTTP header and
transmitted on port 80 or 443."  -- two things: the wire format seems
to go in the body; and using port 80 is a terrible idea.

I don't see any reason that this needs to use a .well-known resource.

What happens when you get a response where the ID doesn't match the request?


On 3 August 2016 at 10:23, tjw ietf <[hidden email]> wrote:
>
> Happy HTTP folks
>
> This draft came up in Buenos Aires and there was interest in the group from
> contributing.  I was double booked in Berlin and wasn't able to attend, but
> mnot politely reminded me about this.
>
> The draft went through adoption and has been adopted by DNSOP.  It's still
> can be worked on, and any and all comments on the ideas etc would be happily
> accepted.
>
> thanks
> tim
>
> ---------- Forwarded message ----------
> From: Tim Wicinski <[hidden email]>
> Date: Mon, Jul 11, 2016 at 6:33 PM
> Subject: Call for Adoption: draft-song-dns-wireformat-http
> To: dnsop <[hidden email]>
>
>
> This starts an official Call for Adoption for
>          draft-song-dns-wireformat-http
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
>
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> We wanted this Call to coincide with the Berlin meeting so if there is
> opinions that needed to be voiced, they can do so.
>
> This call for adoption ends: 25 July 2016
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>

Reply | Threaded
Open this post in threaded view
|

Re: Call for Adoption: draft-song-dns-wireformat-http

Martin Thomson-3
On 3 August 2016 at 10:47, tjw ietf <[hidden email]> wrote:
> There was another draft which discussed various methods of DNS over HTTP
> https://datatracker.ietf.org/doc/draft-shane-review-dns-over-http/
>
> We didn't choose to put it up for adoption, but it may be worthy to merge
> some of that into this document.

The questions that that document asks are the right ones, namely: what
is the purpose of the protocol?  Avoiding network errors is - at least
in my view - a poor reason to move to HTTPS.  How HTTP is used is one
issue that needs to be considered when choosing an approach;
draft-song doesn't really do that very well.

Reply | Threaded
Open this post in threaded view
|

Re: Call for Adoption: draft-song-dns-wireformat-http

Mark Nottingham-2
In reply to this post by Martin Thomson-3

> On 3 Aug 2016, at 2:39 AM, Martin Thomson <[hidden email]> wrote:
>
> It would be really awesome if someone could summarize the reasons that
> the alternative proposals (those cited in the doc) were not adopted.
> I see a few red flags in the doc:
>
> "The protocol is intended to serve as a sort of DNS VPN" -- there's a
> long history of abuse of HTTP of exactly this form; probably because
> it's easier.  See the above question regarding potentially better
> alternatives.

+1.

Would DNSOP consider alternative approaches if they were submitted soonish, or are you committed to using this document as a starting point?


>
> "in this approach wire-format data is wrapped with a HTTP header and
> transmitted on port 80 or 443."  -- two things: the wire format seems
> to go in the body; and using port 80 is a terrible idea.
>
> I don't see any reason that this needs to use a .well-known resource.
>
> What happens when you get a response where the ID doesn't match the request?
>
>
> On 3 August 2016 at 10:23, tjw ietf <[hidden email]> wrote:
>>
>> Happy HTTP folks
>>
>> This draft came up in Buenos Aires and there was interest in the group from
>> contributing.  I was double booked in Berlin and wasn't able to attend, but
>> mnot politely reminded me about this.
>>
>> The draft went through adoption and has been adopted by DNSOP.  It's still
>> can be worked on, and any and all comments on the ideas etc would be happily
>> accepted.
>>
>> thanks
>> tim
>>
>> ---------- Forwarded message ----------
>> From: Tim Wicinski <[hidden email]>
>> Date: Mon, Jul 11, 2016 at 6:33 PM
>> Subject: Call for Adoption: draft-song-dns-wireformat-http
>> To: dnsop <[hidden email]>
>>
>>
>> This starts an official Call for Adoption for
>>         draft-song-dns-wireformat-http
>>
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
>>
>> Please review this draft to see if you think it is suitable for adoption by
>> DNSOP, and comments to the list, clearly stating your view.
>>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> We wanted this Call to coincide with the Berlin meeting so if there is
>> opinions that needed to be voiced, they can do so.
>>
>> This call for adoption ends: 25 July 2016
>>
>> Thanks,
>> tim wicinski
>> DNSOP co-chair
>>
>

--
Mark Nottingham   https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

Poul-Henning Kamp
In reply to this post by Tim Wicinski
--------
In message <[hidden email]>, tjw ietf writes:

>Happy HTTP folks
>
>This draft came up in Buenos Aires and there was interest in the group from
>contributing.  I was double booked in Berlin and wasn't able to attend, but
>mnot politely reminded me about this.

That reminds me:

I should really try to get my IP-over-HTTP draft adopted.

(Yes: That was my way of saying:  What a horrible idea!)


--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

Re: Call for Adoption: draft-song-dns-wireformat-http

Tim Wicinski
In reply to this post by Mark Nottingham-2


On 8/3/16 7:09 AM, Mark Nottingham wrote:

>
>> On 3 Aug 2016, at 2:39 AM, Martin Thomson <[hidden email]> wrote:
>>
>> It would be really awesome if someone could summarize the reasons that
>> the alternative proposals (those cited in the doc) were not adopted.
>> I see a few red flags in the doc:
>>
>> "The protocol is intended to serve as a sort of DNS VPN" -- there's a
>> long history of abuse of HTTP of exactly this form; probably because
>> it's easier.  See the above question regarding potentially better
>> alternatives.
>
> +1.
>
> Would DNSOP consider alternative approaches if they were submitted soonish, or are you committed to using this document as a starting point?
>

Alternative Approaches are always welcome.

tim

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

Patrick McManus-3
In reply to this post by Poul-Henning Kamp

On Wed, Aug 3, 2016 at 7:21 AM, Poul-Henning Kamp <[hidden email]> wrote:
should really try to get my IP-over-HTTP draft adopted.

(Yes: That was my way of saying:  What a horrible idea!)


weirdly, with h2 push the mapping is pretty straight forward. Still a bad idea as you say ;)

of course, IP-over-DNS is a typical desperate tunnel of last result to run https.. combined with dns over h2 that could give you h2-over-tls-over-tcp-over-ip-over-dns-over-h2-over-tls-over-tcp-over-ip. I'm sure that would be totally fine from a congestion and flow control pov :(

Mostly, I jest. Like many others I would like to see some standardized support for DNS transported in HTTP. There are a lot of different use cases that have already been discussed in this thread, but one that has come up in the past and is so far missing would be priming the local HTTP agent for anticipated cross origin resolutions (obviously with appropriate certificates attached). I'll send a different email.


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

Poul-Henning Kamp
--------
In message <CAOdDvNqX438A48aWf8x=[hidden email]>, Patrick McManus writes:

>of course, IP-over-DNS is a typical desperate tunnel of last result to run
>https.. combined with dns over h2 that could give you
>h2-over-tls-over-tcp-over-ip-over-dns-over-h2-over-tls-over-tcp-over-ip.
>I'm sure that would be totally fine from a congestion and flow control pov :(

It would be *so* much more productive to try to tackle these problems
as the political human-rights issues they are, than stacking boxed higher
and higher trying to cross over the walls people erect.

The one sure result from tunnelling more and more through HTTPS is that
HTTPS will be MiTM'd and blocked more and more.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Reply | Threaded
Open this post in threaded view
|

Re: Call for Adoption: draft-song-dns-wireformat-http

Patrick McManus-3
In reply to this post by Tim Wicinski

On Wed, Aug 3, 2016 at 7:11 AM, Tim Wicinski <[hidden email]> wrote:
Alternative Approaches are always welcome.

As an aside, I thought draft-shane was very interesting - thanks for mentioning it here.

Here's what I have heard as "requirements" around dns in http in the past:

* a standard application developer api for lookup. Often expressed as REST/JSON
* a standard application developer api for publishing changes. Often expressed as REST/JSON
* a tunnel for the DNS protocol
* a push mechanism for broadcasting DNS info relevant to the http connection
* solid integration with HTTP caches

I know there have been a number of json-ification discussions in the past. Maybe its time to roll those, the DNS expertise, and the HTTP expertise into a unified effort? It seems this is an easy space to accidentally partition out to its own domain experts and end up with something that isn't satisfying to the whole. I would hope to avoid that. Tim, what are your thoughts on that?

Doing that is certainly a more ambitious project than just tunneling an existing protocol, but I think its potential impact is much bigger - especially if it gets the right people in the room.

In addition to the differing sets of requirements, I think there are different perspectives on eco-system and security impacts to be had.

-Patrick

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

Adrien de Croy
In reply to this post by Poul-Henning Kamp

In our customer base, the biggest driver to deploy MitM is the refusal
of browsers to display block pages from denied CONNECT requests.

------ Original Message ------
From: "Poul-Henning Kamp" <[hidden email]>
To: "Patrick McManus" <[hidden email]>
Cc: "tjw ietf" <[hidden email]>; "HTTP Working Group"
<[hidden email]>
Sent: 4/08/2016 2:25:44 AM
Subject: Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

>--------
>In message
><CAOdDvNqX438A48aWf8x=[hidden email]>,
>Patrick McManus writes:
>
>>of course, IP-over-DNS is a typical desperate tunnel of last result to
>>run
>>https.. combined with dns over h2 that could give you
>>h2-over-tls-over-tcp-over-ip-over-dns-over-h2-over-tls-over-tcp-over-ip.
>>I'm sure that would be totally fine from a congestion and flow control
>>pov :(
>
>It would be *so* much more productive to try to tackle these problems
>as the political human-rights issues they are, than stacking boxed
>higher
>and higher trying to cross over the walls people erect.
>
>The one sure result from tunnelling more and more through HTTPS is that
>HTTPS will be MiTM'd and blocked more and more.
>
>--
>Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>[hidden email]         | TCP/IP since RFC 956
>FreeBSD committer       | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by
>incompetence.
>


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

Nicolas Mailhot
Same here, no block pages -> MITM

--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Reply | Threaded
Open this post in threaded view
|

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

Mark Nottingham-2
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 <[hidden email]> wrote:
>
> Same here, no block pages -> MITM
>
> --
> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.


Reply | Threaded
Open this post in threaded view
|

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

Adrien de Croy

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" <[hidden email]>
To: "Nicolas Mailhot" <[hidden email]>
Cc: "Adrien de Croy" <[hidden email]>; "Poul-Henning Kamp"
<[hidden email]>; "Patrick McManus" <[hidden email]>; "HTTP
Working Group" <[hidden email]>
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
>><[hidden email]> wrote:
>>
>>  Same here, no block pages -> MITM
>>
>>  --
>>  Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma
>>brièveté.
>
>


Reply | Threaded
Open this post in threaded view
|

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

Nicolas Mailhot
In reply to this post by Mark Nottingham-2


----- Mail original -----
De: "Mark Nottingham"
Objet: 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.

For private proxies it would help. Corps would probably be ok with dumping proxy page chrome as long as it is encrypted to avoid spoofing, the user agent warns if the cert changes, and browsers do not do the usual "end of the world" generic message

It's still missing a huge part however: proxy auth. There is no wish to allow a random attacker to drill through corp firewalls just by plugging a gadget on a free ethernet port

I don't see it work for public commercial captive portals (without necessary a proxy behind) such a the one I'm currently using. Those guys want to display their brand proheminently if only to tell people "look, if you was my customer, you could use the free-for-my-customers hotspot I deployed deep in this remote place" (which means auth again to prove you are a customer or paid a on-off fee, + reauth because reception of such hotspots is flacky and the connexion needs restablishing every time you move out of range).

As for the "but banks" objections it would be time for browsers people to realise banks do *not* design their sites any different than otherq, and all the efforts those past years to allow http mashups, third party adds, tracking cookies mean there is no way to check bank web sites anymore. They now call third-party js, add agency, just like the others. They may lag a little (on-two years) but the result is the same.

It is not possible to promote hoplessly insecure practices for some sites and hope they won't spread.

Reply | Threaded
Open this post in threaded view
|

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

Amos Jeffries-2
In reply to this post by Adrien de Croy
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


Reply | Threaded
Open this post in threaded view
|

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

Walter H.
In reply to this post by Mark Nottingham-2
On 06.08.2016 02:25, Mark Nottingham wrote:
Would this help?

https://mnot.github.io/I-D/proxy-explanation/

Keep in mind that only helps for configured proxies. 

configured proxies are not the bug; why not just simpy use plain HTML?

your sample chould then just be this simple:

HTTP/1.1 403 Forbidden
Content-Type: text/html
Cache-Control: no-cache

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Policy Violation</TITLE>
/HEAD>
<BODY>
<H1>Policy Violation</H1>
<UL>
<LI>This content is above your pay grade. <A HREF="https://acme.example.com/why?https://www.example.net">More Info</A>.
</LI>
</UL>
<HR>
<ADDRESS>Acme Networks Proxy</ADDRESS>
</BODY>
</HTML>

is this really a disadvantage doing it this way? and if yes, why?

without having the signing certificate used by the proxy installed in the certstore of the client
the "new way" have no advantages;

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Kari Hurtta
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0390.html

> configured proxies are not the bug; why not just simpy use plain HTML?
>
> your sample chould then just be this simple:
>
> HTTP/1.1 403 Forbidden
> Content-Type: text/html
> Cache-Control: no-cache
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <HTML>

Major browsers do not show this when they get
that on response of CONNECT -request.

Bug 637619 - Display better error messages when HTTPS proxy servers return non-200 error codes
https://bugzilla.mozilla.org/show_bug.cgi?id=637619

/ Kari Hurtta


Reply | Threaded
Open this post in threaded view
|

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

Ilari Liusvaara-2
In reply to this post by Walter H.
On Sun, Aug 07, 2016 at 07:25:22PM +0200, Walter H. wrote:
> On 06.08.2016 02:25, Mark Nottingham wrote:
> > Would this help?
> >
> > https://mnot.github.io/I-D/proxy-explanation/
> >
> > Keep in mind that only helps for configured proxies.
> >
> configured proxies are not the bug; why not just simpy use plain HTML?
 
Except that if you try rejecting the CONNECT, the browsers just throw
up generic error about connection failed and will just plain discard
any payload the proxy sends.

(And pretty much the same for non-browsers, if those even support
CONNECT).


And for http://, yes, the page will be displayed in browsers,
but authority of response will be misinterpretted, creating other
problems. In non-browsers, this can really create a mess.


-Ilari

Reply | Threaded
Open this post in threaded view
|

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

Walter H.
In reply to this post by Kari Hurtta
On 07.08.2016 19:50, Kari hurtta wrote:

> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0390.html
>
>> configured proxies are not the bug; why not just simpy use plain HTML?
>>
>> your sample chould then just be this simple:
>>
>> HTTP/1.1 403 Forbidden
>> Content-Type: text/html
>> Cache-Control: no-cache
>>
>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>> <HTML>
> Major browsers do not show this when they get
> that on response of CONNECT -request.
which in fact is caused by something different - my MITM proxy generates
errors that are shown by my browser;
and these errors are simple HTML

a MITM proxy uses a certificate for signing sites ...

e.g. the proxy uses a certificate called  Proxy-CA, then for every site
you want to go to there will be a created a SSL certificate which is
signed by Proxy-CA;
if the Proxy-CA was signed by a CA that is a built in token in the
certstore of your browser or you have installed the Proxy-CA certificate
in the certstore yourself, then your browser will show this simple HTML
error page the proxy is sending;


> Bug 637619 - Display better error messages when HTTPS proxy servers return non-200 error codes
> https://bugzilla.mozilla.org/show_bug.cgi?id=637619
this is not really bug - it was filed at the times the browser (firefox)
starts warning for invalid or self signed certificates ...
with mnot's "solution" ths would be same;

so where is the advantage of this?



smime.p7s (5K) Download Attachment
123