[infinispan-dev] Netty SSL Context, was [Hot Rod secured by default]
Sebastian Laskawiec
slaskawi at redhat.com
Thu Jun 1 05:51:46 EDT 2017
I think I've just found the reason why we can not migrate in OpenSSL by
default :(
In server scenario we obtain S*SL*Context (the one from JDK; Netty has
similar S*sl*Context) from WildFly. It is already configured along with
sercurity realms, domains etc. We then get into this branch of code [1].
In order to do fancy things like SNI we need to remap JDK's SSLContext into
Netty's SslContext and the only implementation that can consume SSLContext
we have at hand is JdkSslContext.
I honestly have no idea how we could refactor this... And that's a shame
because OpenSSL is way faster...
[1]
https://github.com/infinispan/infinispan/blob/830b5314e5d6763aff239584026a7a9d15f01666/server/core/src/main/java/org/infinispan/server/core/utils/SslUtils.java#L29-L29
On Fri, Mar 31, 2017 at 6:02 PM Tristan Tarrant <ttarrant at 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.berindei at gmail.com
> > <mailto: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
> > <mailto: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
> > <mailto: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>
> > >> >> <mailto: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>
> > >> >> <mailto: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
> > <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
> > <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
> > <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 <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
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170601/95f0c0ed/attachment-0001.html
More information about the infinispan-dev
mailing list