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