You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Thomas Eckert <th...@gmail.com> on 2013/11/25 13:43:00 UTC
Fwd: unsetting encrypted cookies when encryption key changes
Switching mailing list from users to dev becazse to me this does not appear
to be a configuration problem. Anyone care to give a hint ?
---------- Forwarded message ----------
From: Thomas Eckert <th...@gmail.com>
Date: Mon, Nov 18, 2013 at 9:36 AM
Subject: Re: unsetting encrypted cookies when encryption key changes
To: users@httpd.apache.org
Ideas, anyone ?
On Mon, Nov 11, 2013 at 5:26 PM, Thomas Eckert
<th...@gmail.com>wrote:
> Trying to figure out how to unset encrypted cookies for which the
> encryption key was changed. Docs at
>
> http://httpd.apache.org/docs/current/mod/mod_session_crypto.html
>
> say
>
> "If the encryption key is changed, sessions will be invalidated
> automatically."
>
> but using a config like
>
> <Location />
> AuthName "my_auth"
> AuthFormProvider custom_provider
> AuthType form
> AuthFormLoginRequiredLocation "/form_login"
> Session On
> SessionCookieName example_cookie path=/;httponly
> SessionCryptoPassphrase aaadGJ0c3BwWWRqTktzQmZQcERGYk0=
> Require valid-user
> </Location>
>
> <Location "/form_login">
> SetHandler form-login-handler
> AuthFormLoginRequiredLocation "/form_login"
> AuthFormLoginSuccessLocation "/"
> AuthFormProvider custom_provider
> AuthType form
> AuthName "my_auth"
> Session On
> SessionCookieName example_cookie path=/;httponly
> SessionCryptoPassphrase aaadGJ0c3BwWWRqTktzQmZQcERGYk0=
> Require valid-user
> </Location>
>
> and changing the encryption secret after a user has logged on succesfully
> will give me
>
> [session_crypto:error] [pid 22437:tid 3024407408] (100006)Error string
> not specified yet: [client 10.10.10.10:57469] AH01842: decrypt session
> failed, wrong passphrase?
> [session:error] [pid 22437:tid 3024407408] (100006)Error string not
> specified yet: [client 10.10.10.10:57469] AH01817: error while decoding
> the session, session not loaded: /form_login
> [session_crypto:error] [pid 22437:tid 3024407408] (100006)Error string
> not specified yet: [client 10.10.10.10:57469] AH01842: decrypt session
> failed, wrong passphrase?
> [session:error] [pid 22437:tid 3024407408] (100006)Error string not
> specified yet: [client 10.10.10.10:57469] AH01817: error while decoding
> the session, session not loaded: /form_login
>
> and redirecting the user back to the form page again and again. I don't
> see a directive to deal with this in mod_cookie, mod_session or
> mod_session_crypto so I guess this is meant to work out of the box.
>
> What am I missing here ?
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Graham Leggett <mi...@sharp.fm>.
On 27 Jan 2014, at 1:04 PM, Thomas Eckert <th...@gmail.com> wrote:
> > It just woke up - committed in r1560977 and proposed for backport to v2.4.x.
>
> Nice, thank you !
>
>
> > Isn't it curious how the expiry is inspected before the session is decoded?
>
> Why ?
I was also confused by the comment. Currently the expiry of the session is a property of the session implementation, so we use the maxage of the cookie or a dedicated column in a sql table for the expiry. Currently, an expired message shouldn't get past the load step, the check is in case it does in some future module.
Regards,
Graham
--
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
> It just woke up - committed in r1560977 and proposed for backport to
v2.4.x.
Nice, thank you !
> Isn't it curious how the expiry is inspected before the session is
decoded?
Why ?
On Fri, Jan 24, 2014 at 9:16 PM, Erik Pearson <er...@adaptations.com> wrote:
> Isn't it curious how the expiry is inspected before the session is decoded?
>
>
> On Fri, Jan 24, 2014 at 5:11 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
>> On 16 Jan 2014, at 5:15 PM, Thomas Eckert <th...@gmail.com>
>> wrote:
>>
>> > I've had this deployed for some time now and it works just fine. Did
>> this just fall asleep or is further explanation desired ?
>>
>> It just woke up - committed in r1560977 and proposed for backport to
>> v2.4.x.
>>
>> Regards,
>> Graham
>> --
>>
>>
>
>
> --
> Erik Pearson
> Adaptations
> ;; web form and function
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Erik Pearson <er...@adaptations.com>.
Isn't it curious how the expiry is inspected before the session is decoded?
On Fri, Jan 24, 2014 at 5:11 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 16 Jan 2014, at 5:15 PM, Thomas Eckert <th...@gmail.com>
> wrote:
>
> > I've had this deployed for some time now and it works just fine. Did
> this just fall asleep or is further explanation desired ?
>
> It just woke up - committed in r1560977 and proposed for backport to
> v2.4.x.
>
> Regards,
> Graham
> --
>
>
--
Erik Pearson
Adaptations
;; web form and function
Re: unsetting encrypted cookies when encryption key changes
Posted by Graham Leggett <mi...@sharp.fm>.
On 16 Jan 2014, at 5:15 PM, Thomas Eckert <th...@gmail.com> wrote:
> I've had this deployed for some time now and it works just fine. Did this just fall asleep or is further explanation desired ?
It just woke up - committed in r1560977 and proposed for backport to v2.4.x.
Regards,
Graham
--
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
I've had this deployed for some time now and it works just fine. Did this
just fall asleep or is further explanation desired ?
On Fri, Dec 13, 2013 at 9:10 AM, Thomas Eckert
<th...@gmail.com>wrote:
> Must have made some mistake when testing it yesterday because it works
> like a charm. Suggesting this patch (against trunk)
>
> diff --git a/modules/session/mod_session.c b/modules/session/mod_session.c
> index 89c8074..476e021 100644
> --- a/modules/session/mod_session.c
> +++ b/modules/session/mod_session.c
> @@ -126,22 +126,28 @@ static apr_status_t ap_session_load(request_rec * r,
> session_rec ** z)
>
> /* found a session that hasn't expired? */
> now = apr_time_now();
> - if (!zz || (zz->expiry && zz->expiry < now)) {
> + if (zz) {
> + if (zz->expiry && zz->expiry < now) {
> + zz = NULL;
> + }
> + else {
> + /* having a session we cannot decode is just as good as having
> + none at all */
> + rv = ap_run_session_decode(r, zz);
> + if (OK != rv) {
> + ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01817)
> + "error while decoding the session, "
> + "session not loaded: %s", r->uri);
> + zz = NULL;
> + }
> + }
> + }
>
>
> - /* no luck, create a blank session */
> + /* no luck, create a blank session */
> + if (!zz) {
>
> zz = (session_rec *) apr_pcalloc(r->pool, sizeof(session_rec));
> zz->pool = r->pool;
> zz->entries = apr_table_make(zz->pool, 10);
> -
> - }
> - else {
> - rv = ap_run_session_decode(r, zz);
> - if (OK != rv) {
> - ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01817)
> - "error while decoding the session, "
> - "session not loaded: %s", r->uri);
> - return rv;
> - }
> }
>
> /* make sure the expiry and maxage are set, if present */
>
>
> On Thu, Dec 12, 2013 at 10:11 PM, Tom Evans <te...@googlemail.com>wrote:
>
>> On Thu, Dec 12, 2013 at 7:30 PM, Graham Leggett <mi...@sharp.fm> wrote:
>> > On 12 Dec 2013, at 16:57, Thomas Eckert <th...@gmail.com>
>> wrote:
>> >
>> >> The patch does not help but I think it got me on the right track
>> though I'm a bit confused about the 'dirty' flag. Where is that flag
>> supposed to be used ? In both trunk and 2.4.7 I only found one place
>> (./modules/session/mod_session.c:200) where that flag is used but none that
>> remotely looked like triggering a session/cookie replacing.
>> >>
>> >> I assume the real problem lies in mod_session's ap_session_load().
>> There the comment says "If the session doesn't exist, a blank one will be
>> created." but that's simply not true if the session decryption failed.
>> >
>> > Can you clarify what you mean by "session decryption failed"?
>> >
>>
>> When the request has a session cookie present, but the contents are
>> corrupted or in any way incorrect, then decoding the cookie fails.
>> When this occurs, no new session is created.
>> Since no new session is created, no new cookie is set.
>>
>> (I think!)
>>
>> Cheers
>>
>> Tom
>>
>
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
Must have made some mistake when testing it yesterday because it works like
a charm. Suggesting this patch (against trunk)
diff --git a/modules/session/mod_session.c b/modules/session/mod_session.c
index 89c8074..476e021 100644
--- a/modules/session/mod_session.c
+++ b/modules/session/mod_session.c
@@ -126,22 +126,28 @@ static apr_status_t ap_session_load(request_rec * r,
session_rec ** z)
/* found a session that hasn't expired? */
now = apr_time_now();
- if (!zz || (zz->expiry && zz->expiry < now)) {
+ if (zz) {
+ if (zz->expiry && zz->expiry < now) {
+ zz = NULL;
+ }
+ else {
+ /* having a session we cannot decode is just as good as having
+ none at all */
+ rv = ap_run_session_decode(r, zz);
+ if (OK != rv) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01817)
+ "error while decoding the session, "
+ "session not loaded: %s", r->uri);
+ zz = NULL;
+ }
+ }
+ }
- /* no luck, create a blank session */
+ /* no luck, create a blank session */
+ if (!zz) {
zz = (session_rec *) apr_pcalloc(r->pool, sizeof(session_rec));
zz->pool = r->pool;
zz->entries = apr_table_make(zz->pool, 10);
-
- }
- else {
- rv = ap_run_session_decode(r, zz);
- if (OK != rv) {
- ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01817)
- "error while decoding the session, "
- "session not loaded: %s", r->uri);
- return rv;
- }
}
/* make sure the expiry and maxage are set, if present */
On Thu, Dec 12, 2013 at 10:11 PM, Tom Evans <te...@googlemail.com>wrote:
> On Thu, Dec 12, 2013 at 7:30 PM, Graham Leggett <mi...@sharp.fm> wrote:
> > On 12 Dec 2013, at 16:57, Thomas Eckert <th...@gmail.com>
> wrote:
> >
> >> The patch does not help but I think it got me on the right track though
> I'm a bit confused about the 'dirty' flag. Where is that flag supposed to
> be used ? In both trunk and 2.4.7 I only found one place
> (./modules/session/mod_session.c:200) where that flag is used but none that
> remotely looked like triggering a session/cookie replacing.
> >>
> >> I assume the real problem lies in mod_session's ap_session_load().
> There the comment says "If the session doesn't exist, a blank one will be
> created." but that's simply not true if the session decryption failed.
> >
> > Can you clarify what you mean by "session decryption failed"?
> >
>
> When the request has a session cookie present, but the contents are
> corrupted or in any way incorrect, then decoding the cookie fails.
> When this occurs, no new session is created.
> Since no new session is created, no new cookie is set.
>
> (I think!)
>
> Cheers
>
> Tom
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Tom Evans <te...@googlemail.com>.
On Thu, Dec 12, 2013 at 7:30 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 12 Dec 2013, at 16:57, Thomas Eckert <th...@gmail.com> wrote:
>
>> The patch does not help but I think it got me on the right track though I'm a bit confused about the 'dirty' flag. Where is that flag supposed to be used ? In both trunk and 2.4.7 I only found one place (./modules/session/mod_session.c:200) where that flag is used but none that remotely looked like triggering a session/cookie replacing.
>>
>> I assume the real problem lies in mod_session's ap_session_load(). There the comment says "If the session doesn't exist, a blank one will be created." but that's simply not true if the session decryption failed.
>
> Can you clarify what you mean by "session decryption failed"?
>
When the request has a session cookie present, but the contents are
corrupted or in any way incorrect, then decoding the cookie fails.
When this occurs, no new session is created.
Since no new session is created, no new cookie is set.
(I think!)
Cheers
Tom
Re: unsetting encrypted cookies when encryption key changes
Posted by Graham Leggett <mi...@sharp.fm>.
On 12 Dec 2013, at 16:57, Thomas Eckert <th...@gmail.com> wrote:
> The patch does not help but I think it got me on the right track though I'm a bit confused about the 'dirty' flag. Where is that flag supposed to be used ? In both trunk and 2.4.7 I only found one place (./modules/session/mod_session.c:200) where that flag is used but none that remotely looked like triggering a session/cookie replacing.
>
> I assume the real problem lies in mod_session's ap_session_load(). There the comment says "If the session doesn't exist, a blank one will be created." but that's simply not true if the session decryption failed.
Can you clarify what you mean by "session decryption failed"?
In a session key rollover scenario the decryption should succeed, otherwise the session would be lost. When the request is done the contents of the session should be re-encrypted with the new key and then written out.
Regards,
Graham
--
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
The patch does not help but I think it got me on the right track though I'm
a bit confused about the 'dirty' flag. Where is that flag supposed to be
used ? In both trunk and 2.4.7 I only found one place
(./modules/session/mod_session.c:200) where that flag is used but none that
remotely looked like triggering a session/cookie replacing.
I assume the real problem lies in mod_session's ap_session_load(). There
the comment says "If the session doesn't exist, a blank one will be
created." but that's simply not true if the session decryption failed.
Watching the session_rec pointer it will be NULL even after calling
ap_session_load(). This holds true for the subsequent calls to
ap_session_get() in get_session_auth() as well.If you look at mod_session's
ap_session_load() it's obvious why: The session_rec pointer z will never be
set if decoding the session failed.
I would expect a failure to decode the session to result in some form of
reset on the session so the surrounding code can go ahead and set
everything as required, including encrypting the session with a new key.
Looking at mod_auth_form's get_session_auth() this seems to be the
assumption there.
I thought of something as simple as
diff --git a/modules/session/mod_session.c b/modules/session/mod_session.c
index a3354a5..c3c2f27 100644
--- a/modules/session/mod_session.c
+++ b/modules/session/mod_session.c
@@ -142,6 +142,15 @@ static apr_status_t ap_session_load(request_rec * r,
session_rec ** z)
ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01817)
"error while decoding the session, "
"session not loaded: %s", r->uri);
+
+ /* no luck, create a blank session */
+ zz = (session_rec *) apr_pcalloc(r->pool, sizeof(session_rec));
+ zz->pool = r->pool;
+ zz->entries = apr_table_make(zz->pool, 10);
+ zz->uuid = (apr_uuid_t *) apr_pcalloc(zz->pool,
sizeof(apr_uuid_t));
+ apr_uuid_get(zz->uuid);
+ *z = zz;
+
return rv;
}
}
but that didn't do the trick. Going to take another look at it tomorrow.
On Thu, Dec 12, 2013 at 12:25 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 09 Dec 2013, at 10:50 AM, Thomas Eckert <th...@gmail.com>
> wrote:
>
> > So it should work out of the box. I figured as much but was unsure
> whether I hit a bug or forgot a configuration directive. Will look into it
> once I have the time :-/
>
> Here is an untested patch, can you give it a try and confirm?
>
> Index: modules/session/mod_session_crypto.c
> ===================================================================
> --- modules/session/mod_session_crypto.c (revision 1550312)
> +++ modules/session/mod_session_crypto.c (working copy)
> @@ -222,7 +222,7 @@
> * Returns APR_SUCCESS if successful.
> */
> static apr_status_t decrypt_string(request_rec * r, const apr_crypto_t *f,
> - session_crypto_dir_conf *dconf, const char *in, char **out)
> + session_crypto_dir_conf *dconf, const char *in, char **out, int
> *dirty)
> {
> apr_status_t res;
> apr_crypto_key_t *key = NULL;
> @@ -252,6 +252,9 @@
> apr_size_t len = decodedlen;
> char *slider = decoded;
>
> + /* if not first passphrase, mark the session as dirty */
> + *dirty = *dirty & (i > 0);
> +
> /* encrypt using the first passphrase in the list */
> res = apr_crypto_passphrase(&key, &ivSize, passphrase,
> strlen(passphrase),
> @@ -382,7 +385,7 @@
> if ((dconf->passphrases_set) && z->encoded && *z->encoded) {
> apr_pool_userdata_get((void **)&f, CRYPTO_KEY,
> r->server->process->pconf);
> - res = decrypt_string(r, f, dconf, z->encoded, &encoded);
> + res = decrypt_string(r, f, dconf, z->encoded, &encoded,
> &z->dirty);
> if (res != APR_SUCCESS) {
> ap_log_rerror(APLOG_MARK, APLOG_ERR, res, r, APLOGNO(01842)
> "decrypt session failed, wrong passphrase?");
>
>
> Regards,
> Graham
> --
>
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Graham Leggett <mi...@sharp.fm>.
On 09 Dec 2013, at 10:50 AM, Thomas Eckert <th...@gmail.com> wrote:
> So it should work out of the box. I figured as much but was unsure whether I hit a bug or forgot a configuration directive. Will look into it once I have the time :-/
Here is an untested patch, can you give it a try and confirm?
Index: modules/session/mod_session_crypto.c
===================================================================
--- modules/session/mod_session_crypto.c (revision 1550312)
+++ modules/session/mod_session_crypto.c (working copy)
@@ -222,7 +222,7 @@
* Returns APR_SUCCESS if successful.
*/
static apr_status_t decrypt_string(request_rec * r, const apr_crypto_t *f,
- session_crypto_dir_conf *dconf, const char *in, char **out)
+ session_crypto_dir_conf *dconf, const char *in, char **out, int *dirty)
{
apr_status_t res;
apr_crypto_key_t *key = NULL;
@@ -252,6 +252,9 @@
apr_size_t len = decodedlen;
char *slider = decoded;
+ /* if not first passphrase, mark the session as dirty */
+ *dirty = *dirty & (i > 0);
+
/* encrypt using the first passphrase in the list */
res = apr_crypto_passphrase(&key, &ivSize, passphrase,
strlen(passphrase),
@@ -382,7 +385,7 @@
if ((dconf->passphrases_set) && z->encoded && *z->encoded) {
apr_pool_userdata_get((void **)&f, CRYPTO_KEY,
r->server->process->pconf);
- res = decrypt_string(r, f, dconf, z->encoded, &encoded);
+ res = decrypt_string(r, f, dconf, z->encoded, &encoded, &z->dirty);
if (res != APR_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, res, r, APLOGNO(01842)
"decrypt session failed, wrong passphrase?");
Regards,
Graham
--
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
So it should work out of the box. I figured as much but was unsure whether
I hit a bug or forgot a configuration directive. Will look into it once I
have the time :-/
On Sun, Dec 8, 2013 at 2:42 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 04 Dec 2013, at 11:53 AM, Thomas Eckert <th...@gmail.com>
> wrote:
>
> > The encrypted session cookie, sent out in step 4, is never changed. I
> can not see any Set-Cookie headers coming from apache, not even in step 10.
>
> That is definitely a bug - if the session is decrypted with any key other
> than the key that will be used for encryption, the session must be marked
> as dirty so the session gets rewritten.
>
> Regards,
> Graham
> --
>
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2013, at 11:53 AM, Thomas Eckert <th...@gmail.com> wrote:
> The encrypted session cookie, sent out in step 4, is never changed. I can not see any Set-Cookie headers coming from apache, not even in step 10.
That is definitely a bug - if the session is decrypted with any key other than the key that will be used for encryption, the session must be marked as dirty so the session gets rewritten.
Regards,
Graham
--
Re: unsetting encrypted cookies when encryption key changes
Posted by Micha Lenk <mi...@lenk.info>.
Hi Thomas,
Am 04.12.2013 10:53, schrieb Thomas Eckert:
> 1 user tries to browse protected resource
> 2 user is redirected to form
> 3 user fills in and submits form
> 4 user is redirected to AuthFormLoginSuccessLocation and receives
> encrypted session cookie (encrypted with key A)
> 5 encryption key changes from key A to key B
> 6 user tries to browse protected resource
> 7 apache fails to load the session
> 8 user is redirected to form
> 9 user fills in and submits form
> 10 user is redirected to AuthFormLoginSuccessLocation
> 11 apache logs the 'failed to decrypt' and 'failed to load session' again
> 12 user is redirected to form
> continue at step 9
>
> At this point the only way I found to have the user regain access is to
> delete the encrypted session cookie in the user's client. This is
> exactly where my original question sets in because I want to configure
> mod_session and friends in such a way that any cookie which failed
> decryption is simply dropped and replaced with a new one.
>
> All redirets are 302s. I did not see any 401s.
>
> The encrypted session cookie, sent out in step 4, is never changed. I
> can not see any Set-Cookie headers coming from apache, not even in step 10.
Not sending a new cookie in step 10 is probably the issue here. I would
expect apache to send a new Set-Cookie header whenever the user
succeeded authentication (i.e. is redirected to
AuthFormLoginSuccessLocation).
... hope that helps.
Regards,
Micha
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
1 user tries to browse protected resource
2 user is redirected to form
3 user fills in and submits form
4 user is redirected to AuthFormLoginSuccessLocation and receives
encrypted session cookie (encrypted with key A)
5 encryption key changes from key A to key B
6 user tries to browse protected resource
7 apache fails to load the session
8 user is redirected to form
9 user fills in and submits form
10 user is redirected to AuthFormLoginSuccessLocation
11 apache logs the 'failed to decrypt' and 'failed to load session' again
12 user is redirected to form
continue at step 9
At this point the only way I found to have the user regain access is to
delete the encrypted session cookie in the user's client. This is exactly
where my original question sets in because I want to configure mod_session
and friends in such a way that any cookie which failed decryption is simply
dropped and replaced with a new one.
All redirets are 302s. I did not see any 401s.
The encrypted session cookie, sent out in step 4, is never changed. I can
not see any Set-Cookie headers coming from apache, not even in step 10.
On step 7 the log shows
[authz_core:debug] mod_authz_core.c(802): [client 10.128.128.51:57290]
AH01626: authorization result of Require valid-user : denied (no
authenticated user yet)
[authz_core:debug] mod_authz_core.c(802): [client 10.128.128.51:57290]
AH01626: authorization result of <RequireAny>: denied (no authenticated
user yet)
[session_crypto:debug] mod_session_crypto.c(318): (100006)Error string
not specified yet: [client 10.128.128.51:57290] AH01839:
apr_crypto_block_decrypt_finish failed
[session_crypto:info] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01840: decryption failed
[session_crypto:error] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01842: decrypt session failed, wrong passphrase?
[session:error] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01817: error while decoding the session, session not
loaded: /form_to_none_login
[session_crypto:debug] mod_session_crypto.c(318): (100006)Error string
not specified yet: [client 10.128.128.51:57290] AH01839:
apr_crypto_block_decrypt_finish failed
[session_crypto:info] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01840: decryption failed
[session_crypto:error] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01842: decrypt session failed, wrong passphrase?
[session:error] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01817: error while decoding the session, session not
loaded: /form_to_none_login
[session_crypto:debug] mod_session_crypto.c(318): (100006)Error string
not specified yet: [client 10.128.128.51:57290] AH01839:
apr_crypto_block_decrypt_finish failed
[session_crypto:info] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01840: decryption failed
[session_crypto:error] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01842: decrypt session failed, wrong passphrase?
[session:error] (100006)Error string not specified yet: [client
10.128.128.51:57290] AH01817: error while decoding the session, session not
loaded: /form_to_none_login
[session_crypto:debug] mod_session_crypto.c(318): (100006)Error string
not specified yet: [client 10.128.128.51:57290] AH01839:
apr_crypto_block_decrypt_finish failed
and keeps going on like that for a bit longer. This is repeated for every
step following 7. The path '/form_to_none_login' the login form's action.
On Mon, Nov 25, 2013 at 6:55 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 25 Nov 2013, at 7:30 PM, Thomas Eckert <th...@gmail.com>
> wrote:
>
> > > If I have misunderstood, and you simply want all the old cookies
> > > ignored and/or removed, then just list the new key by itself, the old
> > >cookies will not be considered at all - I'm not sure if the invalid
> > > cookie is deleted or not..
> >
> > That's *exactly* what I want: get rid of the old cookies, encrypted with
> the old key. And that's also exactly what's not working, see my first
> message in this thread. There appears an endless loop from the
> authentication form to the authentication form on cookie decryption failure.
>
> Can you be more specific about what is flowing in and out of the server? I
> take it an encrypted cookie comes in that the server cannot decrypt, the
> response is… what? 401 Unauthorised? 302 Temporary Redirect? And on that
> response, what is the value of the cookie being set (assuming the cookie is
> being set at all?).
>
> Regards,
> Graham
> --
>
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Graham Leggett <mi...@sharp.fm>.
On 25 Nov 2013, at 7:30 PM, Thomas Eckert <th...@gmail.com> wrote:
> > If I have misunderstood, and you simply want all the old cookies
> > ignored and/or removed, then just list the new key by itself, the old
> >cookies will not be considered at all - I'm not sure if the invalid
> > cookie is deleted or not..
>
> That's *exactly* what I want: get rid of the old cookies, encrypted with the old key. And that's also exactly what's not working, see my first message in this thread. There appears an endless loop from the authentication form to the authentication form on cookie decryption failure.
Can you be more specific about what is flowing in and out of the server? I take it an encrypted cookie comes in that the server cannot decrypt, the response is… what? 401 Unauthorised? 302 Temporary Redirect? And on that response, what is the value of the cookie being set (assuming the cookie is being set at all?).
Regards,
Graham
--
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
> If I have misunderstood, and you simply want all the old cookies
> ignored and/or removed, then just list the new key by itself, the old
>cookies will not be considered at all - I'm not sure if the invalid
> cookie is deleted or not..
That's *exactly* what I want: get rid of the old cookies, encrypted with
the old key. And that's also exactly what's not working, see my first
message in this thread. There appears an endless loop from the
authentication form to the authentication form on cookie decryption failure.
On Mon, Nov 25, 2013 at 5:53 PM, Tom Evans <te...@googlemail.com> wrote:
> On Mon, Nov 25, 2013 at 1:34 PM, Thomas Eckert
> <th...@gmail.com> wrote:
> > Thanks but I'm no sure if that's what I am looking for. I want to get
> rid of
> > the old sessions (with the old key) and replace them with new ones (with
> the
> > new key).
>
> Firstly, (ISTM) you want to preserve the contents of the cookies, but
> encrypted with a new key.
> In order to do this, you must wait for people to present the old
> cookies to your site.
> Since you want to preserve the contents, you must be able to decrypt
> the old cookie first, thus you require all the old keys that you want
> to convert.
> Once all/enough cookies have been converted, you can remove any old
> keys from your config.
>
> So yes, you would need to list all keys used, as long as you expect
> sessions encrypted with those keys to still be valid as far as httpd
> is concerned.
>
>
> If I have misunderstood, and you simply want all the old cookies
> ignored and/or removed, then just list the new key by itself, the old
> cookies will not be considered at all - I'm not sure if the invalid
> cookie is deleted or not..
>
> Cheers
>
> Tom
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Tom Evans <te...@googlemail.com>.
On Mon, Nov 25, 2013 at 1:34 PM, Thomas Eckert
<th...@gmail.com> wrote:
> Thanks but I'm no sure if that's what I am looking for. I want to get rid of
> the old sessions (with the old key) and replace them with new ones (with the
> new key).
Firstly, (ISTM) you want to preserve the contents of the cookies, but
encrypted with a new key.
In order to do this, you must wait for people to present the old
cookies to your site.
Since you want to preserve the contents, you must be able to decrypt
the old cookie first, thus you require all the old keys that you want
to convert.
Once all/enough cookies have been converted, you can remove any old
keys from your config.
So yes, you would need to list all keys used, as long as you expect
sessions encrypted with those keys to still be valid as far as httpd
is concerned.
If I have misunderstood, and you simply want all the old cookies
ignored and/or removed, then just list the new key by itself, the old
cookies will not be considered at all - I'm not sure if the invalid
cookie is deleted or not..
Cheers
Tom
Re: unsetting encrypted cookies when encryption key changes
Posted by Thomas Eckert <th...@gmail.com>.
Thanks but I'm no sure if that's what I am looking for. I want to get rid
of the old sessions (with the old key) and replace them with new ones (with
the new key). For me, that's pretty much "invalidating" them but I think
the docs mean something different with (
http://httpd.apache.org/docs/current/mod/mod_session_crypto.html#sessioncryptopassphrase
)
"Changing the key on a server has the effect of invalidating all existing
sessions."
Does your reply mean this is not possible without listing every single key
that has ever been used on this vhost ?
On Mon, Nov 25, 2013 at 1:48 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 25 Nov 2013, at 2:43 PM, Thomas Eckert <th...@gmail.com>
> wrote:
>
> Switching mailing list from users to dev becazse to me this does not
> appear to be a configuration problem. Anyone care to give a hint ?
>
>
> and redirecting the user back to the form page again and again. I don't
>> see a directive to deal with this in mod_cookie, mod_session or
>> mod_session_crypto so I guess this is meant to work out of the box.
>>
>> What am I missing here ?
>>
>
> Specify multiple keys, with the current one you want to use on top of the
> list.
>
> The very first key will be used for encryption, but all subsequent keys
> will be used for decryption in turn until one works.
>
> Regards,
> Graham
> --
>
>
Re: unsetting encrypted cookies when encryption key changes
Posted by Graham Leggett <mi...@sharp.fm>.
On 25 Nov 2013, at 2:43 PM, Thomas Eckert <th...@gmail.com> wrote:
> Switching mailing list from users to dev becazse to me this does not appear to be a configuration problem. Anyone care to give a hint ?
> and redirecting the user back to the form page again and again. I don't see a directive to deal with this in mod_cookie, mod_session or mod_session_crypto so I guess this is meant to work out of the box.
>
> What am I missing here ?
Specify multiple keys, with the current one you want to use on top of the list.
The very first key will be used for encryption, but all subsequent keys will be used for decryption in turn until one works.
Regards,
Graham
--