[squid-users] cache_peer directive with SNI

[Amos Jeffries]

On 22/06/2016 3:14 p.m., Kristopher Lalletti wrote:
> Hi All,
> 
> I'm replacing an Apache setup as a reverse-proxy with Squid v3.5, and
> I've hit a small snag.
> 
> Basically, I need to tell squid to pass the proper SSL SNI name to
> the backend webserver which is accessed via SSL, and naturally, the
> SSL SNI service-name (service.foo.com) is not the server-hostname
> (webserver1.foo.com), because I've got 3 servers providing for that
> service-name.
> 

You understanding of "proper" behaviour is not correct.

TLS is a point-to-point protocol.

For clients end-to-end and point-to-point are not distinguishable, so a
lot of misunderstanding exists. For a reverse-proxy / CDN the
distinction is critical for correct crytography.


That means the SNI (plus keys, ciphers and certificates etc) on the
connection between Squid and that origin peer are specifically and
exactly supposed to be the "webserver1" details. Because Squid is
talking to the Server Name(d) "webserver1.foo.com" not to itself.

 --> the client will never see the the TLS details the origin sent to
Squid. They are private to the Squid<->origin connection.


The SNI and crypto details between client and Squid is the only place
"service.foo.com" is proper in the TLS layer. Since outside your CDN /
reverse-proxy structure "service.foo.com" (aka Squid) is the Server Name.


Also be aware that the TLS details like SNI on the Squid<->origin
connection have *nothing* to do with the HTTP layer messages. That
should continue to be Host:service.foo.com or whatever the client is
requesting in its HTTP (S) messages.

SNI is not equivalent to HTTP virtual hosting despite what some known
bugs in Apache may have led you to believe.

Amos