Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

[Ilari Liusvaara <[e-mail]>]

On Wed, Aug 09, 2017 at 10:54:46PM -0700, Tony Arcieri wrote:

> Consider: a gateway server acting as an external proxy which bridges an
> internal network with the Internet, acting as a forward proxy to
> authenticated clients (either human-driven apps/tools or backend services).

> These sorts of tunnels (ab)use a HTTP(S) forward-proxy to establish
> outbound TCP connections (which, if you care about security, will carry TLS
> encrypted traffic).
> 
> This approach is partly described in RFC 2817[2], but to tick all of the
> checkboxes on the points I mentioned earlier using this method, you need to
> implement features in draft-luotonen-web-proxy-tunneling-01[3], which has
> never received an RFC and, as far as I can tell, is only properly
> implemented by Squid. Using Squid as a TLS-in-TLS tunneling solution seems
> less than ideal to me, and yet in many ways it seems like the "least
> friction" option, especially for access control purposes.

As far as I can see, draft-luotonen-web-proxy-tunneling-01 doesn't
really bring anything new on top of RFC 2817 (and in fact, is older
than the RFC).

Neither seemingly describes TLS-in-TLS (SSL-in-SSL) tunnels. But those
are a straightforward extension of the normal HTTP tunneling mechanism.
Including cases where trustpiles for inner and outer connections are
different and where client certificates are different.

However, some non-TLS protocols will not work over HTTPS CONNECT,
unless both client and proxy break TLS semantics (specifically the
behavior of close_notify alert).

In terms of complexity, as far as I can see, the complexity of minimal
implementation of HTTPS tunneling is comparable to dedicated TLS layer
method. HTTPS tunneling does double-encrypt, but eliminating that
double encryption is nontrivial (at least for analysis).


One annoyance in HTTPS tunneling is that the hostname can be duplicated
in three places:

1) The CONNECT target (this is actual place to connect to).
2) The host header (this is supposed to be absent in HTTP/1.0, and MAY
   be blank in HTTP/1.1).
3) The SNI in TLS handshake (in plaintext, can be extracted).



-Ilari