-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 6/9/20 08:13, Mark Thomas wrote:
> 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.
As I think more about this, I think it's important that we investigate
this a little further. Especially because I do not think it will be
terribly complicated.
>> 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've been looking at where ObjectOutputStream is being used in Tomcat
code, and it's quite limited:
XByteBuffer (not relevant)
DeltaManager (serves a different purpose)
StandardManager
JDBCStore
FileStore
Obviously, it's the last 3 of these which are interesting to me.
StandardManager, when configured with a pathname (or left to default
SESSIONS.ser), will use a local-file to store *all* sessions when
Tomcat is shutting-down, and will load from that file on startup. This
is fundamentally different from the session Store concept which deals
with sessions individually instead of in bulk.
The Store interface and the various implementations thereof deal with
individual session-storage.
So I think we need separate solutions for each of the two above cases,
even if they end up sharing a lot of code (e.g. implementation of an
encrypted wrapper).
> 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.
If we can do this at the Manager/Store level (separately) then I think
we won't disturb 3rd-party session managers. If we package the code in
a helpful way, 3rd-party session managers could probably re-use the
code if it makes sense to do so.
What is a little strange is that the JDBCStore and FileStore
implementations delegate the session serialization to the
StandardManager, probably in the spirit of code-reuse. Here is where
the unfortunate internal Tomcat API is working against us:
StandardManager.writeObjectData accepts an ObjectOutputStream instead
of an OutputStream.
What if we add something like this in StandardSession:
public void writeObjectData(OutputStream out) {
if(encrypt) {
out = addEncryptionDecorator(out);
}
writeObjectData(new ObjectOutputStream(out));
}
This should not disturb any existing code.
We update the Store implementations to call
writeObjectData(OutputStream) instead of
writeObjectData(ObjectOutputStream). Any 3rd-party session manager can
use addEncryptionDecorator() if it wants to, and any 3rd-party Store
implementation can use writeObjectData(OutputStream).
StandardManager's implementation of bulk-session-storage can create a
single encrypted stream and continue to call
writeObjectData(ObjectOutputStream) as before.
Symmetric changes to readObjectData would be made as well.
WDYT?
>> 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.
I agree that symmetric encryption is sufficient.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7sv7wACgkQHPApP6U8
pFjSdRAAj8pcYvEAMHwKyQA/N1ysKKWtwFPhPXVCy2dAqD5Bst/e9B8Kb5JZ8DFC
6ImoD05rlQRDRlxYzDD3oUxxLoEshM6O5PqiWWAZbosqYJENE+3cNL2VlBFTTByQ
rGQb4Bsw+t58u6hoJ9RV1sDazRN/ZC0FHLXlYxxcMxgARlE3NkDOSpvPtrqMY0xc
QUTZQWENHh5l564jrjqBkvkoW2E3i0FkWZmPhi6Goe2u5m/BlBs2N9j2laq72dMw
T4Wq6I3uzH4Gf3R+nXb9WbSnwCcpksI33QGqErMOYaUQC8/W6ObHiXrKly930NeY
frVlyK+fXz035twgeTQTOMm6f1Ernq8LTTk7AM+60otu6lfU9t7u+LKXCUo2Pv7+
wnrJmRb11R97/uL0C5rg3iG1boRyNQwcmb7xAvPI+yy6BZLjN6e4iytJRfKxMcm9
1VAtfkJ1A1feuu75tFwVVr5p0pbur7OlFzagkaQQbTY5rFZjydFIL9t8kiM5xQ0H
I1IQDp7BtYfJog7Y20EIK3HEWhqcGEslhDu3caKT6oJwreRUMy+5K+4FdZlK5mDz
LvoFAM1hEFoqvabeO13RcfGUnejea2DVkS2L+5MvvNCXLsk7w8klQQxn/O1oeojG
SFLW2QmKWugzkznK7AQW61ekMwYQd+Oa2iUfqGXEFHJq7UYcwJE=
=wE5/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
