Eliezer, Amos,
--
I wanted to follow-up on the below thread since I encountered an additional, interesting issue.
Per my issue with shutterfly.com below, if I *do not* set an ECDH cipher in the tls-dh parameter, then I have to remove NO_SSLv2 from sslproxy_options.
However, if I set an ECDH cipher (I chose secp384r1), I can add NO_SSLv2 back to sslproxy_options and shutterfly.com works without a hitch. My full sslproxy_options list now looks as follows having set the ECDH cipher in tls-dh -
sslproxy_options No_Compression,NO_TLSv1,NO_SSLv2,NO_SSLv3,SINGLE_ECDH_USE,SINGLE_DH_USE,CIPHER_SERVER_PREFERENCE
I don't know if this is a bug or expected behavior, so defer to you. If you'd like me to submit a bug request, I can do so.
Thanks again for the assistance,
Dave
On Wed, Jan 13, 2016 at 6:26 AM, David Marcos <davem.business@xxxxxxxxx> wrote:
Eliezer, Amos,Thanks very much for the prompt responses.I removed NO_SSLv2 from sslproxy_options and the issue with shutterfly.com went away. If I remove NO_SSLv3 and keep NO_SSLv2, squid reports a handshake negotiation error to the browser. I've thus altered the options to remove NO_SSLv2. The only odd thing about this is that things worked fine in v3.5.12 with my below configuration.I'll make some other changes per Amos's suggestions and follow-up if I see anything additional of concern.Thanks again for the help,Dave--On Tue, Jan 12, 2016 at 11:28 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:On 13/01/2016 3:42 p.m., David Marcos wrote:
> I recently upgraded to Squid v3.5.13 and am encountering at least two
> errors when processing certain HTTPS connections. I am not sure if it is a
> bug or a configuration error on my part.
>
> The first error I am seeing is when shutterfly.com is accessed by a user.
> The issue occurs regardless of whether I splice or bump the site. A user
> can browse to the page, but if they click on anything on the site, squid
> encounters a fault. The system does not crash; it recovers, but the proxy
> is down for about 30 seconds. Note that this occurs in regular forward
> proxy mode, not intercept mode.
Squid crashing or hanging entirely is very odd. Especially with splice,
which is just blindly passing the TLS details between client and server.
>
> My knowledge of SSL is somewhat limited, so I am not sure if I have
> misconfigured things in a way that creates the problem. Two questions I
> have are (a) to apply ECDH properly, must an optional cipher be chosen for
> the tls-dh option? and (b) to properly apply ECDH, do I have to recreate
> the dhparam file using an ECDH cipher (I'm currently using the dhparam file
> that I previously had)?
If you omit or misconfigure the tls-dh / dhparams in a way that is not
complained about on startup/reconfigure all that happens is the DH based
ciphers are not usable. The RSA, DES, AES etc ciphers should all still
work normally.
When dhparam= or tls-dh= is configured "old-style" (ie with no curve
name) it only sets the parameters necessary for plain DH or EDH/DHE
ciphers to be used.
When tls-dh= is set with a curve name then the ECDH and EECDH/ECHDE
ciphers are configured.
>
> Separate from the above (or perhaps related), the second issue I am also
> seeing are odd errors in the cache.log that are causing squid to fault and
> recover. I am not yet sure which sites are causing the issue, but I am
> seeing the following error: FATAL: dying from an unhandled exception:
> !theConsumer. This error seems to be consistently preceded by "Error
> negotiating SSL on FD 25: error:14077102:SSL
> routines:SSL23_GET_SERVER_HELLO:unsupported protocol (1/-1/0)".
This is usually seen when non-TLS protocol (ie plain HTTP) is being
received in the HTTPS port.
Or in recent releases it could possibly be SSLv2 or SSLv2-compatible
protocol being received by a library that does not support SSLv2 on a
SSLv3+ or TLSv1+ -only port.
Since the above rules all contain "mynet" as a criterion for happening,
>
> The prior version I was running was v3.5.12 and I know that version had no
> problems when accessing shutterfly.com nor the odd FATAL message I am
> seeing with the below configuration.
>
> Following is more detailed info for the first problem I am encountering
> above with shutterfly.com. Please let me know additional information is
> needed.
>
> Cache.log extracts when accessing shutterfly.com:
> --------------------------------------------------------------------
>
> 2016/01/12 22:39:59 kid1| Error negotiating SSL on FD 91:
> error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
> (1/-1/0)
>
> 2016/01/12 22:39:59 kid1| Error negotiating SSL on FD 98:
> error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
> (1/-1/0)
>
> 2016/01/12 22:39:59 kid1| Error negotiating SSL on FD 89:
> error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
> (1/-1/0)
>
> 2016/01/12 22:40:02 kid1| Error negotiating SSL on FD 62:
> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed (1/-1/0)
>
> 2016/01/12 22:40:02 kid1| Error negotiating SSL on FD 63:
> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed (1/-1/0)
>
> 2016/01/12 22:40:03 kid1| Error negotiating SSL on FD 56:
> error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
> (1/-1/0)
>
> 2016/01/12 22:40:03 kid1| Error negotiating SSL on FD 56:
> error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
> (1/-1/0)
> 2016/01/12 22:40:03 kid1| Error negotiating SSL on FD 58:
> error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
> (1/-1/0)
>
>
> Extracts from my squid.conf file:
> ----------------------------------------------
>
> http_port 127.0.0.1:3128
>
> http_port 192.168.10.1:3128 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=cert.pem tls-dh=cert.dhparam.pem
>
> http_port 192.168.10.1:3129 intercept disable-pmtu-discovery=transparent
> name=http_icept
>
> https_port 192.168.10.1:3130 intercept disable-pmtu-discovery=transparent
> ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> cert=cert.pem tls-dh=cert.dhparam.pem name=https_icept
>
> sslcrtd_program /usr/lib/squid/ssl_crtd -s /disk/dyn-certs/sslcrtd_db -M 4MB
>
> ...
>
> ssl_bump peek SSL_Step1 !dont_peek_or_stare mynet
>
> ssl_bump splice dont_bump_me mynet
>
> ssl_bump bump mynet
>
> ssl_bump terminate all
>
why not you re-order as:
ssl_bump terminate !mynet
ssl_bump peek SSL_Step1 !dont_peek_or_stare
ssl_bump splice dont_bump_me
ssl_bump bump all
>
> sslproxy_foreign_intermediate_certs /etc/ssl/certs/
>
This new directive takes a filename. Not a directory name.
> sslproxy_options
> No_Compression,NO_TLSv1,NO_SSLv2,NO_SSLv3,SINGLE_DH_USE,CIPHER_SERVER_PREFERENCE
>
> sslproxy_cipher
> EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:HIGH:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>
The tls-dh / dhparams settings lacking a curve name for the EC* or EEC*
part mean that these ciphers will not work despite being configured as
acceptible :
EECDH+ECDSA+AESGCM: EECDH+aRSA+AESGCM: EECDH+ECDSA+SHA384:
EECDH+ECDSA+SHA256: EECDH+aRSA+SHA384: EECDH+aRSA+SHA256:
EECDH+aRSA+RC4:EECDH:
Leaving your proxy only able to use this one:
EDH+aRSA
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
