On 08/06/2020 22:29, Christopher Schultz wrote: > I think that's enough for now. So the questions are: > > 1. Does anyone really want Tomcat to be worried about this stuff? I > know the answer is "some people care" but I want to get a sense of how > many actually care. So if you think this would be a good thing to > implement in one way or another, please speak up.
My instinct is that this is a fairly rare requirement at the moment. > 2. If we implement this, is it okay to change the API to do so? I > think we can do this in a backward-compatible way so that we don't > have to e.g. use an ObjectOutputStream to write a byte[] which has > been encrypted after using another ObjectOutputStream to generate > those bytes for storage. It depends which API. There are lots of 3rd-party session managers so we need to be very careful. Default methods could be useful. I'm wondering if we need a new Filter/Valve/Interceptor style API for this. Or a wrapper around an existing store. Or a wrapper around an existing Manager. Or... I think we need to look a some of the 3rd party session managers out there to get an idea of how this might integrate with them. Or if that is even possible. > 3. Is encryption "enough", or should we try to implement some kind of > replay-mitigations? I don't think we'll ever be able to completely > close this hole because (a) Tomcat can't be expected to have a priori > information about the session before it's being loaded (e.g. after > restart) and (b) all the validation information must be inside the > stored session data. I can't think of a way to avoid a replay attack > short of maintaining yet another database of session-versions for > validation. I can see a man in the corner wearing an "Over-Engineering > Police Force" uniform staring at me intently. Symmetric encryption should be enough. Not persisting authentication (already an option) and not restoring expired sessions (already done) should go some way to mitigating replay attacks. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
