Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: Avoid SSL Handshake in Apache on Every Request |
|
| Author |
|
syedabdulbaqi
Joined: 12 Sep 2020
Posts: 1
Location: India, Hyderabad
|
 Posted: Sat 12 Sep '20 14:45 Post subject: Avoid SSL Handshake in Apache on Every Request |
 |
|
I am trying to optimize the performance of my webserver (apache). I have created a simple test page which just returns the "Coming Soon" message. Upon inspecting the request in Developer Console, I noticed that on every page refresh SSL handshake is occurring (Initial Connection and SSL time).
Keep-Alive Timeout in Apache configuration is set to 5 seconds by default. So when I refresh the page within 5 seconds SSL handshake doesn't occur, and page load time is fast. I have read that it is not recommended to increase Keep-Alive Timeout as it will result in many open idle connections and cause performance issues.
SSLSessionCache is also enabled on the server with SSLSessionCacheTimeout set to 300. I was under the impression that having SSLSessionCache enabled is sufficient to avoid SSL handshake on every request. Please correct me if I am wrong.
| Code: | SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLPassPhraseDialog builtin
<IfModule socache_shmcb_module>
SSLUseStapling On
SSLStaplingCache shmcb:/run/apache2/stapling_cache_shmcb(256000)
# Prevent browsers from failing if an OCSP server is temporarily broken.
SSLStaplingReturnResponderErrors off
SSLStaplingErrorCacheTimeout 60
SSLStaplingFakeTryLater off
SSLStaplingResponderTimeout 3
SSLSessionCache shmcb:/run/apache2/ssl_gcache_data_shmcb(1024000)
</IfModule>
<IfModule !socache_shmcb_module>
SSLSessionCache dbm:/run/apache2/ssl_gcache_data_dbm
</IfModule>
SSLSessionCacheTimeout 300
Mutex file:/run/apache2 ssl-cache
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin |
I see many websites for which SSL handshake happens only for the first request and for consecutive requests there won't be any SSL handshake, unless there is inactivity for a long time (60-300 seconds), only then SSL handshake occurs.
So my question is how to maintain a persistent connection? What is the recommended value for Keep-Alive Timeout? Is there any other parameter in the Apache configuration that controls this behavior?
In case anyone wants to check the URL: https://ksaprices.com/
Any help would be appreciated. |
|
| Back to top |
|
James Blond
Moderator
Joined: 19 Jan 2006
Posts: 7371
Location: Germany, Next to Hamburg
|
| Posted: Tue 15 Sep '20 22:22 Post subject: |
|
|
The default value of Keep-AliveTimeout is okay. Using SSLSessionCache and h(ttp)2 is the solution. If you can enable TLSv1.3 that reduces Handshakes even more. Your Mutex path seems to be wrong.
Recommend settings see https://www.apachelounge.com/viewtopic.php?t=2394 |
|
| Back to top |
|
cent2ap
Joined: 14 Sep 2020
Posts: 6
|
| Posted: Tue 15 Sep '20 23:23 Post subject: |
|
|
I agree, the combination of HTTP/2 and TLSv1.3 is a good solution to avoid renegotiation.
But, I dislike HTTP/2 due to some of its properties, server-side, it can be used to track and monitor users. A large organization like google/microsoft/amazon/etc can use your HTTP/2 session identifier to track you across thousands of websites. Probably irrelevant to you, but I just wanted to moan  |
|
| Back to top |
|
James Blond
Moderator
Joined: 19 Jan 2006
Posts: 7371
Location: Germany, Next to Hamburg
|
| Posted: Wed 16 Sep '20 16:01 Post subject: |
|
|
| cent2ap wrote: | I agree, the combination of HTTP/2 and TLSv1.3 is a good solution to avoid renegotiation.
But, I dislike HTTP/2 due to some of its properties, server-side, it can be used to track and monitor users. A large organization like google/microsoft/amazon/etc can use your HTTP/2 session identifier to track you across thousands of websites. Probably irrelevant to you, but I just wanted to moan |
How should a third party track a client that connects to your server? |
|
| Back to top |
|
cent2ap
Joined: 14 Sep 2020
Posts: 6
|
| Posted: Wed 16 Sep '20 17:22 Post subject: |
|
|
Very simple, if you use cloudflare, or a CDN service like Akamai, or an Amazon service, then all of them can easily follow users across the internet via HTTP/2 connections.
For example, a user browses:
one.com (which uses AWS services)
- amazon generates a unique id at this point
two.com (which uses some captcha service hosted in AWS)
- amazon tracks the user from "one.com" to "two.com"
three.com (loads static files hosted on a S3 Amazon bucket)
- amazon tracks the user from "one.com" to "two.com" to "three.com"
even if the user is blocking all cookies or browser local storage, amazon is able to uniquely identify the user and keep a fairly good idea about browsing habbits.
it actually gets uglier, when services go behind our backs and share HTTP/2 ids between them, then amazon can track a user across cloudflare servers/sites and the reverse. |
|
| Back to top |
|
James Blond
Moderator
Joined: 19 Jan 2006
Posts: 7371
Location: Germany, Next to Hamburg
|
| Posted: Wed 16 Sep '20 19:03 Post subject: |
|
|
| That is a wrong comparison. I talked only about h2 in general and your own server. You talk about a CDN. With a CDN that is possible way before h2 was invented. Search for "super cookie". |
|
| Back to top |
|
cent2ap
Joined: 14 Sep 2020
Posts: 6
|
| Posted: Thu 17 Sep '20 14:57 Post subject: |
|
|
You may need to update and refresh your knowledge a bit 
"super cookies" of the past, are small id strings within Flash storage, they are not so "super" because they could be removed or even blocked, back in the mid 90's that Flash was all over the place. Flash hasn't been around for a decade or more, so there is nothing to worry about them.
Another kind of "super cookie", is those injected by your ISP. In the HTTP days, it was fairly easy for the ISP to MiTM your traffic. But that is also a thing of the past, over the past decade things have moved to HTTPS.
Disclaimer: HTTPS does allow your ISP to read the Host you are connecting to. This was a significant lapse in privacy for SSL/TLS up to and including TLSv1.2. This hole was eliminated in TLSv1.3 only.
So yes, HTTP/2 has this issue, which is why the tor project had HTTP/2 disabled, some time ago. I'm not sure if it has been enabled again, I need to check... |
|
| Back to top |
|
|
|
|
|
|
