Re: New tunnel protocol

that's a different issue.

The problem for me as a proxy implementor, is I still don't know whether 
to expect there to be a TLS layer in there or not.  Please don't make me 
resort to sniffing or daft heuristics to figure this out.  Just make it 
explicit.  If there is an and/or option, include a way to clearly state 
this in the protocol.

Cheers

Adrien

------ Original Message ------
From: "Martin Thomson" <martin.thomson@gmail.com>
To: "Amos Jeffries" <squid3@treenet.co.nz>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 23/01/2015 6:02:49 a.m.
Subject: Re: New tunnel protocol

>Or, if you consider what you are doing to be confidential (it usually 
>isn't), don't include tunnel-protocol. Just like today.
>
>On Jan 21, 2015 8:56 PM, "Amos Jeffries" <squid3@treenet.co.nz> wrote:
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>On 22/01/2015 12:11 p.m., Martin Thomson wrote:
>> > On 21 January 2015 at 14:34, Adrien de Croy <adrien@qbik.com>
>> > wrote:
>> >> So there's room for ambiguity around whether the next layer
>> >> (after CONNECT) is TLS or not.  Or do we rely on the identifier
>> >> also indicating it is over TLS, in which case what if there are 2
>> >> TLS layers?
>> >
>> > I get your point.  My understanding, and what is written down,
>> > were indeed quite different.
>> >
>> > Does this help?
>> >
>> > 
>>https://github.com/httpwg/http-extensions/commit/7e2e57a48c21be2b68f856b41095800620fc1a20
>> >
>> >
>>http://httpwg.github.io/http-extensions/tunnel-protocol.html#rfc.section.1
>> > (when Travis catches up)
>> >
>>
>>No,
>>
>>Consider that under the new scheme the label for HTTPS tunnels would
>>say "HTTP/1.1" to indicate that an HTTP/1.1 compliant proxy "does not
>>understand nor implement the tunneled protocol".
>>
>>The client intent is to tunnel TLS to keep the stuff inside secure. It
>>is not appropriate for the HTTP upper layers to expose those
>>intended-private details for all the world to read.
>>
>>IMO, just indicate TLS as the next layer after CONNECT and have that
>>layers ALPN (or not) indicate the nested next-layer. If the
>>intermediary is capable of peeking at the TLS ALPN value it can do so
>>itself. That also resolves security and logistical issues with keeping
>>the two ALPN tags in-sync.
>>
>>Amos
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v2.0.22 (MingW32)
>>
>>iQEcBAEBAgAGBQJUwIGlAAoJELJo5wb/XPRjbLUIAKEwlIVSVfrTnjnmKMzR+i2c
>>v/x+Qrxsw1Hc5HIHSPqSamcW86MWsKjf872Ay5kLbjzbye5XRVIxJX8ltteImfH4
>>ft9gSEAnIIaeqXcHW7yAE4M+M8x67ShXz2ErvmUEHh38hoybsBYqNVKkGEVg4oEU
>>u6Siuljxjtj4NmhRP8hMTLYf6vT01LOwY9g7gZ3EGf5k0vk+6yTF9qBNxKji9RHF
>>qF6a+/hK15l9YVJejk4KI1w3Jp4xy0Vw0hwJQux+nnbn4D/dW5CE3myIy345xDts
>>ZJhZsKAcRg+JEoRGIMGze6Of5lBIlmtgxs8nhuSalwve+G/grguWb83DDeykWx4=
>>=UNbp
>>-----END PGP SIGNATURE-----
>>

Received on Sunday, 25 January 2015 03:34:29 UTC