logo
Apache Lounge
Webmasters

 

About Forum Index Downloads Search Register Log in RSS X


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

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.
Post new topic   Forum Index -> Apache View previous topic :: View next topic
Reply to topic   Topic: Avoid SSL Handshake in Apache on Every Request
Author
syedabdulbaqi



Joined: 12 Sep 2020
Posts: 1
Location: India, Hyderabad

PostPosted: Sat 12 Sep '20 14:45    Post subject: Avoid SSL Handshake in Apache on Every Request Reply with quote

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: 7288
Location: Germany, Next to Hamburg

PostPosted: Tue 15 Sep '20 22:22    Post subject: Reply with quote

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

PostPosted: Tue 15 Sep '20 23:23    Post subject: Reply with quote

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 Very Happy
Back to top
James Blond
Moderator


Joined: 19 Jan 2006
Posts: 7288
Location: Germany, Next to Hamburg

PostPosted: Wed 16 Sep '20 16:01    Post subject: Reply with quote

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 Very Happy


How should a third party track a client that connects to your server?
Back to top
cent2ap



Joined: 14 Sep 2020
Posts: 6

PostPosted: Wed 16 Sep '20 17:22    Post subject: Reply with quote

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: 7288
Location: Germany, Next to Hamburg

PostPosted: Wed 16 Sep '20 19:03    Post subject: Reply with quote

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

PostPosted: Thu 17 Sep '20 14:57    Post subject: Reply with quote

You may need to update and refresh your knowledge a bit Smile

"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


Reply to topic   Topic: Avoid SSL Handshake in Apache on Every Request View previous topic :: View next topic
Post new topic   Forum Index -> Apache