[2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance

Vincent Deffontaines-2
Greetings,

The root observation that makes me open this subject is the following :
Using mod_auth_form + encrypted cookies to manage a web application
authentication gets httpd's auth cookie to be reset by the server at
each and every authenticated request. On a website with a number of
users x a number of requests, this gets quite a number of HMAC crypto
cookie cyphering operations, which I guess could be reduced.

In order to debug this, I started running the attached configuration
(it's pretty much just the most reduced setup to use the module
combination, nothing fancy).
This setup does not enforce cookie encryption. When cookie are
encrypted, I obviously just can notice they differ from a request to
another. When they are not encrypted, I understand why.

Here are a few successive (ordered) cookies sent by the server with this
configuration, including the dummy login and password I'm using for
illustrating this matter :

Set-Cookie:
DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1

Set-Cookie:
DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1

Set-Cookie:
DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870865331;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1

The most interesting part is that, no matter how close in time these
requests can be, the "expiry=%ld" part will change, because it is an
epoch timestamp with a precision up to the microsecond.

I guess nothing here is wrong, regarding RFC2109. But it appeared odd to
me, as opposed to the way most web sessions are dealt with  : while our
cookie lifetime definetely matches the MaxAge produced in configuration,
it is nevertheless reset by the server at each request.

This is of no performance consequence in this debug setup, but I believe
the load can be affected as soon as one sets a SessionCryptoPassphrase
).

For what it's worth, I have benched the difference on my (non-summy)
application, by reloading the main page (which implies quite some
applicative processing on the server, too, and loads 119 hits to
generate the page).
When sessions are encrypted, for 10 refreshes of the page, I measure an
average of 6.5s load time (min : 5.49s, max : 7.55s)
With non encrypted sessions, for 10 refreshes of the page, I measure an
average of 5.9s load time (min : 4.87s, max : 7.13s)

My conclusion from this small bench is that the performance hit from
encrypting each cookie is not insignifiant. It can be measured  and
extracted.

One suggestion could be the following : trying to get the cookie not to
be recomputed by chunks of time, maybe recompute it every
(SessionMaxAge/3) ; maybe expose a directive to manage this delay ?


Additionnally, when setting SessionMaxAge to 0, the cookie expiry does
not change anymore. But the Set-Cookie is still set with every request,
which hints the server still computes the cookie encryption for each
response generation.

I'd like to read your ideas about these possible optimizations.

Cheers,

Vincent

--
What is it you need, that makes your heart beat ?
Do you really know, cause it doesn't show.
New Order - Round & round

minimum_httpd.conf (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance

Marion & Christophe JAILLET
Hi,

have you checked the work in trunk related to
"SessionExpiryUpdateInterval"? [1]

If you have the opportunity to compile and test the trunk version and
report if it corresponds to your use case, it would be great.

If you want to have a look at the code itself, see [2].

Just my 2c,

CJ

[1]:
https://httpd.apache.org/docs/trunk/mod/mod_session.html#sessionexpiryupdateinterval
[2]:
http://svn.apache.org/viewvc?diff_format=h&view=revision&sortby=date&revision=1709121

Le 10/05/2019 à 12:26, Vincent Deffontaines a écrit :

> Greetings,
>
> The root observation that makes me open this subject is the following :
> Using mod_auth_form + encrypted cookies to manage a web application
> authentication gets httpd's auth cookie to be reset by the server at
> each and every authenticated request. On a website with a number of
> users x a number of requests, this gets quite a number of HMAC crypto
> cookie cyphering operations, which I guess could be reduced.
>
> In order to debug this, I started running the attached configuration
> (it's pretty much just the most reduced setup to use the module
> combination, nothing fancy).
> This setup does not enforce cookie encryption. When cookie are
> encrypted, I obviously just can notice they differ from a request to
> another. When they are not encrypted, I understand why.
>
> Here are a few successive (ordered) cookies sent by the server with
> this configuration, including the dummy login and password I'm using
> for illustrating this matter :
>
> Set-Cookie:
> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>
> Set-Cookie:
> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>
> Set-Cookie:
> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870865331;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>
> The most interesting part is that, no matter how close in time these
> requests can be, the "expiry=%ld" part will change, because it is an
> epoch timestamp with a precision up to the microsecond.
>
> I guess nothing here is wrong, regarding RFC2109. But it appeared odd
> to me, as opposed to the way most web sessions are dealt with : while
> our cookie lifetime definetely matches the MaxAge produced in
> configuration, it is nevertheless reset by the server at each request.
>
> This is of no performance consequence in this debug setup, but I
> believe the load can be affected as soon as one sets a
> SessionCryptoPassphrase ).
>
> For what it's worth, I have benched the difference on my (non-summy)
> application, by reloading the main page (which implies quite some
> applicative processing on the server, too, and loads 119 hits to
> generate the page).
> When sessions are encrypted, for 10 refreshes of the page, I measure
> an average of 6.5s load time (min : 5.49s, max : 7.55s)
> With non encrypted sessions, for 10 refreshes of the page, I measure
> an average of 5.9s load time (min : 4.87s, max : 7.13s)
>
> My conclusion from this small bench is that the performance hit from
> encrypting each cookie is not insignifiant. It can be measured  and
> extracted.
>
> One suggestion could be the following : trying to get the cookie not
> to be recomputed by chunks of time, maybe recompute it every
> (SessionMaxAge/3) ; maybe expose a directive to manage this delay ?
>
>
> Additionnally, when setting SessionMaxAge to 0, the cookie expiry does
> not change anymore. But the Set-Cookie is still set with every
> request, which hints the server still computes the cookie encryption
> for each response generation.
>
> I'd like to read your ideas about these possible optimizations.
>
> Cheers,
>
> Vincent
>
Reply | Threaded
Open this post in threaded view
|

Re: [2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance

Vincent Deffontaines-2
Hi,

Thanks for pointing this option in trunk.
I did compile trunk and tried to use it with the option on my
application. It raised other problems that I cannot really isolate
(unexpected 500s with mod_wsgi which are absolutely off-topic).

So I applied the diffs from
http://svn.apache.org/viewvc?diff_format=h&view=revision&sortby=date&revision=1709121 
into 2.4.39, and it does work like a charm : this patch fixes exactly
the problem that I was describing in this thread.

The patch applies without conflict.

Can this patch be considered for a backport into 2.4 ?

Thanks,

Vincent



Le 2019-05-10 17:23, Marion & Christophe JAILLET a écrit :

> Hi,
>
> have you checked the work in trunk related to
> "SessionExpiryUpdateInterval"? [1]
>
> If you have the opportunity to compile and test the trunk version and
> report if it corresponds to your use case, it would be great.
>
> If you want to have a look at the code itself, see [2].
>
> Just my 2c,---
> httpd/httpd/trunk/modules/session/mod_session_dbd.c 2015/10/16
> 22:27:47 1709120
+++ httpd/httpd/trunk/modules/session/mod_session_dbd.c 2015/10/16
22:36:17 1709121
@@ -245,6 +245,9 @@
      /* put the session in the notes so we don't have to parse it again
*/
      apr_table_setn(m->notes, note, (char *)zz);

+    /* don't cache pages with a session */
+    apr_table_addn(r->headers_out, "Cache-Control", "no-cache,
private");
+
      return OK;

  }
@@ -409,9 +412,6 @@
      if (conf->name_set || conf->name2_set) {
          char *oldkey = NULL, *newkey = NULL;

-        /* don't cache pages with a session */
-        apr_table_addn(r->headers_out, "Cache-Control", "no-cache");
-
          /* if the session is new or changed, make a new session ID */
          if (z->uuid) {
              oldkey = apr_pcalloc(r->pool, APR_UUID_FORMATTED_LENGTH +
1);
@@ -458,7 +458,7 @@
      else if (conf->peruser) {

          /* don't cache pages with a session */
-        apr_table_addn(r->headers_out, "Cache-Control", "no-cache");
+        apr_table_addn(r->headers_out, "Cache-Control", "no-cache,
private");

          if (r->user) {
              ret = dbd_save(r, r->user, r->user, z->encoded, z->expiry);

>
> CJ
>
> [1]:
> https://httpd.apache.org/docs/trunk/mod/mod_session.html#sessionexpiryupdateinterval
> [2]:
> http://svn.apache.org/viewvc?diff_format=h&view=revision&sortby=date&revision=1709121
>
> Le 10/05/2019 à 12:26, Vincent Deffontaines a écrit :
>> Greetings,
>>
>> The root observation that makes me open this subject is the following
>> :
>> Using mod_auth_form + encrypted cookies to manage a web application
>> authentication gets httpd's auth cookie to be reset by the server at
>> each and every authenticated request. On a website with a number of
>> users x a number of requests, this gets quite a number of HMAC crypto
>> cookie cyphering operations, which I guess could be reduced.
>>
>> In order to debug this, I started running the attached configuration
>> (it's pretty much just the most reduced setup to use the module
>> combination, nothing fancy).
>> This setup does not enforce cookie encryption. When cookie are
>> encrypted, I obviously just can notice they differ from a request to
>> another. When they are not encrypted, I understand why.
>>
>> Here are a few successive (ordered) cookies sent by the server with
>> this configuration, including the dummy login and password I'm using
>> for illustrating this matter :
>>
>> Set-Cookie:
>> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>>
>> Set-Cookie:
>> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>>
>> Set-Cookie:
>> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870865331;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>>
>> The most interesting part is that, no matter how close in time these
>> requests can be, the "expiry=%ld" part will change, because it is an
>> epoch timestamp with a precision up to the microsecond.
>>
>> I guess nothing here is wrong, regarding RFC2109. But it appeared odd
>> to me, as opposed to the way most web sessions are dealt with : while
>> our cookie lifetime definetely matches the MaxAge produced in
>> configuration, it is nevertheless reset by the server at each request.
>>
>> This is of no performance consequence in this debug setup, but I
>> believe the load can be affected as soon as one sets a
>> SessionCryptoPassphrase ).
>>
>> For what it's worth, I have benched the difference on my (non-summy)
>> application, by reloading the main page (which implies quite some
>> applicative processing on the server, too, and loads 119 hits to
>> generate the page).
>> When sessions are encrypted, for 10 refreshes of the page, I measure
>> an average of 6.5s load time (min : 5.49s, max : 7.55s)
>> With non encrypted sessions, for 10 refreshes of the page, I measure
>> an average of 5.9s load time (min : 4.87s, max : 7.13s)
>>
>> My conclusion from this small bench is that the performance hit from
>> encrypting each cookie is not insignifiant. It can be measured  and
>> extracted.
>>
>> One suggestion could be the following : trying to get the cookie not
>> to be recomputed by chunks of time, maybe recompute it every
>> (SessionMaxAge/3) ; maybe expose a directive to manage this delay ?
>>
>>
>> Additionnally, when setting SessionMaxAge to 0, the cookie expiry does
>> not change anymore. But the Set-Cookie is still set with every
>> request, which hints the server still computes the cookie encryption
>> for each response generation.
>>
>> I'd like to read your ideas about these possible optimizations.
>>
>> Cheers,
>>
>> Vincent
>>

--
What is it you need, that makes your heart beat ?
Do you really know, cause it doesn't show.
New Order - Round & round