Pages

[Gregg]

... sounds like something from a Spy movie

What is mod_session_crypto?

Quite simply, a submodule of mod_session that provides support for the encryption of user sessions before being written to a local database, or written to a remote browser via an HTTP cookie. This can help provide privacy to user sessions where the contents of the session should be kept private from the user, or where protection is needed against the effects of cross site scripting attacks.

Sound useful?

Currently, in Apache 2.4.1 we have provided mod_session_crypto and the OpenSSL cryto driver (apr_crypto_openssl). There is also a NSS (think Firefox) driver for mod_session_cryto as well. I have finally succeeded in getting NSS built on Windows so I expect to include apr_crypto_nss (and the numerous dependency DLLs) in Aache 2.4.2 when it comes out here in the next week or two if all goes well.

I had at one time stumbled across a matrix and notes about the different ciphers and the different crypto drivers. I needed to find it one time and never could. I just stumbled onto it again yesterday and looking at it, think there is some useful information here that is missing in the documentation for the module, so I'll put it here. Whether it is of any use to you or not is up to you. It may be useful when choosing a cipher to use for encrypting your session cookies.

Code Select Expand

/**
* Symmetric Key types understood by the library.
*
* NOTE: It is expected that this list will grow over time.
*
* Interoperability Matrix:
*
* The matrix is based on the testcrypto.c unit test, which attempts to
* test whether a simple encrypt/decrypt will succeed, as well as testing
* whether an encrypted string by one library can be decrypted by the
* others.
*
* Some libraries will successfully encrypt and decrypt their own data,
* but won't decrypt data from another library. It is hoped that over
* time these anomalies will be found and fixed, but until then it is
* recommended that ciphers are chosen that interoperate across platform.
*
* An X below means the test passes, it does not necessarily mean that
* encryption performed is correct or secure. Applications should stick
* to ciphers that pass the interoperablity tests on the right hand side
* of the table.
*
* Aligned data is data whose length is a multiple of the block size for
* the chosen cipher. Padded data is data that is not aligned by block
* size and must be padded by the crypto library.
*
*                  OpenSSL      NSS      Interop
*                 Align Pad  Align Pad  Align Pad
* 3DES_192/CBC    X     X    X     X    X     X
* 3DES_192/ECB    X     X
* AES_256/CBC     X     X    X     X    X     X
* AES_256/ECB     X     X    X          X
* AES_192/CBC     X     X    X     X
* AES_192/ECB     X     X    X
* AES_128/CBC     X     X    X     X
* AES_128/ECB     X     X    X
*
* Conclusion: for padded data, use 3DES_192/CBC or AES_256/CBC. For
* aligned data, use 3DES_192/CBC, AES_256/CBC or AES_256/ECB.
*/


The notes above were written before the BEAST so one could argue today about the CBC ciphers.

[Gregg]

Whew, for a day there I thought I was going to be made a liar of as I could not get the apr_crypto_nss-1.dll driver to build in x64. Fortunately, figured out the what problem was.

I'm not sure it is worth the extra size (driver + dependency dlls) of the download zip file, or the time spent building it and NSS, but now that I have it I may as well include it.