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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>> >>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>
>> >
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev