Re: forward HTTPS proxy | Re: The future of forward proxy servers in an http/2 over TLS world

> Mike Bishop <Michael.Bishop@microsoft.com>: (Thu Mar  2 00:35:11 2017)
> > A couple problems with that model.  First, the wholly protocol-based:  A stream is opened by a HEADERS frame; sending an earlier frame on a stream is a breaking protocol change that would require negotiation prior to use.  (Sending the frame between HEADERS and DATA, and requiring a zero-length DATA frame to close the stream might be a reasonable workaround to this.)
> > 
> > 

There may be reason to send SETTINGS frame with

  TRUSTED_PROXY_CONFIGURED = 1

from browser to proxy, but reason is not
"Origin certificate" -frame. I think
that stream is open on that situation even
when it is first frame on direction
proxy -> browser.

 
> http://httpwg.org/specs/rfc7540.html
> 
> | Sending or receiving a HEADERS frame causes the stream to become "open". The stream 
> | identifier is selected as described in Section 5.1.1. The same HEADERS frame can also 
> | cause a stream to immediately become "half-closed".
> 
> My reading is:
> 
> It is HEADERS frame for browser to proxy which opens stream, not
> HEADERS frame on proxy's response from proxy to browser.
> 
> 1) From browser to proxy
> 
> HEADERS
>      + END_STREAM
>      + END_HEADERS
>        :method = GET
>        :scheme = https
>        :path = /
>        :authority = example.com
> 
> 2) From proxy to browser
> 
> "Origin certificate"
> 
> HEADERS
>     + END_HEADERS
>     - END_STREAM
> 	:status = 200
> 	content-type = text/html;charset=utf-8
> 	{other headers]
> 
> DATA
>     + END_STREAM
>      payload
> 
> 
> ----
> 

Sequence A:  (HTTP/2 inside of TLS connection between browser and broxy)


browser => proxy  
HEADERS			(stream 1)
      - END_STREAM
      + END_HEADERS
	:method = CONNECT
	:authority = example.com

proxy => browser						(XXXXXX)
HEADERS                 (stream 1)
      - END_STREAM 
      + END_HEADERS
      	:status = 5xx	(Content Inspection Required)
	content-type = text/html;charset=utf-8

proxy => browser
DATA			(stream 1)
      + END_STREAM
<body>
Connection to example.com refused by Content Inspection Gateway
</body>

proxy => browser 
RST_STREAM 		(stream 1)
	
browser => proxy
HEADERS			(stream 3)
      + END_STREAM
      + END_HEADERS
        :method = GET
	:scheme = https
	:path = /
	:authority = example.com

proxy => browser 
ORIGINCERT		(stream 3)

HEADERS			(stream 3)
      + END_HEADERS
      - END_STREAM
	:status = 200
	content-type = text/html;charset=utf-8
	{other headers]

DATA			(stream 3)
     + END_STREAM
       payload


But why proxy on (XXXXXX)  will return 5xx   (Content Inspection Required).
It does not know that browser understand that
or that browser is willing ask data with GET -method
to https -URL.

So it assumes that browser have proxy's CA certificate
installed as CA on browsers certificate store and does:

Sequence B:  (HTTP/2 inside of TLS connection between browser and broxy)

browser => proxy
HEADERS                 (stream 1)
      - END_STREAM
      + END_HEADERS
        :method = CONNECT
        :authority = example.com

proxy => browser                                                (XXXXXX)
HEADERS                 (stream 1)
      - END_STREAM
      + END_HEADERS
        :status = 200

browser => proxy
DATA			(stream 1)
     - END_STREAM
ClientHello

<Proxy generates certificate for example.com and signs it with proxy's
 CA certificate>

proxy => browser 
DATA			(stream 1)
     - END_STREAM
ServerHello
Certificate for example.com generated by proxy


So for Sequence A something like
TRUSTED_PROXY_CONFIGURED = 1
is needed if another possibility is
use proxy generated certificate to 
imporsonate origin.

But then next question is that why not just
use ORIGINCERT -frame from Sequence A
and otherwise just proxy generated 
certificate. This gives same information
to browser.


Sequence C:  (HTTP/2 inside of TLS connection between browser and broxy)

browser => proxy
HEADERS                 (stream 1)
      - END_STREAM
      + END_HEADERS
        :method = CONNECT
        :authority = example.com

proxy => browser                                                (XXXXXX)
HEADERS                 (stream 1)
      - END_STREAM
      + END_HEADERS
        :status = 200

proxy => browser
ORIGINCERT              (stream 1)

browser => proxy
DATA                    (stream 1)
     - END_STREAM
ClientHello

<Proxy generates certificate for example.com and signs it with proxy's
 CA certificate>

proxy => browser
DATA                    (stream 1)
     - END_STREAM
ServerHello
Certificate for example.com generated by proxy



Now browser knows that there is origin
server impersonated because proxy informed
about that.


Alternatively browser can know that origin
server is imporsonated if browser have separate
certificate store for proxy CA certicate,
which implicate that origin server is
impersonated if server certificate is signed by
that certificate.


Mike Bishop <Michael.Bishop@microsoft.com>
https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0384.html

> Also, note that defining how an explicitly-configured proxy might handle a requirement to 
> inspect traffic actually doesn't constitute wiretapping in the definition given by that 
> RFC - in particular, the definition says that neither the sender nor any receivers know 
> about the third party.

Separate certificate store for proxy CA certicate seems to be
minimal method to achieve knowledge that third party is present.

/ Kari Hurtta

Received on Thursday, 2 March 2017 18:17:03 UTC