<div dir="ltr"><div>openssl test to reproduce the error:<br><br>openssl s_client  -connect <a href="http://www.coursera.org:443">www.coursera.org:443</a> - FAILS (Testing with cousera since it is also hosted on cloudfront, and uses TLS/SNI)<br><br>CONNECTED(00000003)<br>140225331586752:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:757:<br><br>openssl s_client  -connect <a href="http://www.coursera.org:443">www.coursera.org:443</a> -servername <a href="http://www.coursera.org">www.coursera.org</a> - SUCCEEDS<br><br><br><br>Also, with nginx, if I switch off the proxy_ssl_server_name flag, I get the same openssl error as squid,<br><br>2017/02/14 09:20:39 [error] 23604#0: *6 SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) while S<br>SL handshaking to upstream,..."<br><br></div><div>This makes me suspect that squid is not sending the servername ...<br></div><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 February 2017 at 02:40, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 14/02/2017 4:40 a.m., Philip Munaawa wrote:<br>
> I am trying to reverse proxy a site hosted on cloudfront, using the normal<br>
> https_port accel. I have the key/cert pair for the origin. The cloudfront<br>
> uses TLS/SNI to negotiate an SSL connection. However, when I try to connect<br>
> through the proxy, I get the error below in the logs:<br>
><br>
> Error negotiating SSL on FD 39: error:14094410:SSL<br>
> routines:SSL3_READ_BYTES:sslv3 alert handshake failure (1/0/0)<br>
><br>
> I have seen a similar issie with nginx, which was resolved by adding a<br>
> switch to send the server_host_name. see:<br>
> <a href="http://stackoverflow.com/questions/25329941/nginx-caching-proxy-fails-with-ssl23-get-server-hellosslv3-alert-handshake-fail" rel="noreferrer" target="_blank">http://stackoverflow.com/<wbr>questions/25329941/nginx-<wbr>caching-proxy-fails-with-<wbr>ssl23-get-server-hellosslv3-<wbr>alert-handshake-fail</a><br>
><br>
> Does squid (3.5.24) have a similar switch/functionality?<br>
><br>
<br>
</div></div>The only thing that SSL23_SERVER_HELLO and SSL3_READ_BYTES have in<br>
common is that they are errors. So no they are not "similar".<br>
<br>
The server is closing the connection without reporting what the problem<br>
actually is. Squid-3.5 should already be sending SNI using the<br>
cache_peer hostname or request-URL hostname.<br>
<br>
<<a href="http://openssl.6102.n7.nabble.com/error-14094410-SSL-routines-SSL3-READ-BYTES-sslv3-alert-handshake-failure-td12398.html" rel="noreferrer" target="_blank">http://openssl.6102.n7.<wbr>nabble.com/error-14094410-SSL-<wbr>routines-SSL3-READ-BYTES-<wbr>sslv3-alert-handshake-failure-<wbr>td12398.html</a>><br>
has some hints from Dave Thompson on how to find out what is going on<br>
with the server.<br>
<br>
Amos<br>
<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
</blockquote></div><br></div>