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.



------ Original Message ------
From: "Martin Thomson" <>
To: "Amos Jeffries" <>
Cc: "HTTP Working Group" <>
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" <> wrote:
>>Hash: SHA1
>>On 22/01/2015 12:11 p.m., Martin Thomson wrote:
>> > On 21 January 2015 at 14:34, Adrien de Croy <>
>> > 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?
>> >
>> > 
>> >
>> >
>> > (when Travis catches up)
>> >
>>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.
>>Version: GnuPG v2.0.22 (MingW32)

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