Re: [squid-users] 71 Protocol Error when using SSL

On 05/22/2010 11:28 AM, Amos Jeffries wrote:
> Edoardo COSTA SANSEVERINO wrote:
>> On 05/22/2010 04:41 AM, Amos Jeffries wrote:
>>> Edoardo COSTA SANSEVERINO wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I had a look in the archives and the only similar problem I found
>>>> was never answered
>>>> (http://www.squid-cache.org/mail-archive/squid-users/200801/0152.html)
>>>> so I hope someone can help me. I posted this request on
>>>> linuxquestions.org but got no reply so I thought I'd be better off
>>>> asking you guys ;)
>>>>
>>>> I tried to get reverse proxy working with apache mod_proxy but that
>>>> failed so I'm giving squid3 a go but with not much more luck. All
>>>> connections to non ssl websites work fine. The following error I
>>>> [B]only get the second time[/B] I access the page, the first time
>>>> the page is displayed properly! This does not make sense to me but
>>>> maybe it will to one of you.
>>>>
>>>> ERROR
>>>> The requested URL could not be retrieved
>>>>
>>>> While trying to retrieve the URL: https://deb01.example.com/
>>>>
>>>> The following error was encountered:
>>>> Connection to 192.168.122.11 Failed
>>>>
>>>> The system returned:
>>>> (71) Protocol error
>>>>
>>>> The remote host or network may be down. Please try the request again.
>>>>
>>>> Your cache administrator is webmaster.
>>>> Generated Thu, 20 May 2010 18:58:28 GMT by localhost
>>>> (squid/3.0.STABLE8)
>>>>
>>>> My setup
>>>> --------
>>>> +--> (deb02) vhosts running multile http
>>>> |
>>>> [WWW] -> KVM/SQUID ->+--> (deb01) vhost running a single https
>>>> |
>>>> +--> (deb03) vhosts running multile http and
>>>> one https
>>>>
>>>> My squid.conf
>>>> -------------
>>>>
>>>> https_port 443 accel cert=/etc/ssl/deb01.example.com.crt
>>>> key=/etc/ssl/deb01.example.com.pem defaultsite=deb01.example.com
>>>> vhost protocol=https
>>>> http_port 80 accel defaultsite=deb02.example.com vhost
>>>>
>>>> cache_peer 192.168.122.11 parent 443 0 no-query originserver
>>>> login=PASS ssl sslversion=3 sslflags=DONT_VERIFY_PEER
>>>> front-end-https=on name=srv01
>>>> cache_peer 192.168.122.2 parent 80 0 no-query originserver name=srv02
>>>>
>>>> acl https proto https
>>>> acl sites_srv01 dstdomain deb01.example.com
>>>> acl sites_srv02 dstdomain deb02.example.com second.example.com
>>>>
>>>> http_access allow sites_srv01
>>>> http_access allow sites_srv02
>>>> cache_peer_access srv01 allow sites_srv01
>>>> cache_peer_access srv02 allow sites_srv02
>>>>
>>>> forwarded_for on
>>>> ---
>>>>
>>>> The first 'successful' connection gives the following entries in
>>>> the logs:
>>>>
>>>> -----BEGIN SSL SESSION PARAMETERS-----
>>>> MIGIAgEBAgIDAQQCADUEIDrfJnfrcvWw15QVzrwAlKJYsrinM/X+Ge9aeTyO8Fkx
>>>> BDBLAPhbkN6LTcdvHMF9YGm8ib5Qwjm05qP3rr7I+LBjpikfjzV5gJSXLfke83U0
>>>> ggOhBgIES/WH8aIEAgIBLKQCBACmFQQTZGViMDEucHJlY29nbmV0LmNvbQ==
>>>> -----END SSL SESSION PARAMETERS-----
>>>> 2010/05/20 21:05:21| 192.168.122.11 digest requires version 17487;
>>>> have: 5
>>>> 2010/05/20 21:05:21| temporary disabling (invalid digest cblock)
>>>> digest from 192.168.122.11
>>>
>>> Normal. Simply means the web server does not understand proxy cache
>>> digest exchange. This can be silenced by adding no-digest option to
>>> the web server cache_peer line.
>>>
>>>> 2010/05/20 21:05:21| fwdNegotiateSSL: Error negotiating SSL
>>>> connection on FD 16: error:1408F06B:SSL
>>>> routines:SSL3_GET_RECORD:bad decompression (1/-1/0)
>>>> 2010/05/20 21:05:21| TCP connection to 192.168.122.11/443 failed
>>>> [...]
>>>
>>> There is your HTTPS problem. Your SSL system libraries are producing
>>> that error when they can't handle the settings.
>>>
>>> http://google.com/search?q=SSL3_GET_RECORD%3Abad+decompression
>>>
>>>
>>>> 2010/05/20 21:05:21| fwdNegotiateSSL: Error negotiating SSL
>>>> connection on FD 16: error:1408F06B:SSL
>>>> routines:SSL3_GET_RECORD:bad decompression (1/-1/0)
>>>> 2010/05/20 21:05:21| TCP connection to 192.168.122.11/443 failed
>>>> 2010/05/20 21:05:21| fwdNegotiateSSL: Error negotiating SSL
>>>> connection on FD 16: error:1408F06B:SSL
>>>> routines:SSL3_GET_RECORD:bad decompression (1/-1/0)
>>>> 2010/05/20 21:05:21| TCP connection to 192.168.122.11/443 failed
>>>>
>>> <snip storage log>
>>>>
>>>>
>>>> The second 'failed' connection shows the following log events:
>>>>
>>>>
>>>> ==> /var/log/squid3/cache.log <==
>>>> 2010/05/20 21:06:11| fwdNegotiateSSL: Error negotiating SSL
>>>> connection on FD 15: error:1408F06B:SSL
>>>> routines:SSL3_GET_RECORD:bad decompression (1/-1/0)
>>>> [...]
>>>> 2010/05/20 21:06:12| fwdNegotiateSSL: Error negotiating SSL
>>>> connection on FD 15: error:1408F06B:SSL
>>>> routines:SSL3_GET_RECORD:bad decompression (1/-1/0)
>>>> 2010/05/20 21:06:12| TCP connection to 192.168.122.11/443 failed
>>>> 2010/05/20 21:06:12| fwdNegotiateSSL: Error negotiating SSL
>>>> connection on FD 15: error:1408F06B:SSL
>>>> routines:SSL3_GET_RECORD:bad decompression (1/-1/0)
>>>> 2010/05/20 21:06:12| TCP connection to 192.168.122.11/443 failed
>>>>
>>> <snip storage log>
>>>
>>> store.log is irrelevant to most uses. You can safely set it to
>>> "none" in your squid.conf file.
>>>
>>>>
>>>> Any help would be greatly apreciated.
>>>>
>>>>
>>>> As a side note. If anyone can tell me how to show the IP of the
>>>> squid server rather than the internal IP of the webserver (as in
>>>> the error) that would be a bonus ;)
>>>
>>> The error is correct.
>>>
>>> The link client->squid is not working perfectly.
>>>
>>> The link squid->server (via internal IPs) is failing.
>>>
>>> Thus you get a report telling you which link out of the two has
>>> failed. Changing that will only make you look in the wrong place for
>>> some
>>>
>>> Amos
>>
>> Hi Amos,
>>
>> Thanks for your answer but I am a bit confused now.
>>
>> Are you saying it's an SSL problem?
>> There is your HTTPS problem. Your SSL system libraries are
>> producing that error when they can't handle the settings.
>> http://google.com/search?q=SSL3_GET_RECORD%3Abad+decompression
>
> Yes. That is the cause.
>
>>
>> Or are you saying that squid is unable to forward SSL to an internal IP?
>> The link client->squid is not working perfectly.
>> The link squid->server (via internal IPs) is failing.
>>
>
> Yes. That is the effective result.
>
>> Is squid the tool for me if I want to implement the above setup?
>> What would you recomend, Squid, mod_proxy, ...?
>
> I'm not aware of any tools for debugging SSL myself. You may have to
> go searching. A good place would be the reports by other people with
> the same problem. Thus the google link I created for you.
>
>
> Amos

Hi Amos,

I wanted to thank you for your help. First time round, I had not
understood it was an ssl problem. I solved the problem by removing zlib
from SSL.

The following is for anyone having the same problem as I.

These are the steps I did on the squid server and this is the link to
the site:
https://spaces.internet2.edu/display/SHIB2/DebianEtchRebuildOpenSSL

The following steps are the steps I took and vary slightly from the link
above.

Download needed packages for building OpenSSL:

  apt-get build-dep libssl0.9.8
  apt-get source libssl0.9.8
  cd openssl-0.9.8c

Then you have to alter the debian/rules file so as to disable the zlib
during compilation.

  CONFARGS = --prefix=/usr --openssldir=/usr/lib/ssl no-idea no-mdc2 no-rc5 no-zlib

  Next you can start the build process:

  dpkg-buildpackage -rfakeroot -b
  cd ..
  apt-get remove openssl
  dpkg -i *.deb

The custom version is installed. You now have to prevent future updates
from overwriting your custom versions:

  dpkg --set-selections
  openssl hold
  libssl0.9.8 hold
  ^D

Of course, this means that when new openssl versions are released they
won't be automatically installed. You have to repeat this process each
time, specially since they tend to be security updates.

Thanks again for your help!
  -Edoardo
Received on Sat May 22 2010 - 10:56:51 MDT