[squid-users] cache_peer directive with SNI

Hector Chan hectorchan at gmail.com
Thu Jun 23 15:40:17 UTC 2016


Yes, you are right. I ran into the same problem as you did, and now I
remember how I got it to work. I manually patched the version of squid I
was using to send SNI. Let me if you are interested in going that route.
If I remember right, it was just a 1 to 3 line-patch.

On Thu, Jun 23, 2016 at 5:31 AM, Kristopher Lalletti <kristopher at lalletti.ca
> wrote:

> 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> 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.
>
> 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'
> 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 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
> http://lists.squid-cache.org/listinfo/squid-users
>
>
>
> _______________________________________________
> squid-users mailing list
> 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/9af04485/attachment-0001.html>


More information about the squid-users mailing list