GitLab

Summary

Some of our (usually large corporate) users are asking for some form of session encryption.

The current design lets any DBA read the content of user sessions (which might contain personal data), and since the lookup key is usually the session ID, they also can easily access valid session IDs, allowing identity spoofing.

Design proposition

I have several ideas about how, and where, to implement this.

In ::Common::Session

• Pros: compatible with every existing session backend, does not require modifying Apache::Session::*
• Cons: We can only encrypt session content and session IDs, and not indexed fields. This might not be an issue because very large setups usually don't use the session explorer at all. And we don't use indexes all that much in the portal code. Some features won't work anymore at large scale (IP restrictions, some SAML use cases...)

In Apache::Session::*

• Pros: can be used to encrypt indexes, so we have (almost) feature parity with non-encrypted sessions.
• Pros: Works with any LLNG version
• Cons: requires a lot more work and more maintenance overhead. We probably will only do that work in the Apache::Session::Browseable module. If we go this way, I will only implement Redis and MongoDB first because that's where the current demand (for encrypted sessions) is, and the rest will come later.

Caveats

Whatever we chose to implement

• searchOnExpr can not work anymore, or at least it won't be able to take advantage of indexes.
• we're expecting some performance penalty, to be measured
• Encrypting indexes with predictable values (_httpSessionType, etc.) might weaken the secret key, but I'm not sure about this. So we might need both an Index and and EncryptedIndex config option
• We'll need to use a good crypto lib, AES::CBC is not very future-proof, one of our users suggested Crypt::NaCl::Sodium but it's not packaged anywhere yet.

@guimard , @clement_oudot , what are your thoughts about this? Especially on ::Common::Session vs Apache::Session ?