Here is the actual procedure (in TRUNK, but last modified 3 months ago, I did not look at what changed). http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/session/mod_session_crypto.c?view=markup Ignoring the apache-specific configuration, it looks pretty standard to me (although I did not spend too long looking at it, but I did teach college-senior crypto last semester and it looks similar to a project we assigned).
- Y On Mon, Jul 8, 2013 at 11:32 PM, Mikhail T. <mi+t...@aldan.algebra.com>wrote: > 08.07.2013 19:35, Graham Leggett wrote: > > Like Daniel said, you don't need to know. > > This is unhelpful. Do you *know* the answer? If you do, could you share > it? If you are trying to avoid committing to a particular method -- because > you foresee it changing in the future -- well, that does not seem right > either. The cookies may already be stored by the browsers and invalidating > them all by upgrading the server would not be proper. > > You can configure the decrypted session to be provided to php either via an > environment variable or a request header, your choice. You can then > optionally update the session with a response header. All encryption is > transparent to php. > > Only if the php is running on the same -- or similarly configured Apache > server. > > And then there is the other aspect I mentioned -- the tests, which would > require the session-cookie to be generated (correctly) inside JMeter. > > > 08.07.2013 19:33, Daniel Lescohier wrote: > > Perhaps your decryption code isn't handling the salt? > > Perhaps... But for now I'm just trying to decrypt the existing cookie > myself -- if only to better understand, how it is constructed. I'd > appreciate the description of the method used -- rather than a lecture on > how I "don't need to worry my pretty little head"... > > I'm also curious, if the cookie is only encrypted, or if it is also > signed. As well as whether it is possible to just have it signed without > encrypting... Thanks, > > -mi > >
