Re: Intermittent SSL Handshake Errors

Here's what we've learned so far: The issue is related to a new security feature that blocks TLS Fallback, which is a client that connects with one version of TLS, then tries to downgrade the connection and connect with a lower TLS version.. It was a feature made in light of the Poodle SSL vulnera

Re: Intermittent SSL Handshake Errors

I should specify that I agree with what is happening. We have clients that are falling back under normal conditions, and the latest libssl that implemented fallback prevention for TLS is stopping. I have downgraded our libssl and I'm looking in my logs, and I see plenty of iOS 8 devices that auto-

Re: Intermittent SSL Handshake Errors

Maxim, I have been playing with the ciphers as well, and it doesn't appear to be cipher related. It happens for every cipher I've tried. I tried with turning off the prefer on the server, and it uses the same cipher with the prefer on. I then turned prefer server ciphers back on, and tailed our acc

Re: Intermittent SSL Handshake Errors

I had to start looking at this issue again now that yet another openssl security issue. Now that I know I can go back to a working setup just by downgrading SSL, I am able to gather more information. This morning, I updated the libssl libraries and restarted nginx, and the errors started flooding

Re: Intermittent SSL Handshake Errors

You are absolutely correct, but I figured you would want a working environment while we work with nginx/openssl on figuring out how to fix this bug. Knowing that it worked for you also increases my own comfort that the issue is mitigated on my side and I won't have performance issues at my next pea

Re: Intermittent SSL Handshake Errors

Eric, Did you try to downgrade your libssl to the previous version I mentioned earlier? Would love to hear if your issues go away. Posted at Nginx Forum: http://forum.nginx.org/read.php?2,256373,256428#msg-256428 ___ nginx mailing list nginx@nginx.org

Re: Intermittent SSL Handshake Errors

My first question is do these I have been fighting a similar issue with SSL handshake issues for the past few days. After reboots and upgrades for GHOST, we started seeing errors like this in our error logs constantly: *579 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_

nginx struggling to accept connections during peak load

Hello, I had posted to the mailing list earlier this week, but I managed to gather some new information that points directly to nginx (almost certainly my configuration), so I thought I'd post something more concise. I am running edge boxes which use nginx to terminate SSL which passes to haproxy

Re: Is there an nginx queue that isn't logged via $response_time

In case it helps, here at my sysctl and applicable nginx config values Sysctl net.ipv4.tcp_syncookies = 0 net.ipv4.tcp_synack_retries = 2 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_fin_timeout = 3 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 1677721

Re: Is there an nginx queue that isn't logged via $response_time

Sorry, I meant $request_time. Posted at Nginx Forum: http://forum.nginx.org/read.php?2,243170,243171#msg-243171 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx

Is there an nginx queue that isn't logged via $response_time

We have a setup that looks like this: nginx->haproxy->app servers We are terminating SSL with nginx and it sits in front of everything. During our peak load times, we are experiencing about a 2x performance hit. Requests that would normally take 400 ms are taking 800ms. It's taking longer for the