-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Filip,

On 10/23/18 12:19, Filip Hanik wrote:
> On Tue, Oct 23, 2018 at 7:05 AM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> All,
> 
> Can I get a technical review for (a) appropriateness and (b)
> technical implementation of the attached cluster interceptor? Let's
> assume for a moment that encryption is something worth adding to
> clustering and not argue that point.
> 
> 
>> Sure! But maybe you can narrow down the need/use case? ie, would
>> just point-to-point TLS be sufficient? so that all bytes got 
>> encrypted?

I wanted something that was a little more accessible. TLS would be a
better, more robust solution, but I wanted something quicker :)

As for point-to-point, it won't work over multicast. Maybe DTLS? I
don't know enough about it.

>> or do you want a WhatsApp type of security, where only sender and
>> receiver can share the a specific data package?

This is just for simple Tomcat clustering, actually.

> It should be straightforward. Knowing virtually nothing about the
> way that Tribes works, implementing this as an interceptor seemed
> like the least invasive (and easiest!) way to add encryption to
> clustering.
> 
> The only question I have about what I've actually written is what
> to do about the cipher IV? Both sides of the conversation need to
> know the IV in order to communicate. Should I just add another
> member to the class for the IV and require that users specify both
> the key AND the IV?
> 
>> That would be one way. I think the idea of having to share a key
>> may be the only drawback in your implementation. Have you
>> considered maybe using asymmetrical encryption?

Nope: I wanted quick dirty. Configuring a Tomcat cluster requires
manual configuration of each of the nodes, anyway, so adding a
pre-shared key isn't a big deal.

As for the IV, I've been thinking about that. Using a one-block-sized
IV (or even just a one-block-sized nonce) and throwing-away the IV
will suffice. The first block can't be reliably decrypted, but because
it's a nonce anyway, it doesn't matter. The receiver can always ignore
the first block of data. This requires an overhead of one-block of
data. For AES, that's 16 bytes, which isn't too bad.

>> In that scenario, you would have MemberImpl.payload = certificate
>> or public key Each member can broadcast their certificate, and a
>> sender can use it to encrypt the data only the receiver can
>> read. No sharing of keys.
> 
>> The encryption would still be done in an interceptor just like
>> you have it. The Local member would hold the private key for
>> decryption.

This might not be a bad idea for a second / alternate implementation.
For now, I just wanted something that /worked/. Some people "just want
encryption". :) OpenVPN, stunnel, etc. are all possibilities, but they
require you to configure some other component.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPgHQACgkQHPApP6U8
pFhD6A/8Dt1EfHcJXjsVNh7YeR7Q9O/yul/e+I3OkYIwHd9oY6fCkI3zpmLiOyqt
s1dZsnj8OkKcGnfbDZvwohCe+8NmEvFRaYB+HLWHbdyCgorFd8S09kThQYe7q3Cx
YlY9p6eNAKciFd/nVrq6ANWLlHZYVtzFJtEGdMQjFb+XJmwcLZxdHQLY1Ol/lYkS
D6NKDgXv5rWSE2KpnBulg61qLtIp5/bNpoRo33EswA9iq9DS1902C+YgaIsObWuA
Uru4Q72ySpNNd3wVJbMnCmle458UIBcb+8M5xHdFo4sErknce0xVyIGgCHv+lFbB
LHHhB0pAWtPOntITIg9xLn3kDei1eIMnhKslpq9wHqKjkDhlJSzDWkBdyU0VMghe
7cP2VeB9R1450hSpYY80meVhXqHMwEc8Vlwfi7S2qnPPi1ujcxOrjk/DQWsEEv80
OnXQqHtm6Is3Y18JWOMs+C6O9rwqu0glrkfLLyjsB8ZYSqv5hARw1OciZaqhHHLh
mvparuHuf9z3fLziL4bwmHxwBtxsNEz5TQIqzBndMviMxWJkJPVDOH4uHyO3oS8w
hkFPGXToomQuJLM1Mne+LoLGu9h0Z9UlJ0awYuu2jOFcKLnzzERzUALQVw4D0e07
nV9ppWVSLgXlvOMfYxl0EtX9N2nd93owz+P2WjUpYLMk2ZYgH8o=
=VZba
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to