[infinispan-dev] Hot Rod secured by default

[Dan Berindei]

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> 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> 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>> 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>
>> >>     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
>> >>
>> >
>> _______________________________________________
>> infinispan-dev mailing list
>> 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