Re: [squid-users] Sharepoint SSL Error

On 13/01/2012 3:27 a.m., Dale J. Rodriguez wrote:
> Hello World. Noob Here.
>
>
> I have successfully setup squid as a reverseproxy for port 80, however

What squid version?

> my attempts to set up the same server to point to a https server on
> sharepoint have failed. All I get is the authentication box, and the
> following error message in cache.log:
>
>
> fwdNegotiateSSL: Error negotiating SSL connection on FD 11:
> error:00000000:lib(0):func(0):reason(0) (5/-1/104)

Squid is connecting to a remote server which is responding with
something which is (a) not SSL encrypted, or (b) using an SSL / TLS
version not supported by your OpenSSL library.

>
> The only caveat I have is that I am using an SSL cert that was assigned
> to another IP address, do you have to have matching SSL certs for this
> to work properly?

If the certificate has been created to tie the domain and IP address
together, then yes. I've only seen it on client certificates and some
high-security setups.
Most server ones seem to just be tied to the domain name, allowing
re-use in reverse proxies like you are trying to do.

>
>
>
> Here is my squid config:
>
>
>
> visible_hostname squid.localhost

This is the visible (ie public) hostname (read: FQDN / fully qualified
domain name) of your Squid machine.

Also, ".localhost" domain is invalid. The IANA registered domain you
seem to be looking for is ".local". But that leads to problems with ISP
admin unable to find out who on their own LAN is running the machine
"squid".

>
>
>
> always_direct allow all

This means do not use cache_peer entries in your config. Ever.

Fix #1:
   Please remove this and your actual reverse-proxy config will start to
work the way you configured it.

>
> ssl_bump allow all
>
> pipeline_prefetch off
>
>
>
> http_port 80 defaultsite=1.2.3.60

This means your website *domain name* is "1.2.3.60" for all traffic
received on port 80.

Note that clients connecting to 1.2.3.60 will of course *connect
straight to 1.2.3.60* (instead of your Squid). So any URL re-write
related side effects will bypass Squid and go straight to the backend
server.

Clients which are somehow passing requests to Squid will have their
traffic URLs re-written to http://1.2.3.60/ before Squid tries to
resolve the domain (er, 1.2.3.60) in DNS and gets told the IP 1.2.3.60.
always_direct will then force Squid to pass the re-written request to
that IP.
  ** notice how cache_peer and the cache_peer access logics never got used.

Fix #2:
  you need to add the actual public domain name clients are connecting
to as defaultsite=.
  if you have multiple domains you need to enabel virtual hosting with
the "vhost" reverse-proxy option to http_port

>
> https_port 443 cert=/usr/ssl/lol.cer key=/usr/ssl/llol2.server.pem
> connection-auth=on defaultsite=1.2.3.11

Same problems are happening here. But with the "domain name" 1.2.3.11.

Fix #3: see fix #2.

>
>
>
> cache_peer 1.2.3.60 parent 80 0 no-query originserver no-digest
> login=PASS name=bi_iis
>
> cache_peer 1.2.3.11 parent 443 0 connection-auth=on no-query
> originserver login=PASSTHRU ssl sslflags=DONT_VERIFY_PEER
> name=sharepoint

see notes above with always_direct.

These appear at first glance to be okay of themselves.

>
>
> acl bi_server dst 1.2.3.60
>
> acl sharepoint dst 1.2.3.11
>
> acl lan1 src 1.2.3.0/32
>
> acl lan2 src 1.2.3.0/32
>
> acl vpn src 5.6.7.0/32
>
> acl externalip src 2.3.4.0/32
>
> cache_peer_access bi_iis allow bi_server
>
> cache_peer_access bi_iis allow lan1
>
> cache_peer_access bi_iis allow lan2
>
> cache_peer_access bi_iis allow vpn
>
> cache_peer_access bi_iis allow externalip
>
> cache_peer_access bi_iis deny all
>
> cache_peer_access sharepoint allow bi_server
>
> cache_peer_access sharepoint allow lan1
>
> cache_peer_access sharepoint allow lan2
>
> cache_peer_access sharepoint allow vpn
>
> cache_peer_access sharepoint allow externalip
>
> cache_peer_access sharepoint deny all

see always_direct.

What I see here is nothing like a normal reverse-proxy configuration.
When you have the correct domain names passing through from http_port
and always_direct gone you should be able to revert these back to the
simple dstdomain ACL which are documented for reverse-proxy. Possibly
with HTTP/HTTPS ACLs tying the secure traffic to the SSL peer if you want.

>
> http_access allow lan1
>
> http_access allow lan2
>
> http_access allow vpn
>
> http_access allow externalip
>
> #negative dns entry
>
>
>
> acl localhost src 127.0.0.1/32
>
> acl manager proto cache_object
>
> acl Safe_ports port 80 # httpacl Safe_ports port 443 #https
>
> acl CONNECT method CONNECT
>
> acl POST method POST
>
> never_direct allow CONNECT
>
> never_direct allow POST
>
> never_direct allow ALL

A series of allow lines followed by "allow all" is meaningless. Same
applies to a series of deny and "deny all". Every possible ACL test or
combination of tests is a subset of "all".
The only reason you may want to performuse for a test sequence like this
was if it had side effects (DNS lookups, external ACL helper calls, auth
credentials lookup etc) which were needed soon by some following
fast-group access control which cannot perform the lookup itself.

"always_direct allow all" and "never_direct allow all" in the same
config file shows a misunderstanding of how ACLs work.
    always_direct determines whether use of cache_peer is forbidden
(DIRECT forced) or if peers *may* be used.
    never_direct determines whether DIRECT may be used as a back when
the cache_peer all have problems.
  DIRECT being a DNS lookup of the domain name, and connection to the IP
addresses found in DNS.

>
> sslproxy_flags DONT_VERIFY_PEER
>
>
>
> cache_mgr a_at_lol.com
>
> http_access allow manager localhost
>
> http_access allow lan1
>
> http_access allow lan2
>
> http_access allow vpn
>
> http_access allow externalip

You allow'ed these already up above already.

>
> http_access deny manager
>
> http_access deny !Safe_ports
>
> http_access deny CONNECT
>
> #http_access deny all

This needs a look at after the rest is configured. None of it makes much
sense in a reverse-proxy and can br removed. But for a general proxy it
is broken at present and needs fixing.

Amos
Received on Sat Jan 14 2012 - 06:00:29 MST