Quantcast

Reverse proxy for HTTPS cloudfront server

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Reverse proxy for HTTPS cloudfront server

Philip Munaawa
I am trying to reverse proxy a site hosted on cloudfront, using the normal https_port accel. I have the key/cert pair for the origin. The cloudfront uses TLS/SNI to negotiate an SSL connection. However, when I try to connect through the proxy, I get the error below in the logs:

Error negotiating SSL on FD 39: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure (1/0/0)

I have seen a similar issie with nginx, which was resolved by adding a switch to send the server_host_name. see: http://stackoverflow.com/questions/25329941/nginx-caching-proxy-fails-with-ssl23-get-server-hellosslv3-alert-handshake-fail

Does squid (3.5.24) have a similar switch/functionality?

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reverse proxy for HTTPS cloudfront server

Amos Jeffries
Administrator
On 14/02/2017 4:40 a.m., Philip Munaawa wrote:

> I am trying to reverse proxy a site hosted on cloudfront, using the normal
> https_port accel. I have the key/cert pair for the origin. The cloudfront
> uses TLS/SNI to negotiate an SSL connection. However, when I try to connect
> through the proxy, I get the error below in the logs:
>
> Error negotiating SSL on FD 39: error:14094410:SSL
> routines:SSL3_READ_BYTES:sslv3 alert handshake failure (1/0/0)
>
> I have seen a similar issie with nginx, which was resolved by adding a
> switch to send the server_host_name. see:
> http://stackoverflow.com/questions/25329941/nginx-caching-proxy-fails-with-ssl23-get-server-hellosslv3-alert-handshake-fail
>
> Does squid (3.5.24) have a similar switch/functionality?
>

The only thing that SSL23_SERVER_HELLO and SSL3_READ_BYTES have in
common is that they are errors. So no they are not "similar".

The server is closing the connection without reporting what the problem
actually is. Squid-3.5 should already be sending SNI using the
cache_peer hostname or request-URL hostname.

<http://openssl.6102.n7.nabble.com/error-14094410-SSL-routines-SSL3-READ-BYTES-sslv3-alert-handshake-failure-td12398.html>
has some hints from Dave Thompson on how to find out what is going on
with the server.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reverse proxy for HTTPS cloudfront server

Philip Munaawa
openssl test to reproduce the error:

openssl s_client  -connect www.coursera.org:443 - FAILS (Testing with cousera since it is also hosted on cloudfront, and uses TLS/SNI)

CONNECTED(00000003)
140225331586752:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:757:

openssl s_client  -connect www.coursera.org:443 -servername www.coursera.org - SUCCEEDS



Also, with nginx, if I switch off the proxy_ssl_server_name flag, I get the same openssl error as squid,

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
SL handshaking to upstream,..."

This makes me suspect that squid is not sending the servername ...



On 14 February 2017 at 02:40, Amos Jeffries <[hidden email]> wrote:
On 14/02/2017 4:40 a.m., Philip Munaawa wrote:
> I am trying to reverse proxy a site hosted on cloudfront, using the normal
> https_port accel. I have the key/cert pair for the origin. The cloudfront
> uses TLS/SNI to negotiate an SSL connection. However, when I try to connect
> through the proxy, I get the error below in the logs:
>
> Error negotiating SSL on FD 39: error:14094410:SSL
> routines:SSL3_READ_BYTES:sslv3 alert handshake failure (1/0/0)
>
> I have seen a similar issie with nginx, which was resolved by adding a
> switch to send the server_host_name. see:
> http://stackoverflow.com/questions/25329941/nginx-caching-proxy-fails-with-ssl23-get-server-hellosslv3-alert-handshake-fail
>
> Does squid (3.5.24) have a similar switch/functionality?
>

The only thing that SSL23_SERVER_HELLO and SSL3_READ_BYTES have in
common is that they are errors. So no they are not "similar".

The server is closing the connection without reporting what the problem
actually is. Squid-3.5 should already be sending SNI using the
cache_peer hostname or request-URL hostname.

<http://openssl.6102.n7.nabble.com/error-14094410-SSL-routines-SSL3-READ-BYTES-sslv3-alert-handshake-failure-td12398.html>
has some hints from Dave Thompson on how to find out what is going on
with the server.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reverse proxy for HTTPS cloudfront server

Craig Gowing
From what I can tell the SNI is not added for cache peers. In Ssl::PeerConnector::initializeSsl if "peer" is set then the call to Ssl::setClientSNI is skipped. Also the SSL context doesn't have the hostname or a callback set, and sslCreateClientContext doesn't appear to be able to set it either.

I've tested with a quick patch which appears to the fix the issue: (however I feel it should take into account the forcedomain option as well)

diff --git a/src/ssl/PeerConnector.cc b/src/ssl/PeerConnector.cc
index f5d4c81..178c685 100644
--- a/src/ssl/PeerConnector.cc
+++ b/src/ssl/PeerConnector.cc
@@ -133,6 +133,7 @@ Ssl::PeerConnector::initializeSsl()
     if (peer) {
         SBuf *host = new SBuf(peer->ssldomain ? peer->ssldomain : peer->host);
         SSL_set_ex_data(ssl, ssl_ex_index_server, host);
+        Ssl::setClientSNI(ssl, host->c_str());
 
         if (peer->sslSession)
             SSL_set_session(ssl, peer->sslSession);

Loading...