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

[Kari hurtta <[e-mail]>]

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

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

application/proxy-explanation+json does not necessary work for
http://

https://mnot.github.io/I-D/proxy-explanation/#rfc.section.4

| They can be mitigated in a few ways:
| 
| ∙    Not displaying the moreinfo member in situations 
|      when this is possible (i.e., on any response other 
|      than that to a CONNECT on an encrypted connection).
| 
| ∙    Not supporting the 
|      application/proxy-connection+json media type when the 
|      method is not CONNECT and the connection is not 
|      encrypted.
| 
| ∙    Cautioning the user that the content might not be 
|      trustworthy.

I has some suggestions with that

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0303.html
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0306.html


But because Connection: seems not be implemented, this does not really
work.

/ Kari Hurtta


-------------------------------------------------------------------------
Date: Wed, 2 Mar 2016 07:08:46 +0200 (EET)
From: Kari Hurtta <[e-mail]>

Thomas Mangin <[e-mail]>: (Tue Mar  1 17:32:22 2016)
>>> 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.
> 
> 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

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

| This approach does not preclude an origin server presenting itself as a 
| the proxy, in cases where the client supports the 
| media type on requests other than CONNECT.

If homogeneity of the user experience is desired (as I suggested)
and there is need for avoid origin server presenting itself
as a proxy (for example when request method was GET), there
is possibility to use nonce.

This is perhaps overengineering here:

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