[squid-users] cache_peer directive with SNI

[Kristopher Lalletti]

Tried both and individually; nothing doing.

I keep getting from Squid a TCP_MISS/503 to which the client page states:

(54) Connection reset by peer (TLS code: SQUID_ERR_SSL_HANDSHAKE)
Handshake with SSL server failed: [No Error]

I’m currently using:
Squid Cache version 3.5.19

I just tried substituting the service-name (service.foo.com) in my /etc/hosts, and define cache_peer to connect to service.foo.com, and even that doesn’t work.  It appears that the cache_peer directive, when SSL is enabled does not transmit SNI.

I did however, manage to get it working to some degree using ssl_bump (http://wiki.squid-cache.org/Features/SslPeekAndSplice) using peek, however, I’m also doing URI filtering with squid, and this defeats the purpose to URI filtering as it only checks the requested SNI header from the end-user, and transposes the connection to the cache_peer.

So I’m thinking that the absence of SNI on cache_peer is a ‘bug’ or a ‘missing feature’, which I’m guessing my next viable option is to see if I can bridge the SNI gap with something like STUNNEL.

Anyone else have any thoughts?

From: Hector Chan [mailto:hectorchan at gmail.com]
Sent: June 22, 2016 1:09 AM
To: Kristopher Lalletti <kristopher at lalletti.ca>
Cc: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] cache_peer directive with SNI

Have you looked at the options forceddomain and ssldomain under the cache_peer directive?  Those may be just what you need.


On Tue, Jun 21, 2016 at 8:14 PM, Kristopher Lalletti <kristopher at lalletti.ca<mailto:kristopher at lalletti.ca>> 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<http://service.foo.com>) is not the server-hostname (webserver1.foo.com<http://webserver1.foo.com>), because I've got 3 servers providing for that service-name.

Valid Request to my backend server:
curl --verbose --resolve service.foo.com:10.10.10.10 https://service.foo.com/

Bad requests to my backend server:
curl --verbose --header 'Host: service.foo.com<http://service.foo.com>' https://webserver1.foo.com/
curl --verbose https://webserver1.foo.com/
curl --verbose https://10.10.10.10/

I've looked at the configuration that was generated for the cached_peer, and it came to this:

cache_peer webserver1.foo.com<http://webserver1.foo.com> parent 443 0 proxy-only no-query no-digest originserver login=PASSTHRU connection-auth=on round-robin ssl sslflags=DONT_VERIFY_PEER front-end-https=auto name=rvp_webserver1

Unfortunately, cached_peer doesn't seem to have any directives about this, which leads me to believe there may be a magic SSL Squid ACL that would tell the cache_peer to transpose the requested hostname as part of the SSL SNI hello message, or something like this...

Any advice/orientation to approach the problem would be much appreciated.

Cheers
Kris
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org<mailto:squid-users at lists.squid-cache.org>
http://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160623/1ed12e38/attachment.html>