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.busin...@gmail.com>
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 <squ...@treenet.co.nz>
> 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.
>>
>>
>> >
>> > 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
>> >
>>
>> Since the above rules all contain "mynet" as a criterion for happening,
>> 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@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>
>
>
> --
> ___________________________________________________________
> David J. Marcos
> davem.busin...@gmail.com
>
--
___________________________________________________________
David J. Marcos
davem.busin...@gmail.com
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
