W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

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

From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
Date: Wed, 02 Mar 2016 09:25:06 +0000
To: hurtta@siilo.fmi.fi
Cc: "Mark Nottingham" <mnot@mnot.net>, "HTTP WG" <ietf-http-wg@w3.org>, "Amos Jeffries" <squid3@treenet.co.nz>, "Kari Hurtta" <hurtta-ietf@elmme-mailer.org>
Message-ID: <DC6A5E50-5F88-474E-B563-FBD7F464FBE8@exa-networks.co.uk>
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.


> 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
Received on Wednesday, 2 March 2016 09:25:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC