On Mon, Apr 3, 2017 at 1:52 PM, Sebastian Laskawiec <slask...@redhat.com> wrote:
> That's actually a very good point but it deserves separate discussion I > think. > > The point is that we get an initialized SSLEngine from WF. Then we simply > build Netty's JdkSslContext [1] (as you probably know, Netty uses its own > SSLContext; this JdkSslContext class acts as a bridge between Netty (it > implements Netty's SslContext) and JDK (it can be created from JDK's > SSLContext) world). > > So if we want to depend on WF/Elytron-based SSL initialization, we need to > either stick to JDK's SSLContext or implement our own JDK's > SSLContext/Netty's OpenSSLContext [2] bridge. I created a JIRA [3] to > implement this. > AFAICT, Wildfly 11 should export a "org.wildfly.security.ssl-context" capability to allow plugging in custom engines. Gustavo > > [1] https://github.com/infinispan/infinispan/blob/fd3061a684 > c13aa7c22d215f43910735bf7ff4a6/server/router/src/main/java/ > org/infinispan/server/router/router/impl/hotrod/handlers/ > util/SslUtils.java#L35 > [2] https://github.com/netty/netty/blob/a2304287a170dc140319 > 28d6d2a3374705305839/handler/src/main/java/io/netty/ > handler/ssl/OpenSslContext.java > [3] https://issues.jboss.org/browse/ISPN-7694 > > On Fri, Mar 31, 2017 at 6:02 PM Tristan Tarrant <ttarr...@redhat.com> > wrote: > > You want to use OpenSSL with Netty: > > http://netty.io/wiki/requirements-for-4.x.html#wiki-h4-4 > > Tristan > > On 31/03/2017 15:55, Sebastian Laskawiec wrote: > > Unfortunately TLS still slows down stuff (a lot). When I was doing tests > > for the multi-tenancy router (which is based on TLS/SNI), my average > > results were like this: > > > > Use-caseTypeAvgError > > initConnectionAndPerform10KPutsSingleServerNoSsl1034.81714.424 > > initConnectionAndPerform10KPutsSingleServerWithSsl1567.55324.872 > > initConnectionAndPerform10KPutsTwoServersWithSslSni1563.22934.05 > > initConnectionOnlySingleServerNoSsl*3.389*0.198 > > initConnectionOnlySingleServerWithSsl*14.086*0.794 > > initConnectionOnlyTwoServersWithSslSni*14.722*0.684 > > perform10KPutsSingleServerNoSsl*4.602*0.585 > > perform10KPutsSingleServerWithSsl*16.583*0.198 > > perform10KPutsTwoServersWithSslSni*17.02*0.794 > > > > This is nothing new, but initializing Hot Rod connection took was ~4 > > times slower and putting 10K random strings (UUIDs) was also ~4 times > > slower. But what's worth to mention, there is no significant difference > > between TLS and TLS+SNI. > > > > As far as I know, it is possible to install specialized hardware to deal > > with encryption in data centers. It is called SSL Acceleration [1]. > > However I'm not aware of any special processor instructions that can > > help you with that. But the implementations are getting better and > > better, so who knows... > > > > But getting back to the original question, I think the problem we are > > trying to solve (correct me if I'm wrong) is to prevent unauthorized > > folks to put their hands on a victims data (either pushing something > > malicious/corrupted to the cache or obtaining something from the cache). > > Another problem is transmission security - encryption. If we want our > > new devs to be secured out of the box, I think we should do both - use > > TLS (without trusting all certificated) and authentication. This makes > > Infinispan harder to use of course. So the other extremum is to turn > > both things off. > > > > I voted for the latter, making Infinispan super easy to use. But you > > guys convinced me that we should care about the security in this case > > too, so I would use PLAIN authentication + TLS. I would also love to see > > one magic switch, for example `./bin/standalone.sh --dev-mode`, which > > would turn all security off. > > > > Thanks, > > Sebastian > > > > [1] https://en.wikipedia.org/wiki/SSL_acceleration > > > > > > On Thu, Mar 30, 2017 at 9:22 PM Dan Berindei <dan.berin...@gmail.com > > <mailto:dan.berin...@gmail.com>> wrote: > > > > I agree with Radim, PLAIN authentication without encryption makes it > > too easy to sniff the password from another machine. > > > > I have no idea how expensive SSL encryption is in WildFly, but I > think > > all recent processors have specialized instructions for helping with > > encryption, so it may not be that bad. > > > > Even with encryption, if the client trusts all certs, it may be > > possible for an attacker to insert itself in the middle and decode > > everything -- depending on network topology and what kind of access > > the attacker already has. I think it only makes sense to trust all > > certs if we also implement something like HPKP [1], to make it more > > like ssh. > > > > [1]: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning > > > > Cheers > > Dan > > > > > > > > On Thu, Mar 30, 2017 at 7:07 PM, Wolf Fink <wf...@redhat.com > > <mailto:wf...@redhat.com>> wrote: > > > +1 to make the default secure. > > > > > > -1 SSL by default as it makes it slower and I think not most will > > use it > > > > > > -1 easy trust all certs, That sounds to me we close one door and > > make it > > > possible to open another one > > > > > > > > > What if we add an example configuration unsecured which can be > > simple copied > > > for examples and to start. > > > > > > > > > On Thu, Mar 30, 2017 at 5:31 PM, Dennis Reed <der...@redhat.com > > <mailto:der...@redhat.com>> wrote: > > >> > > >> +1 to authentication and encryption by default. > > >> This is 2017, that's how *everything* should be configured. > > >> > > >> -1 to making it easy to trust all certs. That negates the point > of > > >> using encryption in the first place and should really never be > done. > > >> > > >> If it's too hard to configure the correct way that we think it > would > > >> turn users away, that's a usability problem that needs to be > fixed. > > >> > > >> -Dennis > > >> > > >> > > >> On 03/30/2017 09:29 AM, Tristan Tarrant wrote: > > >> > While the "unsecure" over loopback is quite tempting, I would > > prefer to > > >> > have homogeneous behaviour with the possibility to disable > > security > > >> > altogether for quick demos. > > >> > Otherwise a developer would need to code differently for the > > local use > > >> > case than for the remote one, causing more confusion. > > >> > > > >> > Tristan > > >> > > > >> > On 30/03/2017 14:54, Sebastian Laskawiec wrote: > > >> >> I agree the security out of the box is good. But at the same > > time we > > >> >> don't want to make Infinispan harder to use for new > > developers. Out of > > >> >> the box configuration should be "good enough" to start > hacking. > > >> >> > > >> >> I would propose to make all the endpoints unprotected (with > > >> >> authentication disabled) on localhost/loopback and protected > when > > >> >> calling from the outside world. > > >> >> > > >> >> On Thu, Mar 30, 2017 at 2:39 PM Tristan Tarrant > > <ttarr...@redhat.com <mailto:ttarr...@redhat.com> > > >> >> <mailto:ttarr...@redhat.com <mailto:ttarr...@redhat.com>>> > wrote: > > >> >> > > >> >> Dear all, > > >> >> > > >> >> after a mini chat on IRC, I wanted to bring this to > > everybody's > > >> >> attention. > > >> >> > > >> >> We should make the Hot Rod endpoint require > > authentication in the > > >> >> out-of-the-box configuration. > > >> >> The proposal is to enable the PLAIN (or, preferably, > > DIGEST) SASL > > >> >> mechanism against the ApplicationRealm and require users > > to run the > > >> >> add-user script. > > >> >> This would achieve two goals: > > >> >> - secure out-of-the-box configuration, which is always a > > good idea > > >> >> - access to the "protected" schema and script caches > which is > > >> >> prevented > > >> >> when not on loopback on non-authenticated endpoints. > > >> >> > > >> >> Tristan > > >> >> -- > > >> >> Tristan Tarrant > > >> >> Infinispan Lead > > >> >> JBoss, a division of Red Hat > > >> >> _______________________________________________ > > >> >> infinispan-dev mailing list > > >> >> infinispan-dev@lists.jboss.org > > <mailto:infinispan-dev@lists.jboss.org> > > >> >> <mailto:infinispan-dev@lists.jboss.org > > <mailto:infinispan-dev@lists.jboss.org>> > > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > >> >> > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> infinispan-dev mailing list > > >> >> infinispan-dev@lists.jboss.org > > <mailto:infinispan-dev@lists.jboss.org> > > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > >> >> > > >> > > > >> _______________________________________________ > > >> infinispan-dev mailing list > > >> infinispan-dev@lists.jboss.org > > <mailto:infinispan-dev@lists.jboss.org> > > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > > > > > > > _______________________________________________ > > > infinispan-dev mailing list > > > infinispan-dev@lists.jboss.org > > <mailto:infinispan-dev@lists.jboss.org> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org <mailto:infinispan-dev@lists.j > boss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
