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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
