Hello, I have run into a very interesting issue. I am replacing a set of nginx reverse proxy servers with a new set running an updated OS/nginx. These nginx servers front a popular API that's mostly used by mobile apps, but also a website that's hosted on a nearby subnet. I put the new servers into service last night, and this morning as traffic picked up (only a couple thousand requests per secoby tempspace - Nginx Mailing List - English
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 vulnerability in order to keep SSL secure. The problem is that many networking libraries still exhibit thiby tempspace - Nginx Mailing List - English
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-negotiate to TLS 1.2 that end up with a TLS 1.0 session. When the new libssl is installed, these connby tempspace - Nginx Mailing List - English
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 access logs which show which cipher was used for the communication. I then went through cipher by cipheby tempspace - Nginx Mailing List - English
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 back. This time, I took a packet capture to see what was happening and what I could correlate. I rby tempspace - Nginx Mailing List - English
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 peak time. Thank you so much for the pcap stuff, I'm sure the information you will provide to Lukas wby tempspace - Nginx Mailing List - English
Eric, Did you try to downgrade your libssl to the previous version I mentioned earlier? Would love to hear if your issues go away.by tempspace - Nginx Mailing List - English
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_CIPHER_LIST:inappropriate fallback) while SSL handshaking, in conjunction with an elevated erroby tempspace - Nginx Mailing List - English
OK, I have an incredibly weird nginx connection issue. I have a cluster of boxes that are responsible for terminating SSL requests and passing them to a local haproxy instance for further routing. I have corosync/pacemaker setup to manage the IP addresses and failover instances if there’s an issue. This server has been running fine for a long time, but we recently had to reboot because of theby tempspace - Nginx Mailing List - English
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 on the same server. During our peak load time, we are experiencing intermittent slow connection isby tempspace - Nginx Mailing List - English
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 = 16777216 16777216 16777216 net.ipv4.tcp_wmem = 16777216 16777216 16777216 net.ipv4.tcp_max_tw_bucketsby tempspace - Nginx Mailing List - English
Sorry, I meant $request_time.by tempspace - Nginx Mailing List - English
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 entire Internet. The problem is, I have absolutely no sign of any slowdowns in my logsby tempspace - Nginx Mailing List - English