<div dir="ltr">I think I've just found the reason why we can not migrate in OpenSSL by default :(<div><br></div><div>In server scenario we obtain S<b>SL</b>Context (the one from JDK; Netty has similar S<b>sl</b>Context) from WildFly. It is already configured along with sercurity realms, domains etc. We then get into this branch of code [1].</div><div><br></div><div>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.</div><div><br></div><div>I honestly have no idea how we could refactor this... And that's a shame because OpenSSL is way faster...</div><div><br></div><div>[1] <a href="https://github.com/infinispan/infinispan/blob/830b5314e5d6763aff239584026a7a9d15f01666/server/core/src/main/java/org/infinispan/server/core/utils/SslUtils.java#L29-L29">https://github.com/infinispan/infinispan/blob/830b5314e5d6763aff239584026a7a9d15f01666/server/core/src/main/java/org/infinispan/server/core/utils/SslUtils.java#L29-L29</a></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 31, 2017 at 6:02 PM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You want to use OpenSSL with Netty:<br>
<br>
<a href="http://netty.io/wiki/requirements-for-4.x.html#wiki-h4-4" rel="noreferrer" target="_blank">http://netty.io/wiki/requirements-for-4.x.html#wiki-h4-4</a><br>
<br>
Tristan<br>
<br>
On 31/03/2017 15:55, Sebastian Laskawiec wrote:<br>
> Unfortunately TLS still slows down stuff (a lot). When I was doing tests<br>
> for the multi-tenancy router (which is based on TLS/SNI), my average<br>
> results were like this:<br>
><br>
> Use-caseTypeAvgError<br>
> initConnectionAndPerform10KPutsSingleServerNoSsl1034.81714.424<br>
> initConnectionAndPerform10KPutsSingleServerWithSsl1567.55324.872<br>
> initConnectionAndPerform10KPutsTwoServersWithSslSni1563.22934.05<br>
> initConnectionOnlySingleServerNoSsl*3.389*0.198<br>
> initConnectionOnlySingleServerWithSsl*14.086*0.794<br>
> initConnectionOnlyTwoServersWithSslSni*14.722*0.684<br>
> perform10KPutsSingleServerNoSsl*4.602*0.585<br>
> perform10KPutsSingleServerWithSsl*16.583*0.198<br>
> perform10KPutsTwoServersWithSslSni*17.02*0.794<br>
><br>
> This is nothing new, but initializing Hot Rod connection took was ~4<br>
> times slower and putting 10K random strings (UUIDs) was also ~4 times<br>
> slower. But what's worth to mention, there is no significant difference<br>
> between TLS and TLS+SNI.<br>
><br>
> As far as I know, it is possible to install specialized hardware to deal<br>
> with encryption in data centers. It is called SSL Acceleration [1].<br>
> However I'm not aware of any special processor instructions that can<br>
> help you with that. But the implementations are getting better and<br>
> better, so who knows...<br>
><br>
> But getting back to the original question, I think the problem we are<br>
> trying to solve (correct me if I'm wrong) is to prevent unauthorized<br>
> folks to put their hands on a victims data (either pushing something<br>
> malicious/corrupted to the cache or obtaining something from the cache).<br>
> Another problem is transmission security - encryption. If we want our<br>
> new devs to be secured out of the box, I think we should do both - use<br>
> TLS (without trusting all certificated) and authentication. This makes<br>
> Infinispan harder to use of course. So the other extremum is to turn<br>
> both things off.<br>
><br>
> I voted for the latter, making Infinispan super easy to use. But you<br>
> guys convinced me that we should care about the security in this case<br>
> too, so I would use PLAIN authentication + TLS. I would also love to see<br>
> one magic switch, for example `./bin/standalone.sh --dev-mode`, which<br>
> would turn all security off.<br>
><br>
> Thanks,<br>
> Sebastian<br>
><br>
> [1] <a href="https://en.wikipedia.org/wiki/SSL_acceleration" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/SSL_acceleration</a><br>
><br>
><br>
> On Thu, Mar 30, 2017 at 9:22 PM Dan Berindei <<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a><br>
> <mailto:<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>>> wrote:<br>
><br>
> I agree with Radim, PLAIN authentication without encryption makes it<br>
> too easy to sniff the password from another machine.<br>
><br>
> I have no idea how expensive SSL encryption is in WildFly, but I think<br>
> all recent processors have specialized instructions for helping with<br>
> encryption, so it may not be that bad.<br>
><br>
> Even with encryption, if the client trusts all certs, it may be<br>
> possible for an attacker to insert itself in the middle and decode<br>
> everything -- depending on network topology and what kind of access<br>
> the attacker already has. I think it only makes sense to trust all<br>
> certs if we also implement something like HPKP [1], to make it more<br>
> like ssh.<br>
><br>
> [1]: <a href="https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning</a><br>
><br>
> Cheers<br>
> Dan<br>
><br>
><br>
><br>
> On Thu, Mar 30, 2017 at 7:07 PM, Wolf Fink <<a href="mailto:wfink@redhat.com" target="_blank">wfink@redhat.com</a><br>
> <mailto:<a href="mailto:wfink@redhat.com" target="_blank">wfink@redhat.com</a>>> wrote:<br>
> > +1 to make the default secure.<br>
> ><br>
> > -1 SSL by default as it makes it slower and I think not most will<br>
> use it<br>
> ><br>
> > -1 easy trust all certs, That sounds to me we close one door and<br>
> make it<br>
> > possible to open another one<br>
> ><br>
> ><br>
> > What if we add an example configuration unsecured which can be<br>
> simple copied<br>
> > for examples and to start.<br>
> ><br>
> ><br>
> > On Thu, Mar 30, 2017 at 5:31 PM, Dennis Reed <<a href="mailto:dereed@redhat.com" target="_blank">dereed@redhat.com</a><br>
> <mailto:<a href="mailto:dereed@redhat.com" target="_blank">dereed@redhat.com</a>>> wrote:<br>
> >><br>
> >> +1 to authentication and encryption by default.<br>
> >> This is 2017, that's how *everything* should be configured.<br>
> >><br>
> >> -1 to making it easy to trust all certs. That negates the point of<br>
> >> using encryption in the first place and should really never be done.<br>
> >><br>
> >> If it's too hard to configure the correct way that we think it would<br>
> >> turn users away, that's a usability problem that needs to be fixed.<br>
> >><br>
> >> -Dennis<br>
> >><br>
> >><br>
> >> On 03/30/2017 09:29 AM, Tristan Tarrant wrote:<br>
> >> > While the "unsecure" over loopback is quite tempting, I would<br>
> prefer to<br>
> >> > have homogeneous behaviour with the possibility to disable<br>
> security<br>
> >> > altogether for quick demos.<br>
> >> > Otherwise a developer would need to code differently for the<br>
> local use<br>
> >> > case than for the remote one, causing more confusion.<br>
> >> ><br>
> >> > Tristan<br>
> >> ><br>
> >> > On 30/03/2017 14:54, Sebastian Laskawiec wrote:<br>
> >> >> I agree the security out of the box is good. But at the same<br>
> time we<br>
> >> >> don't want to make Infinispan harder to use for new<br>
> developers. Out of<br>
> >> >> the box configuration should be "good enough" to start hacking.<br>
> >> >><br>
> >> >> I would propose to make all the endpoints unprotected (with<br>
> >> >> authentication disabled) on localhost/loopback and protected when<br>
> >> >> calling from the outside world.<br>
> >> >><br>
> >> >> On Thu, Mar 30, 2017 at 2:39 PM Tristan Tarrant<br>
> <<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a> <mailto:<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>><br>
> >> >> <mailto:<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a> <mailto:<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>>>> wrote:<br>
> >> >><br>
> >> >> Dear all,<br>
> >> >><br>
> >> >> after a mini chat on IRC, I wanted to bring this to<br>
> everybody's<br>
> >> >> attention.<br>
> >> >><br>
> >> >> We should make the Hot Rod endpoint require<br>
> authentication in the<br>
> >> >> out-of-the-box configuration.<br>
> >> >> The proposal is to enable the PLAIN (or, preferably,<br>
> DIGEST) SASL<br>
> >> >> mechanism against the ApplicationRealm and require users<br>
> to run the<br>
> >> >> add-user script.<br>
> >> >> This would achieve two goals:<br>
> >> >> - secure out-of-the-box configuration, which is always a<br>
> good idea<br>
> >> >> - access to the "protected" schema and script caches which is<br>
> >> >> prevented<br>
> >> >> when not on loopback on non-authenticated endpoints.<br>
> >> >><br>
> >> >> Tristan<br>
> >> >> --<br>
> >> >> Tristan Tarrant<br>
> >> >> Infinispan Lead<br>
> >> >> JBoss, a division of Red Hat<br>
> >> >> _______________________________________________<br>
> >> >> infinispan-dev mailing list<br>
> >> >> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> >> >> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>>><br>
> >> >> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >> _______________________________________________<br>
> >> >> infinispan-dev mailing list<br>
> >> >> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> >> >> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> >> >><br>
> >> ><br>
> >> _______________________________________________<br>
> >> infinispan-dev mailing list<br>
> >> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > infinispan-dev mailing list<br>
> > <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
<br>
--<br>
Tristan Tarrant<br>
Infinispan Lead<br>
JBoss, a division of Red Hat<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><p class="inbox-inbox-fullname-container" style="box-sizing:border-box;color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span class="inbox-inbox-firstname-container" style="box-sizing:border-box">SEBASTIAN</span><span class="inbox-inbox-Apple-converted-space"> </span><span class="inbox-inbox-lastname-container" style="box-sizing:border-box">ŁASKAWIEC</span></p><p class="inbox-inbox-position-container" style="box-sizing:border-box;color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span class="inbox-inbox-position" style="box-sizing:border-box">INFINISPAN DEVELOPER</span></p><p class="inbox-inbox-legal-container" style="box-sizing:border-box;font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a class="inbox-inbox-redhat-anchor" href="https://www.redhat.com/" target="_blank" style="box-sizing:border-box;color:rgb(0,136,206);margin:0px;text-decoration:none">Red Hat<span class="inbox-inbox-Apple-converted-space"> </span><span style="box-sizing:border-box">EMEA</span></a></p><table border="0" style="box-sizing:border-box;color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody style="box-sizing:border-box"><tr style="box-sizing:border-box"><td width="100px" style="box-sizing:border-box"><a href="https://red.ht/sig" style="box-sizing:border-box"><img width="90" height="auto" style="box-sizing: border-box;" src="https://www.redhat.com/files/brand/email/sig-redhat.png"></a></td></tr></tbody></table></div></div>