Re: For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy et al, On 10/25/18 11:54, Rémy Maucherat wrote: > On Thu, Oct 25, 2018 at 5:15 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> All, >> >> Bump. >> >> I have a full patch at this point (still without documentation), >> but this one includes resolution of the IV issue and also a set >> of unit tests which pass. >> >> I'd appreciate it if someone could install this into their >> cluster and see if it works. Just configure the interceptor into >> your interceptor chain and set an encryption key (e.g. >> "cafebabecafebabe"). > > > IMO you should commit it and people will test it then (you did and > it works for you, right ?). With my storeconfig hat on, the > encryptionKey should be more bean like, the poor thing will break > otherwise (again ;) ). I've incorporated the feedback from Keiichi into my patch and committed it to Tomcat trunk. Feedback is welcome and encouraged. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvXTbsACgkQHPApP6U8 pFhsog//a/UjfptHMgYkoIvCdayD1fq4MwKPKZgqV6z0Xox6okP0i0pGkX4/SsJY siYRbKy2oVxjs/EmDHPjrkYBYkreKcxm8qPbkkq7GwLIRL/AFt5S+GJ+d5F5wyVL WutC5umBweOrybe2W4VIvd4I1G6A9b4oH75lWRezvsoEUV8v45Z8BPx+6SJ0Ty5p jwKTKm3wglF7RxfgZ+SRjO7ZDKt4ZdD8aySGZD4Vof0W4cOvy1pz11uJG/olFGrl 9lVtzn4pBVfyxRBffwhhihnS0R482I9BxOXmjUDtGzQIQh5xBrgskFan/+h8vB0a +30H0xjcCnutNkXk8nJhX4EYi7IIPpnv0KXTECEU5PyZYtCJS1Pdb08FKTTKq9FX XJaKkyt2EzLWKKwzSWsaHhSUG+J1BZ+j07jK70FSRVK0Wpkb12dmP6nmzsbEx56K QERuDNnr3EEEflgo2/Hnj+n/OcRYUg4mgOpp96EDlmz+i/2tZu0101aEDKRp3hzt a4SayK6XBYXsF9DEZgPIc20jU4rTPpLjVXeVHLA4ptzlipe5XrNZ1x0Aeg70iqDw mIzHIH1rib8nojTfrtm73KkoRbJ6rQmWP+V4A8Vhmgm9PfBIHS+MCblAPjiBx+TM L3t9Nbjv36HefWB5vDnPj6+G8JyjvmaAL4Aql+popLnLJ2jeJMo= =arhG -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Keiichi, On 10/26/18 01:01, Keiichi Fujino wrote: > Hi Chris! > > Because the argument svc is basically passed the value of > SND_RX_SEQ (1) | Channel.SND_TX_SEQ (2) | MBR_RX_SEQ (4) | > MBR_TX_SEQ (8), so you need to fix the following in start method. > == if(Channel.SND_TX_SEQ == svc) -> if (Channel.SND_TX_SEQ == (svc > & Channel.SND_TX_SEQ)) == > > In order to avoid warnings, you need to add and implement > EncryptInterceptorMBean. > > Some components (static membership etc.) send channel message at > startup, so you should call "super.start(svc)" after calling > "initCiphers()". > > After the above fix, I configured this interceptor and tested > session replication. It seems to work fine. Excellent feedback. I wasn't sure about the start() method; thanks for clearing that up. I'll definitely add the MBean as well, even though I think it won't be very useful to use via JMX. Thanks, - -chris > 2018年10月26日(金) 1:08 Christopher Schultz > : > > Rémy, > > On 10/25/18 11:54, Rémy Maucherat wrote: On Thu, Oct 25, 2018 at 5:15 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > > All, > > Bump. > > I have a full patch at this point (still without > documentation), but this one includes resolution of the IV > issue and also a set of unit tests which pass. > > I'd appreciate it if someone could install this into their > cluster and see if it works. Just configure the interceptor > into your interceptor chain and set an encryption key > (e.g. "cafebabecafebabe"). IMO you should commit it and people will test it then (you did and it works for you, right ?). With my storeconfig hat on, the encryptionKey should be more bean like, the poor thing will break otherwise (again ;) ). > > Okay, I can make the encryption key extractable. > > I don't actually have a cluster available to test I've never > gotten one set up and working. I will do that, but it may take some > time . > > The unit tests actually send the data through the > sendMessage/messageReceived methods, so I'm fairly confident it > will wor k. > > I'll write-up the documentation and commit it, then. > > Thanks, -chris >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> -- Keiichi.Fujino > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvTHEYACgkQHPApP6U8 pFiQPRAAyGhrGQrKV7BTJShAr7qs3IxQUmxXjGbwvr3AzDLY4n2nnvA8kyZkJIgV yS9WAqc7unssIUxrbmsEsT6c4WFhC0OMefvgHjuwZgYkC8YMmsuxTCczK5utSMgE cdjGvM1BZVwA2+OtXLoZrcbeFz1+AQhbn2ma8uR9i1Sr937j/jyISPd5Z+irnI7j s9//RUhjqvV7rkCO6PKBhA0Vt7M8BN8Ys716YmPXs346ey9JMOEct3Ik+o3euPrG yp8oATuwwRDl3EwwsZsgZeSduKoRMz6iGdQXl5iD/3eXus9y1eItebzR69vwXeIT sWA505islh0w3RkBCRQjfQ05tDUmgxX4BQaiPrkIsLkAbsadGleEp17r+P55gBri 3if0l79GS8dd6y/djY6RIbZLu9ZLYIOqPXYz2kkjcm/7JrLy8ccw/Qi5vpPioPVs nmdSi4jgm7/TMLvb96esWcMj7/TN6r4qVWdATqDriFRvNz9+MaX+VSZBtHhD6Pcr dByOXFGXyUzgLxb0mGUrIkqnt05pX6BdU80fCDXNQle6fBibVevFV7Q3Chyd+gmc 4PMmdoaDX99/LFEu/piONcObpLSu5K8+gjU9FWitfXWlGMXPC4ycq5Jn4wzMNHUh 7nWvqGJCk6am6pwo7cHQIOvHL0yP3RBsRTxDUKpMXBzz33cl8ZM= =BDbq -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
Hi Chris! Because the argument svc is basically passed the value of SND_RX_SEQ (1) | Channel.SND_TX_SEQ (2) | MBR_RX_SEQ (4) | MBR_TX_SEQ (8), so you need to fix the following in start method. == if(Channel.SND_TX_SEQ == svc) -> if (Channel.SND_TX_SEQ == (svc & Channel.SND_TX_SEQ)) == In order to avoid warnings, you need to add and implement EncryptInterceptorMBean. Some components (static membership etc.) send channel message at startup, so you should call "super.start(svc)" after calling "initCiphers()". After the above fix, I configured this interceptor and tested session replication. It seems to work fine. 2018年10月26日(金) 1:08 Christopher Schultz : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Rémy, > > On 10/25/18 11:54, Rémy Maucherat wrote: > > On Thu, Oct 25, 2018 at 5:15 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > >> > >> All, > >> > >> Bump. > >> > >> I have a full patch at this point (still without documentation), > >> but this one includes resolution of the IV issue and also a set > >> of unit tests which pass. > >> > >> I'd appreciate it if someone could install this into their > >> cluster and see if it works. Just configure the interceptor into > >> your interceptor chain and set an encryption key (e.g. > >> "cafebabecafebabe"). > > > > > > IMO you should commit it and people will test it then (you did and > > it works for you, right ?). With my storeconfig hat on, the > > encryptionKey should be more bean like, the poor thing will break > > otherwise (again ;) ). > > Okay, I can make the encryption key extractable. > > I don't actually have a cluster available to test I've never > gotten one set up and working. I will do that, but it may take some time > . > > The unit tests actually send the data through the > sendMessage/messageReceived methods, so I'm fairly confident it will wor > k. > > I'll write-up the documentation and commit it, then. > > Thanks, > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvR6oQACgkQHPApP6U8 > pFhKIBAAv2NovLqQpgIsuJzd17LfyHP0wKO0HBaXO9EINx3SfhoTTN7oN5pl7F5I > v+kgBBYVzYGa9N0sVpUhmdP2MqWZ/G0ocY4/WqBCsDaxNcRrUQfY3HMxw18vAQng > sb8bXNVxK4TboKO8lvzPlGVFTuiUxynu5rN/1J62B9scjQE2aDzjIeQ3hAj68V+V > NuKWemxQ/zLLJewEUJ2YMRDntZdn8FoGhpXtnueYNJAaeG3xAzBH3xMwBJQRXpoS > Q54CcumZ07+X5cK7y0as3yLayrQmMnyNpAxILAsiLpCuG24YXDpncwP6izkgkaKq > MogRGxUjuBluXbCKcu+4bQ4nVmsIH9qM0ILcih8Ek/sFqhKBvzlK4TPlqKP/LS51 > +QcSopxX4okJEN8T3VLHyWb7Iw20XjjmjDfJewTZQaHdl1ay20SXsWaFmBXhczX0 > I/YDpqdXr+ZIk7CFUbi0BHcJ6LNxJHakddARds+qDajtUlDYB9GVGersyCr5aDcp > N9887JvRBWC3qODyN8W2CLzdMdTsmdIBYdkRNs3obhPzGetr41TDN0JafEaVw+9W > m3jvzGABOrZGIGF3JFYsqYAG27fRlsR/FU+nu94chKYTOb7QrhOop9lj6NLJl4pU > Ny+3vncMdkUJmcRikGf+ukXFBpZ+ISg+XqHCWBfUnN7ClCnnLmw= > =3pk7 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- > Keiichi.Fujino >
Re: For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy, On 10/25/18 11:54, Rémy Maucherat wrote: > On Thu, Oct 25, 2018 at 5:15 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> All, >> >> Bump. >> >> I have a full patch at this point (still without documentation), >> but this one includes resolution of the IV issue and also a set >> of unit tests which pass. >> >> I'd appreciate it if someone could install this into their >> cluster and see if it works. Just configure the interceptor into >> your interceptor chain and set an encryption key (e.g. >> "cafebabecafebabe"). > > > IMO you should commit it and people will test it then (you did and > it works for you, right ?). With my storeconfig hat on, the > encryptionKey should be more bean like, the poor thing will break > otherwise (again ;) ). Okay, I can make the encryption key extractable. I don't actually have a cluster available to test I've never gotten one set up and working. I will do that, but it may take some time . The unit tests actually send the data through the sendMessage/messageReceived methods, so I'm fairly confident it will wor k. I'll write-up the documentation and commit it, then. Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvR6oQACgkQHPApP6U8 pFhKIBAAv2NovLqQpgIsuJzd17LfyHP0wKO0HBaXO9EINx3SfhoTTN7oN5pl7F5I v+kgBBYVzYGa9N0sVpUhmdP2MqWZ/G0ocY4/WqBCsDaxNcRrUQfY3HMxw18vAQng sb8bXNVxK4TboKO8lvzPlGVFTuiUxynu5rN/1J62B9scjQE2aDzjIeQ3hAj68V+V NuKWemxQ/zLLJewEUJ2YMRDntZdn8FoGhpXtnueYNJAaeG3xAzBH3xMwBJQRXpoS Q54CcumZ07+X5cK7y0as3yLayrQmMnyNpAxILAsiLpCuG24YXDpncwP6izkgkaKq MogRGxUjuBluXbCKcu+4bQ4nVmsIH9qM0ILcih8Ek/sFqhKBvzlK4TPlqKP/LS51 +QcSopxX4okJEN8T3VLHyWb7Iw20XjjmjDfJewTZQaHdl1ay20SXsWaFmBXhczX0 I/YDpqdXr+ZIk7CFUbi0BHcJ6LNxJHakddARds+qDajtUlDYB9GVGersyCr5aDcp N9887JvRBWC3qODyN8W2CLzdMdTsmdIBYdkRNs3obhPzGetr41TDN0JafEaVw+9W m3jvzGABOrZGIGF3JFYsqYAG27fRlsR/FU+nu94chKYTOb7QrhOop9lj6NLJl4pU Ny+3vncMdkUJmcRikGf+ukXFBpZ+ISg+XqHCWBfUnN7ClCnnLmw= =3pk7 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
On Thu, Oct 25, 2018 at 5:15 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > All, > > Bump. > > I have a full patch at this point (still without documentation), but > this one includes resolution of the IV issue and also a set of unit > tests which pass. > > I'd appreciate it if someone could install this into their cluster and > see if it works. Just configure the interceptor into your interceptor > chain and set an encryption key (e.g. "cafebabecafebabe"). IMO you should commit it and people will test it then (you did and it works for you, right ?). With my storeconfig hat on, the encryptionKey should be more bean like, the poor thing will break otherwise (again ;) ). Rémy
Re: For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, Bump. I have a full patch at this point (still without documentation), but this one includes resolution of the IV issue and also a set of unit tests which pass. I'd appreciate it if someone could install this into their cluster and see if it works. Just configure the interceptor into your interceptor chain and set an encryption key (e.g. "cafebabecafebabe"). Thanks, - -chris On 10/23/18 16:14, Christopher Schultz wrote: > All, > > On 10/23/18 10:05, Christopher Schultz wrote: >> 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. > >> 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. > > For the record, I haven't tested this AT ALL. I just made it > compile :) > > If someone has a test-cluster available, could you please try to > add this (it just requires an "encryptionKey" attribute on the > interceptor... just use "cafebabe" or something simple) and see if > (a) the messages flow properly and (b) they transmit in > non-plaintext? > > Thanks, -chris > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvR3hcACgkQHPApP6U8 pFiQjQ/+OOneeU7lH84A/qzplSjPkyYFunMhAVhhK3bO+dMEjYT+Hw5kWcvtudAA x3djNxKBz2BGB5cva2K7022iMfrC5wKJzQV9CP5/VRgObu+klQem7ui8g8hqVizT emEbkojYjzudNygjzhpT1CQgEWoUBGL3g1ssR6uY8RS72O9Jr9G9y/WFMusFCiXH ERYSY9Wv/e5+gB8+k1jtJS1idAB3ZrTT3qjfEKl4q3gerdX4NU/fQOtRdISoj54m qUjRaSas+x53QHpCbqVlQbuDNlS4cIHrmXNj4hVuaiCon8yYaeV6LGdadSPnP7a2 AXg81MQjL667rv8o91Tw+3NgaepljwrXhiVqtUFuhFCsomTUQTjkqSZNmD3Z27D3 jVjZzmRi6oDM6niDNFulkTpnr9mTe3KuE58dG2TvtpqrZVN2JIjc/bssbVVzqhtV j5SwmMdehDAy96eguE+MzXXEvpMbI4PJ8HaTg80A9dDihd6vCUI7XXHeE70YVqvT r+kZgqGykLnXpiWB4u5oNAKDFlvV9N2WzK4UaaZV+Kr8rhij0Us7ajrO+619NYY9 KAUtRksXzTo0VOl5k3SdLV37HwKaqH+3/s/19nULHyjSLgGM/r4WxqBTgjvcM8Tn yokrOxCaFgwZWWhInXHi07Z6Wz0Eqn8GoB13rNxP+z3vGOlVr6g= =XEXS -END PGP SIGNATURE- Index: java/org/apache/catalina/tribes/group/interceptors/EncryptInterceptor.java === --- java/org/apache/catalina/tribes/group/interceptors/EncryptInterceptor.java (nonexistent) +++ java/org/apache/catalina/tribes/group/interceptors/EncryptInterceptor.java (working copy) @@ -0,0 +1,292 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.catalina.tribes.group.interceptors; + +import java.security.GeneralSecurityException; +import java.security.SecureRandom; + +import javax.crypto.BadPaddingException; +import javax.crypto.Cipher; +import javax.crypto.IllegalBlockSizeException; +import javax.crypto.spec.IvParameterSpec; +import javax.crypto.spec.SecretKeySpec; + +import org.apache.catalina.tribes.Channel; +import org.apache.catalina.tribes.ChannelException; +import org.apache.catalina.tribes.ChannelMessage; +import org.apache.catalina.tribes.Member; +import org.apache.catalina.tribes.group.ChannelInterceptorBase; +import org.apache.catalina.tribes.group.InterceptorPayload; +import org.apache.catalina.tribes.io.XByteBuffer; +import org.apache.catalina.tribes.util.StringManager; +import org.apache.juli.logging.Log; +import org.apache.juli.logging.LogFactory; +import org.apache.tomcat.util.buf.HexUtils; + +/** + * Adds encryption using a pre-shared key. + * + * The length of the key (in bytes) must be acceptable for the encryption + * algorithm being used. For example, for AES, you must use a key of either + * 16 bytes (128 bits, 24 bytes 192 bits), or 32 bytes (256 bits). + * + * You can supply the raw key bytes by calling {@link #setEncryptionKey(byte[])} + * or the hex-encoded binary bytes by calling + * {@link #setEncryptio
Re: For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 10/23/18 10:05, Christopher Schultz wrote: > 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. > > 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. For the record, I haven't tested this AT ALL. I just made it compile :) If someone has a test-cluster available, could you please try to add this (it just requires an "encryptionKey" attribute on the interceptor... just use "cafebabe" or something simple) and see if (a) the messages flow properly and (b) they transmit in non-plaintext? Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPgRMACgkQHPApP6U8 pFgROg//db0iK87mkSIVs/so72nemDkmUjjz158ccjl8AT7cLzEbEanPB0/3TghT lKuQKeQRD97xYbNbFCxoWdowkaEt25w0Qpl3mht363jFdF9xPLCYMj7xtLc7brv6 m/KTHhcbsBb4cgkOK1o6gcbzKUmPB2v5IWhIPG09Aa9rce2yT9TNjAyyARqcOdp0 tuh0jT8ksvuojM6u9hfOvrK8xO5GX223ljPCHNBQvqprqOaOtoKfN349BvZx3MvZ vwn+cn5fKbmU6hucq5X0kBVg7r4SbhGt3+S3a7VLfl3cWAxf3jzkq45KHsB8/gON RoI2AqDqD9w9pDQ1CZAG953nAFAnKDR1xng63MDNgD05w34hkGloMe4ytJjX4tLL kOr0vx1pqfKSYEqTzoJUfTzgaKmDW7WBYNM/JsrJ+jG+Y0/xdQDIvyEsBgozVVWK bIMXibAviXHypnY1UfhVgJgpgWwhra+XGJEbGYHEtQijClM0NRaERsQaVGCxbkbA ncbi0EwHw2MC5cRZZdY38sxPbYVk9omcQywTiaIHxtQA0FZxRP/r/NNMnw5X2UXA 7+ox7mrjpleaf6dB2CxNl5Yc/186wqSicsw93ekLNm1RyuN0bHOQzyKJ/rWMae+S wt9iED9aidu4go4fKplugb436KSHVSksVcFwnjDX0aEj1Dq/T70= =5+TL -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
-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
Re: For review: EncryptInterceptor for Cluster/Tribes
On 23/10/2018 18:19, Filip Hanik wrote: On Tue, Oct 23, 2018 at 7:05 AM Christopher Schultz < ch...@christopherschultz.net> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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? or do you want a WhatsApp type of security, where only sender and receiver can share the a specific data package? 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? 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. That brings you back to the full TLS style solution with trust-stores and associated certificate authority management. If you skip that, you open yourself up to MITM attacks. I think a shared symmetric key is a reasonable solution to this use case. Requiring the user to specify the key and the iv seems reasonable to me. Mark Filip Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPKqsACgkQHPApP6U8 pFgGSxAAy1vj8FY7uzcvstimHwUGKd6dJkFiKRxygY30Lp3bHor5O4GKoWP4eWwJ l0rl0ojvhgLzHwPB/+Cdm1gpZD2cSSiqyz3V6eGlt8oq8mm3M4lCMqZqXckNHYG5 cSRHXPIO0XaoCrUR2KA4NRS207OXTUYZe7ihPb0Bblev5SE/S/vIArRs+1Gybdi+ zYXY4XwBUHRHu2PzWy6c0HFPP3hDJ85I3Mn4O/uqZgh01eRRpsfvbmros45znTfc frKqBeT3O/+dwNOX9HhshnIW92U8dyYto70CsKdtPrsVXpY9kQH3zOc3vC+UN2qf jJZYie32mHjg22JDrYOqFpfAhTQi9r4xUMzprMVjTk93p34SxvmZNbLBVi/Li6OA PdthMBpHiAQp+bLVGSU4UbHdEG9t/Ixp8RodWJzxGWtduy3/GGCsifQke5H6yBf5 Kb3Rux4u/3mKwn0PZL8HljUgEZCge3g1+KOX1qL9Uw5TCKm4YIF744C1P7piSllR GW3UxamATH4qmZ/ccAUJVBgdQQYPjVKAc0tAvCVBZSxf6+OB8D5HfA/A8f8N7Fzj wBVPbcW5d4OjFpjEshOtehb74q1WAGhg1+rUkPbd1Nkd/WTQN8YXXayN0+TE28gm LPSv8RSsAEWFLzh/TiY8BNzdehEaHID6R6h5q7io9JNMbtljhgQ= =nSgU -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: For review: EncryptInterceptor for Cluster/Tribes
On Tue, Oct 23, 2018 at 7:05 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > 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? or do you want a WhatsApp type of security, where only sender and receiver can share the a specific data package? > > 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? 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. Filip > > Thanks, > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPKqsACgkQHPApP6U8 > pFgGSxAAy1vj8FY7uzcvstimHwUGKd6dJkFiKRxygY30Lp3bHor5O4GKoWP4eWwJ > l0rl0ojvhgLzHwPB/+Cdm1gpZD2cSSiqyz3V6eGlt8oq8mm3M4lCMqZqXckNHYG5 > cSRHXPIO0XaoCrUR2KA4NRS207OXTUYZe7ihPb0Bblev5SE/S/vIArRs+1Gybdi+ > zYXY4XwBUHRHu2PzWy6c0HFPP3hDJ85I3Mn4O/uqZgh01eRRpsfvbmros45znTfc > frKqBeT3O/+dwNOX9HhshnIW92U8dyYto70CsKdtPrsVXpY9kQH3zOc3vC+UN2qf > jJZYie32mHjg22JDrYOqFpfAhTQi9r4xUMzprMVjTk93p34SxvmZNbLBVi/Li6OA > PdthMBpHiAQp+bLVGSU4UbHdEG9t/Ixp8RodWJzxGWtduy3/GGCsifQke5H6yBf5 > Kb3Rux4u/3mKwn0PZL8HljUgEZCge3g1+KOX1qL9Uw5TCKm4YIF744C1P7piSllR > GW3UxamATH4qmZ/ccAUJVBgdQQYPjVKAc0tAvCVBZSxf6+OB8D5HfA/A8f8N7Fzj > wBVPbcW5d4OjFpjEshOtehb74q1WAGhg1+rUkPbd1Nkd/WTQN8YXXayN0+TE28gm > LPSv8RSsAEWFLzh/TiY8BNzdehEaHID6R6h5q7io9JNMbtljhgQ= > =nSgU > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org
For review: EncryptInterceptor for Cluster/Tribes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. 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? Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvPKqsACgkQHPApP6U8 pFgGSxAAy1vj8FY7uzcvstimHwUGKd6dJkFiKRxygY30Lp3bHor5O4GKoWP4eWwJ l0rl0ojvhgLzHwPB/+Cdm1gpZD2cSSiqyz3V6eGlt8oq8mm3M4lCMqZqXckNHYG5 cSRHXPIO0XaoCrUR2KA4NRS207OXTUYZe7ihPb0Bblev5SE/S/vIArRs+1Gybdi+ zYXY4XwBUHRHu2PzWy6c0HFPP3hDJ85I3Mn4O/uqZgh01eRRpsfvbmros45znTfc frKqBeT3O/+dwNOX9HhshnIW92U8dyYto70CsKdtPrsVXpY9kQH3zOc3vC+UN2qf jJZYie32mHjg22JDrYOqFpfAhTQi9r4xUMzprMVjTk93p34SxvmZNbLBVi/Li6OA PdthMBpHiAQp+bLVGSU4UbHdEG9t/Ixp8RodWJzxGWtduy3/GGCsifQke5H6yBf5 Kb3Rux4u/3mKwn0PZL8HljUgEZCge3g1+KOX1qL9Uw5TCKm4YIF744C1P7piSllR GW3UxamATH4qmZ/ccAUJVBgdQQYPjVKAc0tAvCVBZSxf6+OB8D5HfA/A8f8N7Fzj wBVPbcW5d4OjFpjEshOtehb74q1WAGhg1+rUkPbd1Nkd/WTQN8YXXayN0+TE28gm LPSv8RSsAEWFLzh/TiY8BNzdehEaHID6R6h5q7io9JNMbtljhgQ= =nSgU -END PGP SIGNATURE- /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.apache.catalina.tribes.group.interceptors; import java.security.GeneralSecurityException; import java.security.Key; import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import org.apache.catalina.tribes.Channel; import org.apache.catalina.tribes.ChannelException; import org.apache.catalina.tribes.ChannelMessage; import org.apache.catalina.tribes.Member; import org.apache.catalina.tribes.group.ChannelInterceptorBase; import org.apache.catalina.tribes.group.InterceptorPayload; import org.apache.catalina.tribes.util.StringManager; import org.apache.juli.logging.Log; import org.apache.juli.logging.LogFactory; import org.apache.tomcat.util.buf.HexUtils; /** * Adds encryption using a pre-shared key. */ public class EncryptInterceptor extends ChannelInterceptorBase { private static final Log log = LogFactory.getLog(EncryptInterceptor.class); protected static final StringManager sm = StringManager.getManager(EncryptInterceptor.class); private static final String DEFAULT_ENCRYPTION_ALGORITHM = "AES/CBC/PKCS5Padding"; private String providerName; private String encryptionAlgorithm = DEFAULT_ENCRYPTION_ALGORITHM; private Key encryptionKey; private Cipher encryptionCipher; private Cipher decryptionCipher; public EncryptInterceptor() { } @Override public void start(int svc) throws ChannelException { super.start(svc); if(Channel.SND_TX_SEQ == svc) { try { initCiphers(); } catch (GeneralSecurityException gse) { log.fatal(sm.getString("encryptInterceptor.init.failed")); throw new ChannelException(sm.getString("encryptInterceptor.init.failed"), gse); } } } @Override public void sendMessage(Member[] destination, ChannelMessage msg, InterceptorPayload payload) throws ChannelException { try { byte[] data = msg.getMessage().getBytes(); data = encrypt(data); msg.getMessage().trim(msg.getMessage().getLength()); msg.getMessage().append(data,0,data.length); super.sendMessage(destination, msg, payload); } catch (GeneralSecurityException gse) { log.error(sm.getString("encryptInterceptor.encrypt.failed")); throw new ChannelException(gse); } } @Override public void messageReceived(ChannelMessage msg)