[squid-users] SQUID_ERR_SSL_HANDSHAKE
Amos Jeffries
squid3 at treenet.co.nz
Thu Dec 18 08:25:08 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 18/12/2014 5:32 p.m., Roman Gelfand wrote:
> *The squid version is 3.4.5. The server certificate is sslv3
> generated by openssl. Not quite sure as to what the problem is.*
>
Problem 1: "The server certificate is sslv3"
A certficate has two things:
* a format+data
* a security key
Neither of these things is particularly attached to use on SSLv3
*protocol*, other than being defined there. The format used by all
protocols SSLv2 and later is self-descriptive, you should be able to
use it for secure TLS.
Did you mean cert format v3?
>
> *Failed to establish a secure connection to 192.168.3.108*
>
> The system returned:
>
> (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
>
> Handshake with SSL server failed: error:140770FC:SSL
> routines:SSL23_GET_SERVER_HELLO:unknown protocol
>
> This proxy and the remote host failed to negotiate a mutually
> acceptable security settings for handling your request. It is
> possible that the remote host does not support secure connections,
> or the proxy is not satisfied with the host security credentials.
>
>
This seems to be *a* Squid generated error page BUT...
>
> The ssl configuration is...
>
> https_port 443 cert=/etc/ssl/certs/webfarm.crt
> key=/etc/ssl/private/webfarm.key accel vport
> options=NO_SSLv2:NO_TLSv1:CIPHER_SERVER_PREFERENCE
> cipher=RC4:!MD5:!aNULL:!EDH
>
Problem 2:
Squid-3 no longer impicitly enables "options=ALL". What that means is
that if you explicitly configure an options= or cipher= only what you
sepecifically configure there is available for use.
Omitting those parameters entirely uses the OpenSSL libraries config
settings rather than "ALL".
Your proxy is presenting a very restricted set of ciphers. RC4 only,
with SSLv3, TLSv1.1, TLSv1.2 as protocol.
> cache_peer 192.168.3.108 parent 80 0 no-query originserver
> login=PASS front-end-https=on name=cmm2Server
>
> acl cmm2 dstdomain [my domain] cache_peer_access cmm2Server allow
> cmm2 never_direct allow cmm2
>
> http_access allow cmm2
>
You have no TLS/SSL settings on this cache_peer. So Squid has no
reason to be using SSL/TLS to connect to it.
You don't mention any sslproxy_* settings so I cant be sure. But the
only way for your proxy to generate that page is for somethign like
https://192.168.3.108/ to be requested by the client and allowed
through your proxy.
Far more likely that it comes from some other proxy which does proper
securty checking and complaining about your https_port requirements.
My advice:
* see if your cert can be used over any of the TLS versions. Very
likely it can, especially as you are already offering to use it over
TLSv1.1 or TLSv1.2.
* update the proxy allowed ciphers to include some modern secure ones.
- may require upgrading your OpenSSL library.
* If the cert really is tying you back see if you can get a
better/newer one.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUko9kAAoJELJo5wb/XPRj7QUH/3pFtmKow6VbcIkJ9s/grWhS
0qEAIeHKfrkkqTyCYReFOimj60NIS43ogrFjcVNxlbFx8jqQMKgVJsfont99/D20
h+R3mro7/4EVp8rJYqouKbx3qSWac4leB6wyBWHzKPg2sNTNWWqxfQA38kIAqm6C
+nhUHqrGvVfrdXybtYNj639alHZ7FkoDgw7Xy2CQfaSMMIx6FuJ/0zWH6zYddfWi
L4O7qth0HGpbwtzMwZiwyjEVHoVEKlQVFYSCQx1XjWNOpPSZHcJxO3QrTJ2NZRte
gq3IHXDBJIUBatCW4xMqXGjLTeHDE+L9obEstJdZWeWyXjD1UydfCWoTHKcJFWI=
=MUH8
-----END PGP SIGNATURE-----
More information about the squid-users
mailing list