[squid-users] squid reverse proxy (accelerator) for MS Exchange OWA

[Amos Jeffries]

On 20/01/2017 1:03 p.m., Vieri wrote:
> Hi,
> 
> I'm trying to set up Squid as a reverse proxy on a host with IP address 10.215.144.91 so that web browsers can connect to it on port 443 and request pages from an OWA server at 10.215.144.21:443.
> 
> I have this in my squid.conf:
> 
> https_port 10.215.144.91:443 accel cert=/etc/ssl/squid/owa_cert.cer key=/etc/ssl/squid/owa_key.pem defaultsite=webmail2.mydomain.org
> 
> cache_peer 10.215.144.21 parent 443 0 no-query originserver login=PASS ssl sslcert=/etc/ssl/squid/client.cer sslkey=/etc/ssl/squid/client_key.pem ssloptions=ALL sslflags=DONT_VERIFY_PEER,DONT_VERIFY_DOMAIN name=owaServer
> # cache_peer 10.215.144.21 parent 80 0 no-query originserver login=PASS front-end-https=on name=owaServer
> 

The ssloptions and sslflags values are bad for debugging.
 * The ssloptions=ALL may be adding unknown new issues OWA does not like
from all the insecure things it turns on in Squids TLS handshake.
 * The sslflags disabling verify actions is hiding from you any issues
Squid will have with the OWA handshake security settings.

Knowing what all that hidden stuff does is important to finding the
right fixes or workarounds.



> acl OWA dstdomain webmail2.mydomain.org
> cache_peer_access owaServer allow OWA
> never_direct allow OWA
> 
> http_access allow OWA
> http_access deny all
> miss_access allow OWA
> miss_access deny all

The miss_access is not useful. Your earlier *_access rules already
prevent the unwanted things happening.

> 
> Note that if I comment out the "cache_peer parent 443" line above and uncomment the "cache_peer parent 80" line then the web browser client successfully connects and can view the OWA pages after logging in.
> 
> However, the connection fails if I use 443 between squid at 10.215.144.91 and the OWA backend at 10.215.144.21. The client views a Squid error page with an SSL handshake error.
> 
> Here's the cache log when I try to connect with a client:
> 
> 2017/01/20 00:10:42.284 kid1| Error negotiating SSL on FD 16: error:00000000:lib(0):func(0):reason(0) (5/0/0)
> 2017/01/20 00:10:42.284 kid1| TCP connection to 10.215.144.21/443 failed
> 2017/01/20 00:10:42.285 kid1| 5,5| comm.cc(1038) comm_remove_close_handler: comm_remove_close_handler: FD 16, AsyncCall=0x80d93a00*2
> 2017/01/20 00:10:42.285 kid1| 9,5| AsyncCall.cc(56) cancel: will not call Ssl::PeerConnector::commCloseHandler [call453] because comm_remove_close_handler
> 2017/01/20 00:10:42.285 kid1| 17,4| AsyncCall.cc(93) ScheduleCall: PeerConnector.cc(742) will call FwdState::ConnectedToPeer(0x80d8b9f0, local=10.215.144.91:55948 remote=10.215.144.21:443 FD 16 flags=1, 0x809d49a0/0x809d49a0) [call451]
> 2017/01/20 00:10:42.285 kid1| 93,5| AsyncJob.cc(137) callEnd: Ssl::PeerConnector::negotiateSsl() ends job [ FD 16 job42]
> 2017/01/20 00:10:42.285 kid1| 83,5| PeerConnector.cc(58) ~PeerConnector: Peer connector 0x80d8b590 gone
> 2017/01/20 00:10:42.285 kid1| 93,5| AsyncJob.cc(40) ~AsyncJob: AsyncJob destructed, this=0x80d8b5b4 type=Ssl::PeerConnector [job42]
> 2017/01/20 00:10:42.285 kid1| 17,4| AsyncCallQueue.cc(55) fireNext: entering FwdState::ConnectedToPeer(0x80d8b9f0, local=10.215.144.91:55948 remote=10.215.144.21:443 FD 16 flags=1, 0x809d49a0/0x809d49a0)
> 2017/01/20 00:10:42.285 kid1| 17,4| AsyncCall.cc(38) make: make call FwdState::ConnectedToPeer [call451]
> 2017/01/20 00:10:42.285 kid1| 17,3| FwdState.cc(415) fail: ERR_SECURE_CONNECT_FAIL "Service Unavailable"
> https://webmail2.mydomain.org/Exchange2/
> 2017/01/20 00:10:42.285 kid1| TCP connection to 10.215.144.21/443 failed
> 
> I don't understand the "Service Unavailable" bit above.

It is Squid telling the client it cannot proxy the request. Because the
cache_peer failed. Just one of the symptoms of whatever the problem is.

The key part is the "Error negotiating SSL on FD 16:
error:00000000:lib(0):func(0):reason(0) (5/0/0)"

Which is OpenSSL's very obtuse way of telling Squid "an error
rhappened". With no helpful details about what error it was.

> I can connect just fine from the command line on the squid server at 10.215.144.91 as you can see below.
> 
> # wget --no-check-certificate -O -  https://10.215.144.21 
> --2017-01-20 00:41:10--  https://10.215.144.21/
> Connecting to 10.215.144.21:443... connected.
> WARNING: cannot verify 10.215.144.21's certificate, issued by '/C=xx/ST=xx/O=xx/OU=xx/CN=xxx/emailAddress=xx at xx.xxx':
> Unable to locally verify the issuer's authority.
> WARNING: certificate common name 'XYZ' doesn't match requested host name '10.215.144.21'.

Firstly remove the ssloptions=ALL from your config.

Traffic should be able to go through at that point. But dont take that
as "working", the TLS layer is not in any way secure yet.
 - if not try the front-end-https setting I mentioned earlier.

Then add a sslcafile= option to tell Squid the CA cert which signed the
OWA servers certificate.

Then remove the sslflags option. Traffic should stay working with that.

Amos