<div dir="ltr">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:<div><div><br></div><div>Use-case<span class="Apple-tab-span" style="white-space:pre"> </span>Type<span class="Apple-tab-span" style="white-space:pre"> </span>Avg<span class="Apple-tab-span" style="white-space:pre"> </span>Error</div><div>initConnectionAndPerform10KPuts<span class="Apple-tab-span" style="white-space:pre"> </span>SingleServerNoSsl<span class="Apple-tab-span" style="white-space:pre"> </span>1034.817<span class="Apple-tab-span" style="white-space:pre"> </span>14.424</div><div>initConnectionAndPerform10KPuts<span class="Apple-tab-span" style="white-space:pre"> </span>SingleServerWithSsl<span class="Apple-tab-span" style="white-space:pre"> </span>1567.553<span class="Apple-tab-span" style="white-space:pre"> </span>24.872</div><div>initConnectionAndPerform10KPuts<span class="Apple-tab-span" style="white-space:pre"> </span>TwoServersWithSslSni<span class="Apple-tab-span" style="white-space:pre"> </span>1563.229<span class="Apple-tab-span" style="white-space:pre"> </span>34.05</div><div>initConnectionOnly<span class="Apple-tab-span" style="white-space:pre"> </span>SingleServerNoSsl<span class="Apple-tab-span" style="white-space:pre"> </span><b><font color="#38761d">3.389</font></b><span class="Apple-tab-span" style="white-space:pre"> </span>0.198</div><div>initConnectionOnly<span class="Apple-tab-span" style="white-space:pre"> </span>SingleServerWithSsl<span class="Apple-tab-span" style="white-space:pre"> </span><b><font color="#38761d">14.086</font></b><span class="Apple-tab-span" style="white-space:pre"> </span>0.794</div><div>initConnectionOnly<span class="Apple-tab-span" style="white-space:pre"> </span>TwoServersWithSslSni<span class="Apple-tab-span" style="white-space:pre"> </span><b><font color="#38761d">14.722</font></b><span class="Apple-tab-span" style="white-space:pre"> </span>0.684</div><div>perform10KPuts<span class="Apple-tab-span" style="white-space:pre"> </span>SingleServerNoSsl<span class="Apple-tab-span" style="white-space:pre"> </span><b><font color="#ff0000">4.602</font></b><span class="Apple-tab-span" style="white-space:pre"> </span>0.585</div><div>perform10KPuts<span class="Apple-tab-span" style="white-space:pre"> </span>SingleServerWithSsl<span class="Apple-tab-span" style="white-space:pre"> </span><b><font color="#ff0000">16.583</font></b><span class="Apple-tab-span" style="white-space:pre"> </span>0.198</div><div>perform10KPuts<span class="Apple-tab-span" style="white-space:pre"> </span>TwoServersWithSslSni<span class="Apple-tab-span" style="white-space:pre"> </span><b><font color="#ff0000">17.02</font></b><span class="Apple-tab-span" style="white-space:pre"> </span>0.794</div></div><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Sebastian</div><div><br></div><div>[1] <a href="https://en.wikipedia.org/wiki/SSL_acceleration">https://en.wikipedia.org/wiki/SSL_acceleration</a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 30, 2017 at 9:22 PM Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Radim, PLAIN authentication without encryption makes it<br class="gmail_msg">
too easy to sniff the password from another machine.<br class="gmail_msg">
<br class="gmail_msg">
I have no idea how expensive SSL encryption is in WildFly, but I think<br class="gmail_msg">
all recent processors have specialized instructions for helping with<br class="gmail_msg">
encryption, so it may not be that bad.<br class="gmail_msg">
<br class="gmail_msg">
Even with encryption, if the client trusts all certs, it may be<br class="gmail_msg">
possible for an attacker to insert itself in the middle and decode<br class="gmail_msg">
everything -- depending on network topology and what kind of access<br class="gmail_msg">
the attacker already has. I think it only makes sense to trust all<br class="gmail_msg">
certs if we also implement something like HPKP [1], to make it more<br class="gmail_msg">
like ssh.<br class="gmail_msg">
<br class="gmail_msg">
[1]: <a href="https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning" rel="noreferrer" class="gmail_msg" target="_blank">https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning</a><br class="gmail_msg">
<br class="gmail_msg">
Cheers<br class="gmail_msg">
Dan<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Thu, Mar 30, 2017 at 7:07 PM, Wolf Fink <<a href="mailto:wfink@redhat.com" class="gmail_msg" target="_blank">wfink@redhat.com</a>> wrote:<br class="gmail_msg">
> +1 to make the default secure.<br class="gmail_msg">
><br class="gmail_msg">
> -1 SSL by default as it makes it slower and I think not most will use it<br class="gmail_msg">
><br class="gmail_msg">
> -1 easy trust all certs, That sounds to me we close one door and make it<br class="gmail_msg">
> possible to open another one<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> What if we add an example configuration unsecured which can be simple copied<br class="gmail_msg">
> for examples and to start.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> On Thu, Mar 30, 2017 at 5:31 PM, Dennis Reed <<a href="mailto:dereed@redhat.com" class="gmail_msg" target="_blank">dereed@redhat.com</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> +1 to authentication and encryption by default.<br class="gmail_msg">
>> This is 2017, that's how *everything* should be configured.<br class="gmail_msg">
>><br class="gmail_msg">
>> -1 to making it easy to trust all certs. That negates the point of<br class="gmail_msg">
>> using encryption in the first place and should really never be done.<br class="gmail_msg">
>><br class="gmail_msg">
>> If it's too hard to configure the correct way that we think it would<br class="gmail_msg">
>> turn users away, that's a usability problem that needs to be fixed.<br class="gmail_msg">
>><br class="gmail_msg">
>> -Dennis<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> On 03/30/2017 09:29 AM, Tristan Tarrant wrote:<br class="gmail_msg">
>> > While the "unsecure" over loopback is quite tempting, I would prefer to<br class="gmail_msg">
>> > have homogeneous behaviour with the possibility to disable security<br class="gmail_msg">
>> > altogether for quick demos.<br class="gmail_msg">
>> > Otherwise a developer would need to code differently for the local use<br class="gmail_msg">
>> > case than for the remote one, causing more confusion.<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > Tristan<br class="gmail_msg">
>> ><br class="gmail_msg">
>> > On 30/03/2017 14:54, Sebastian Laskawiec wrote:<br class="gmail_msg">
>> >> I agree the security out of the box is good. But at the same time we<br class="gmail_msg">
>> >> don't want to make Infinispan harder to use for new developers. Out of<br class="gmail_msg">
>> >> the box configuration should be "good enough" to start hacking.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> I would propose to make all the endpoints unprotected (with<br class="gmail_msg">
>> >> authentication disabled) on localhost/loopback and protected when<br class="gmail_msg">
>> >> calling from the outside world.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> On Thu, Mar 30, 2017 at 2:39 PM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com" class="gmail_msg" target="_blank">ttarrant@redhat.com</a><br class="gmail_msg">
>> >> <mailto:<a href="mailto:ttarrant@redhat.com" class="gmail_msg" target="_blank">ttarrant@redhat.com</a>>> wrote:<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Dear all,<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> after a mini chat on IRC, I wanted to bring this to everybody's<br class="gmail_msg">
>> >> attention.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> We should make the Hot Rod endpoint require authentication in the<br class="gmail_msg">
>> >> out-of-the-box configuration.<br class="gmail_msg">
>> >> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL<br class="gmail_msg">
>> >> mechanism against the ApplicationRealm and require users to run the<br class="gmail_msg">
>> >> add-user script.<br class="gmail_msg">
>> >> This would achieve two goals:<br class="gmail_msg">
>> >> - secure out-of-the-box configuration, which is always a good idea<br class="gmail_msg">
>> >> - access to the "protected" schema and script caches which is<br class="gmail_msg">
>> >> prevented<br class="gmail_msg">
>> >> when not on loopback on non-authenticated endpoints.<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Tristan<br class="gmail_msg">
>> >> --<br class="gmail_msg">
>> >> Tristan Tarrant<br class="gmail_msg">
>> >> Infinispan Lead<br class="gmail_msg">
>> >> JBoss, a division of Red Hat<br class="gmail_msg">
>> >> _______________________________________________<br class="gmail_msg">
>> >> infinispan-dev mailing list<br class="gmail_msg">
>> >> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
>> >> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a>><br class="gmail_msg">
>> >> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> _______________________________________________<br class="gmail_msg">
>> >> infinispan-dev mailing list<br class="gmail_msg">
>> >> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
>> >> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
>> >><br class="gmail_msg">
>> ><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> infinispan-dev mailing list<br class="gmail_msg">
>> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> infinispan-dev mailing list<br class="gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
infinispan-dev mailing list<br class="gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
</blockquote></div>