- From: Adrien de Croy <adrien@qbik.com>
- Date: Sun, 25 Jan 2015 03:33:34 +0000
- To: "Martin Thomson" <martin.thomson@gmail.com>, "Amos Jeffries" <squid3@treenet.co.nz>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
- Message-Id: <emad5c0ba5-943b-49ea-b2b0-84b9224f7b35@bodybag>
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