-----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
