Re: New tunnel protocol

On 25 January 2015 at 00:37, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> The ALPN identifier tells you if there is TLS.
>>
>
> What does this mean?

That some values for the ALPN identifier signal that there is TLS in
the stack (h2, http/1.1) and others don't (h2c).

>  CONNECT example.com:443 HTTP/1.1
>  Tunnel-Protocol: h2c
>  ...
>  <TLS handshake ALPN(h2)>

That means that the client lied to the proxy.

>  CONNECT example.com:80 HTTP/1.1
>  Tunnel-Protocol: HTTP/1.1
>  ...
>  <TLS handshake ALPN(http/1.1)>
>  GET / HTTP/1.1

The value "HTTP/1.1" isn't defined, but if it were to mean cleartext
HTTP/1.1 (the lowercase variant means HTTP/1.1 over TLS) then the
client is lying here too.

>  CONNECT example.com:80 HTTP/1.1
>  Tunnel-Protocol: HTTP/1.1
>  \r\n
>  <TLS handshake>
>  ...
>  HTTP/1.1 4xx Protocol Not Supported
>  \r\n
>  The "HTTP/1.1" protocol is not permitted through this HTTP/1.1 proxy.
>  \r\n

If you intended the lowercase variant here, that's fine.  The value
only signals the client's intent with respect to application
protocols.  Here, the destination server has declined the transaction,
but it is still effectively speaking the intended protocol.

>  CONNECT example.com:587 HTTP/1.1
>  Tunnel-Protocol: h2c
>  ...
>  <TLS handshake>
>  HELO example.com:25 HTTP/1.1
>  ...

Again, that's the client lying about its intentions.  Depending on how
much information the proxy can extract from the session, there isn't
much that can be done about that.  Of course, the client might find
that its connection has been given a priority that is completely
inappropriate for its actual task.

> Any attempt to proxy the above and use the new header results in some
> form of interoperability failures. So what reason does anybody have to
> bother using it?

I assume that the interoperability failures only occur if the
destination server fails to understand what the client wants and does.
That is always possible though; I can fail to implement a protocol
correctly in numerous ways.

Of course, if the proxy is performing a MitM on the TLS session, or
the client chooses a cleartext protocol and the proxy decides to MitM
that, that is definitely highly likely to break something.  That's on
the client, for lying.

> Lots of problems disappear by being strict that next means *next* layer.
> Not allowing any intermediary layer (ie TLS ALPN extension) to
> contradict the identifiable state.

Indeed they do, but that does not address the actual requirements
here.  The "next" layer in something like WebRTC is basically useless
(it's a TCP encapsulation of UDP packets in some cases).

Received on Sunday, 25 January 2015 17:48:45 UTC