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