-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All,
Tomcat has provided session-persistence mechanisms as far back as I can remember, and on-disk/in-database/in-memcached/in-redis storage is a somewhat popular practice. Occasionally, we (the community) are asked how to protect the data in those back-end stores e.g. using encryption. The answer has usually been "you need to trust your data store" and that Tomcat simply doesn't provide this kind of facility. A few years ago, I started advocating treating all networks as un-trusted, including "trusted" ones. If you've seen any of my presentations or read any of my comments on networks, you'll know that I think all network communications should be encrypted, even within corporate networks or other environments where the network should be considered "trusted". I think a reasonable extension of this policy is to not trust your storage mechanisms any farther than necessary. For example, if you are storing Tomcat sessions on-disk or in a database, there are very few other things that need to snoop (or modify!) that data besides Tomcat itself. So there isn't any reason NOT to add something like encryption to Tomcat for session stores. I've been looking at StandardSession, which is Serializable. DeltaSession extends StandardSession and adds some magic for clustering which is /separate from/ the standard serialization mechanism -- at least when sending session-changes; I haven't yet looked at bulk-migration of sessions between cluster nodes. Such encryption could easily be implemented in StandardSession.doWriteObject/doReadObject by simply performing the existing serialization operation but adding an encryption step, finally writing a byte string into the ObjectOutputStream. An encryption algorithm+key could be added to the SessionManager and, if present, we add symmetric encryption to the process. I have a few questions about this for the community: 1. Does anyone want this? (I definitely know there are some yesses out there) 2. Is it sufficient to implement this in StandardSession, or do we need something more configurable / customizable / extensible? 3. Is symmetric encryption sufficient, or is there a reason to muck-around with asymmetric encryption. 4. Can anyone think of anything that might break (or significantly degrade) if this were to be added? I'm specifically thinking about clustering which has its own separate encryption mechanism. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl69a8AACgkQHPApP6U8 pFhbAg/7BkhoAJUx8+r3mfFWx8ClSS0x5A4VMb86tLLM3zt7HTVyCrMuvOP3UTrh 6MnSbLFChJDeZfj39ypqWcocW5R+oB78ROVsJPiIOTsNPxyas7+hCL7D91BqxtGT U/Q9DGnyWZTYObxlXqI0qqtFSnhN+UWa8ANpFQWGcuI/l1i8rIPHjkSazhFyBkbQ Rxzed1/15KepSpBunXd3QzPeR3Nn7eFzL/J8EiVEe+T4psscoKGzJ8xRs2OcDj54 q88KqBfq04Dk+G9+KHLxDY2ZXmiP+Mt8uYNXwe/7zLbBtiv6aPdrNMNMS+ejdY+D lRYX4u7KQmNdO/zIMyJJ/5DHy4MDktl803am+x4Cng4Skeh3Cg78TjeCf+NJ2toE /lO9aCe/OGKAbZfczV8HSdMDKCgzon4G+6g/8glFlRk1MeuGMs/EfbLnyOB7cb/a ixT/Tcx0l2U6W9iDNjSfq9+/sxDcmV64htSB5X+IP7GZyd8daOWg4QedkRyN04Dg cjVPf8/rXtpUR4hY3DQG5GCStCyp7c1+dbBL1b/lBueV2arLK8V6Qz/8oQ2ERags ZQUgRMuSaNHIp78djg6wDjUg+93ZhQ6Qxt/9pRuPqzkuZZsOGJ6vz9SPJaCYfz2F 9OjUY/G+VOyZi8jryu7c9fwYGO8WU7lGPBFjptOy4pgJdnaZLa4= =l94x -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
