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-case Type Avg Error initConnectionAndPerform10KPuts SingleServerNoSsl 1034.817 14.424 initConnectionAndPerform10KPuts SingleServerWithSsl 1567.553 24.872 initConnectionAndPerform10KPuts TwoServersWithSslSni 1563.229 34.05 initConnectionOnly SingleServerNoSsl *3.389* 0.198 initConnectionOnly SingleServerWithSsl *14.086* 0.794 initConnectionOnly TwoServersWithSslSni *14.722* 0.684 perform10KPuts SingleServerNoSsl *4.602* 0.585 perform10KPuts SingleServerWithSsl *16.583* 0.198 perform10KPuts TwoServersWithSslSni *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> 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> 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> 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>> 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> > >> >> 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 > > > > > > > > _______________________________________________ > > 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
