Subject: Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt

From: Kari Hurtta <[email-masked]>
Date: Tue, 01 Mar 2016 05:23:21 +0000

>> 
>> At the end of the day, an intercepting proxy can already inject
>> anything into an unencrypted payload anyway, so I'm not sure this use
>> case is going to be interesting. 
>> 
>> I'm sure some intercepting proxy folks would like to show something
>> like this to the user for an encrypted stream, but that seems well out
>> of scope for this spec. Anyway, having a mechanism for the proxy to
>> talk to the user when it's legitimately configured instead of
>> intercepting might encourage more people to deploy non-intercepting
>> proxies :)
>> 
>> So, I think I'll adjust the language in the draft to make this
>> specific to CONNECT.
> 
> This is only for https ?
> 
> Otherwise when browser is configured to use proxy and 
> URL is http, browser do not use CONNECT but original
> http -method (GET and so on). Given url just is
> absolute.
> 
> Of course on http -case browser already shows
> error response  (when it is html).
> 
> It is strange if browser shows proxy 
> response when it is text/html, but not 
> if it is application/proxy-explanation+json
> 
> ( That is situation when that media type 
>  is restricted to CONNECT and browser shows 
>  other error responses anyway for 
>  http: -urls when CONNECT is not used. )
> 
> You perhaps want limit that for CONNECT
> -usage when url is https -- And no
> limitation when url is http 
> (encrypted (i.e. Alt-Svc) or not) ?

Or limit to case where proxy is configured
to be used and http error status is given
(not succeed code).

When CONNECT is not used (unencrypted http)
and browser is configured to proxy,
browser does not know is response
from original server or from proxy.

( If application/proxy-explanation+json
 is not shown for http -urls
 in case of non-intercepting proxies,
 it is not really encouraging. )

If proxy uses application/proxy-explanation+json
for CONNECT, then it make sense to use
application/proxy-explanation+json for other
types (specially GET) also (if browser
indicates that it supports 
application/proxy-explanation+json )
because that unifies user experiense
between http and https -urls.

( when https error response
 proxy can not really emulate
 same experience )

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 01 Mar 2016 05:08:28 +0000

This is only for https ?

/ Kari Hurtta

 ( just reading
   https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/index.html
 )

---

From: "Thomas Mangin" <[email-masked]>
Date: Tue, 01 Mar 2016 15:32:22 +0000

>> http -method (GET and so on). Given url just is

Client implementations are able to use CONNECT when requesting HTTP 
through a proxy but the major implementations choose not to do so.
Changing this behaviour is probably inadvisable as current proxies will 
most likely simply drop the connection when getting a CONNECT message 
for HTTP page.

And while the feature is most useful for CONNECT with HTTPS, and while 
it is likely that some proxies will continue to prefer ‘branded’ 
HTML pages, allowing the use of this answer on non CONNECT request may 
also hold value as promoting homogeneity to the user experience between 
HTTP and HTTPS.

Thomas

---

From: "Thomas Mangin" <[email-masked]>
Date: Wed, 02 Mar 2016 09:25:06 +0000

Hi Kari,

I can see value in using a ‘secret’ between the client and proxy to 
validate the source of the reply.

If used with the CONNECT verb, there is no risk of the header carrying 
this information to be be passed on to the origin. However, if allowed 
through HTTP, any header would pass through towards the origin and then 
could be used by another non-configured proxy down the line. This could 
be mitigated by mandating a draft aware proxy to block any 
json+explaination response messages coming back towards the client.

Obviously this would not protect the client if a MITM attack is 
performed between the client and the proxy (i.e. most likely within the 
LAN where it should be mitigated at network level), but it would prevent 
interference ‘down the line’ where interference risks are greater.

Alternatively, draft support for HTTP could be negotiated using a 
message, using a new verb or muffing the semantic of an existing one 
like OPTIONS, the client is able at any time to issue a new command to 
renew the secret. In this scenario, the header would only be included if 
support is negotiated.

Thomas

> Register new header field for that nonce.
>
> Browser may include that on request when it is using proxy:
>
> New-header-field: nonce-value
> Connection: new-header-field
>
> Connection header field prevents origin server seeing
> this (if proxy follows HTTP/1.1 -- I do not know how
> this play with HTTP/2, but HTTP/2 is likely to be used
> only  with encrypted connections / with CONNECT method. )
>
> Given nonce-value can be included to 
> application/proxy-explanation+json
> as own member.
>
> ( Header field name should be something short like
>   'proxy-nonce', I think. )
>
> | Clients SHOULD indicate that they support this media type by 
> including it
> | in the field-value of the Accept request header
> | field [RFC7231] of all supported requests.
>
> To reduce fingerprinting and request size, browser probably use just 
> */* as
> Accept -header value.
>
> ( I notice that also this new nonce header field ('proxy-nonce' for 
> example)
>   may work as indicator that application/proxy-explanation+json is 
> supported
>   by browser. )
>
> / Kari Hurtta

---

From: "Thomas Mangin" <[email-masked]>
Date: Wed, 02 Mar 2016 10:16:36 +0000

> any header would pass through towards the origin and then could be 
> used by another non-configured proxy down the line.

clarification: it should read ‘could pass’ and not ‘would pass’.

While section 14.10 of RFC 2616 / 6.1 of RFC 7230 does have a rule for 
header stripping, it may not be correctly implemented by proxies.
To be perfectly honest, I just had a look at my/our own code and we did 
not implement it - patch pending :-(.

However as long as any proxy implementing the draft does follow this 
rule it looks like a good solution.

Thomas

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 02 Mar 2016 10:12:54 +0000

Thomas Mangin <[email-masked]>: (Wed Mar  2 11:25:06 2016)
> json+explaination response messages coming back towards the client.

That is why I put it to Connection: -header field.

>> only  with encrypted connections / with CONNECT method. )

I think that browser will quite fast learn
that is proxy supporting HTTP/1.1

Simple use this only when there is seen HTTP/1.1
response from proxy for some previous request.

If proxy wants use this, then it is better to support
HTTP/1.1

https://tools.ietf.org/html/rfc7230#section-6.1

|   When a header field aside from Connection is used to supply control
|   information for or about the current connection, the sender MUST list
|   the corresponding field-name within the Connection header field.  A
|   proxy or gateway MUST parse a received Connection header field before
|   a message is forwarded and, for each connection-option in this field,
|   remove any header field(s) from the message with the same name as the
|   connection-option, and then remove the Connection header field itself
|   (or replace it with the intermediary's own connection options for the
|   forwarded message).

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 02 Mar 2016 16:19:37 +0000

> json+explaination response messages coming back towards the client.

If proxy receices application/proxy-explanation+json from
upstream proxy, that is directed to that proxy.

Proxy can use use it to form it's own error report to
downstream (either text/html or application/proxy-explanation+json)

If proxy receices application/proxy-explanation+json from
origin server then it is another error case.

Yes, in any case application/proxy-explanation+json is consumed
and not passed to downstream.

So I see that media type to be connection releated. 

( But as I noticed earlier, that new header field 
 is perhaps overengineering here. )

/ Kari Hurtta