[infinispan-dev] Hot Rod secured by default

Sebastian Laskawiec slaskawi at redhat.com
Fri Mar 31 09:55:15 EDT 2017


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.berindei at 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 <wfink at 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 <dereed at 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 <ttarrant at redhat.com
> >> >> <mailto:ttarrant at 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 at lists.jboss.org
> >> >> <mailto:infinispan-dev at lists.jboss.org>
> >> >>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> infinispan-dev mailing list
> >> >> infinispan-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> >>
> >> >
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170331/c00313ba/attachment.html 


More information about the infinispan-dev mailing list