Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SSL slow. Establishing secure connection taking too long

I have a dedicated server with 256GB RAM 6 CPUs (12 Threads) on Hetzner, and it is located in Germany. I have CENTOS 7.5. EA4.

My problem is with SSL. Every day for about 2 hours, we have 40 requests in one second and finishing requests takes about 20 seconds. Non-SSL takes 0.5 or less. Here is an example.

From 13:00 to 15:30 (UTC+4), SSL requests take the most time. The problem is evident when you open this link with SSL and without.

I have WHM available. I've noticed ModSecurity and wonder if it might be the problem. I've applied most of the settings provided here, but there is not much regarding SSL.

enter image description here

In case certificates are the reason for all of this:

enter image description here

like image 325
temo Avatar asked Jun 11 '18 18:06

temo


People also ask

How do I fix establishing a secure connection?

What Causes Establishing Secure Connection Slow. Solution 1: Clear All Browsing Data. Solution 2: Reset Network. Solution 3: Re-enable Cryptographic Services and DNS Client in Services.

How do I fix secure connection failed in Chrome?

You'll see this error if you have antivirus software that provides "HTTPS protection" or "HTTPS scanning." The antivirus is preventing Chrome from providing security. To fix the problem, turn off your antivirus software. If the page works after turning off the software, turn off this software when you use secure sites.


2 Answers

I had the same issue and after a lot of digging I found that the problem was caused by the fact that I had mod_unique_id installed.

Further checking shows that the module is a requirement for mod_security. I did remove mod_security at first which did not make any change and only after removing the mod_unique_id module as well things started to fly.

Hope this helps.

like image 86
Bursuc Sergiu Avatar answered Nov 12 '22 15:11

Bursuc Sergiu


So far I am unable to reproduce your problem. WebPageTest reports are all good and pretty. SSL negotiation is within expected 100-200 ms considering you have OCSP stapling enabled. It would have been taking longer under IE otherwise. Suffice to say HTTPS is always slower at first than a plain HTTP, you can't really compare them. All of which makes me think that...

One possible culprit is the mentioned OCSP stapling. What OCSP stapling on your server does is from time to time your server contacts your CA to receive a signed OCSP response. In this situation your CA could be the bottleneck. If it can't provide an expected response on time, you connection stalls too, and that would happen exactly when you're seeing it: during SSL negotiation.

You can check for how long a cached OCSP response is valid with the following command:

openssl s_client -connect banners.analyticson.com:443 -status -servername banners.analyticson.com

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Produced At: Jun 17 21:47:34 2018 GMT
    Cert Status: good
    This Update: Jun 17 21:47:34 2018 GMT
    Next Update: Jun 24 21:47:34 2018 GMT

Currently it reports that an OCSP response is valid up to Jun 24 21:47:34 2018 GMT at very least, but Apache is configured to expire them quite earlier by default. Specifically after just one hour. You should try raising this timeout to a more meaningful value, like up to a week:

SSLStaplingStandardCacheTimeout 604800

Another possible advice is a contrarian one: try disabling OCSP stapling altogether for some time.

If this would really help to remove the problem, then you should be either contacting your CA for assistance, or switch to use a different CA known not to have such problems (think Let's Encrypt), or use a different webserver that can handle OCSP stapling asynchronously and cache them for a longer time (think nginx).

Further research shows that Apache can be made to work around slow or unreliable OCSP responders, although I'm not sure these workarounds would do any good in your case.

like image 44
sanmai Avatar answered Nov 12 '22 14:11

sanmai