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@gmail.com
> <mailto:dan.berindei@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@redhat.com
>     <mailto:wfink@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@redhat.com
>     <mailto:dereed@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@redhat.com <mailto:ttarrant@redhat.com>
>      >> >> <mailto:ttarrant@redhat.com <mailto:ttarrant@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.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
>

--
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