[infinispan-dev] Hot Rod secured by default

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Hot Rod secured by default

Tristan Tarrant-2
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Tristan Tarrant-2
Let me add another item:

combined with Sebastian's PR [1] we could also turn on encryption by
default using a self-signed certificate. We would also need to have an
easy option (i.e. a boolean, false by default) on the Hot Rod clients to
trust all certs.

This means that a Hot Rod client would need to be configured as follows:

ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder
   .security()
     .authentication()
       .username("user").realm("realm").password("password")
     .ssl()
       .enable().trustAll(true);

without having to manually set up callback handlers or trustmanagers.

I don't think this would affect the user experience too much.

Tristan

[1] https://github.com/infinispan/infinispan/pull/5036

On 30/03/2017 14:25, Tristan Tarrant 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Gustavo Fernandes-2
In reply to this post by Tristan Tarrant-2
+1

On Thu, Mar 30, 2017 at 1:25 PM, Tristan Tarrant <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Sebastian Laskawiec
In reply to this post by Tristan Tarrant-2
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Gustavo Fernandes-2
In reply to this post by Tristan Tarrant-2
-1 to SSL by default

On Thu, Mar 30, 2017 at 1:39 PM, Tristan Tarrant <[hidden email]> wrote:
Let me add another item:

combined with Sebastian's PR [1] we could also turn on encryption by
default using a self-signed certificate. We would also need to have an
easy option (i.e. a boolean, false by default) on the Hot Rod clients to
trust all certs.

This means that a Hot Rod client would need to be configured as follows:

ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder
   .security()
     .authentication()
       .username("user").realm("realm").password("password")
     .ssl()
       .enable().trustAll(true);

without having to manually set up callback handlers or trustmanagers.

I don't think this would affect the user experience too much.

Tristan

[1] https://github.com/infinispan/infinispan/pull/5036

On 30/03/2017 14:25, Tristan Tarrant 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Tristan Tarrant-2
In reply to this post by Sebastian Laskawiec
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 <[hidden email]
> <mailto:[hidden email]>> 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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Dennis Reed
+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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Gustavo Fernandes-2
On Thu, Mar 30, 2017 at 4:31 PM, Dennis Reed <[hidden email]> wrote:
+1 to authentication and encryption by default.
  This is 2017, that's how *everything* should be configured.

Agree, and SSL can always be turned on if needed.
But enabling it by default and forcing upfront handling of certificates, keystores and trustores is overkill IMO.
 

-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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Tristan Tarrant-2
In reply to this post by Dennis Reed


On 30/03/2017 17:31, Dennis Reed 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.
Well, none of the databases I know of require you to set up client side
truststores, so that is already a usability hurdle.

Tristan

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Radim Vansa
In reply to this post by Tristan Tarrant-2
I don't see an example/quickstart using security on the tutorials page
[1]. Could you provide one that would show what all would the user have
to configure in order to do HotRod hello world?

While secure OOTB is good, I like performant OOTB. And it seems to me
that "I need security" is something they'll probably think about when
deploying (if they need that), and will look it up, I wouldn't like to
see "turn off security" in the perf tuning guide. So I'd say -1 to SSL
by default.

-1 to PLAIN authentication without encryption, that's not a safe
default. [2]

Radim

[1] http://infinispan.org/tutorials/
[2] http://www.prokofiev.ru/prikol/pics/p12/winfirewall.jpg

On 03/30/2017 02:39 PM, Tristan Tarrant wrote:

> Let me add another item:
>
> combined with Sebastian's PR [1] we could also turn on encryption by
> default using a self-signed certificate. We would also need to have an
> easy option (i.e. a boolean, false by default) on the Hot Rod clients to
> trust all certs.
>
> This means that a Hot Rod client would need to be configured as follows:
>
> ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
> clientBuilder
>     .security()
>       .authentication()
>         .username("user").realm("realm").password("password")
>       .ssl()
>         .enable().trustAll(true);
>
> without having to manually set up callback handlers or trustmanagers.
>
> I don't think this would affect the user experience too much.
>
> Tristan
>
> [1] https://github.com/infinispan/infinispan/pull/5036
>
> On 30/03/2017 14:25, Tristan Tarrant 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


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Wolf Fink
In reply to this post by Dennis Reed
+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 <[hidden email]> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>> >> <mailto:[hidden email]>> 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
>> >>     [hidden email]
>> >> <mailto:[hidden email]>
>> >>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> infinispan-dev mailing list
>> >> [hidden email]
>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>
>> >
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Sebastian Laskawiec
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-case Type Avg Error
initConnectionAndPerform10KPuts SingleServerNoSsl 1034.817 14.424
initConnectionAndPerform10KPuts SingleServerWithSsl 1567.553 24.872
initConnectionAndPerform10KPuts TwoServersWithSslSni 1563.229 34.05
initConnectionOnly SingleServerNoSsl 3.389 0.198
initConnectionOnly SingleServerWithSsl 14.086 0.794
initConnectionOnly TwoServersWithSslSni 14.722 0.684
perform10KPuts SingleServerNoSsl 4.602 0.585
perform10KPuts SingleServerWithSsl 16.583 0.198
perform10KPuts TwoServersWithSslSni 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



On Thu, Mar 30, 2017 at 9:22 PM Dan Berindei <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>> >> <mailto:[hidden email]>> 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
>> >>     [hidden email]
>> >> <mailto:[hidden email]>
>> >>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> infinispan-dev mailing list
>> >> [hidden email]
>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>
>> >
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Tristan Tarrant-2
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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>
>      >> >> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >>
>      >> >>
>      >> >> _______________________________________________
>      >> >> infinispan-dev mailing list
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Sebastian Laskawiec
That's actually a very good point but it deserves separate discussion I think.

The point is that we get an initialized SSLEngine from WF. Then we simply build Netty's JdkSslContext [1] (as you probably know, Netty uses its own SSLContext; this JdkSslContext class acts as a bridge between Netty (it implements Netty's SslContext) and JDK (it can be created from JDK's SSLContext) world). 

So if we want to depend on WF/Elytron-based SSL initialization, we need to either stick to JDK's SSLContext or implement our own JDK's SSLContext/Netty's OpenSSLContext [2] bridge. I created a JIRA [3] to implement this.


On Fri, Mar 31, 2017 at 6:02 PM Tristan Tarrant <[hidden email]> wrote:
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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>
>      >> >> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >>
>      >> >>
>      >> >> _______________________________________________
>      >> >> infinispan-dev mailing list
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Gustavo Fernandes-2
On Mon, Apr 3, 2017 at 1:52 PM, Sebastian Laskawiec <[hidden email]> wrote:
That's actually a very good point but it deserves separate discussion I think.

The point is that we get an initialized SSLEngine from WF. Then we simply build Netty's JdkSslContext [1] (as you probably know, Netty uses its own SSLContext; this JdkSslContext class acts as a bridge between Netty (it implements Netty's SslContext) and JDK (it can be created from JDK's SSLContext) world). 

So if we want to depend on WF/Elytron-based SSL initialization, we need to either stick to JDK's SSLContext or implement our own JDK's SSLContext/Netty's OpenSSLContext [2] bridge. I created a JIRA [3] to implement this.


AFAICT, Wildfly 11 should export a "org.wildfly.security.ssl-context" capability to allow plugging in custom engines.

Gustavo
 


On Fri, Mar 31, 2017 at 6:02 PM Tristan Tarrant <[hidden email]> wrote:
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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>
>      >> >> <mailto:[hidden email] <mailto:[hidden email]>>> 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
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >>
>      >> >>
>      >> >> _______________________________________________
>      >> >> infinispan-dev mailing list
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Galder Zamarreño
In reply to this post by Tristan Tarrant-2
Hi all,

As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].

In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.

Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.

Cheers,

[1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
[2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
--
Galder Zamarreño
Infinispan, Red Hat

> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Gustavo Fernandes-2
On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
Hi all,

As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].

In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.

Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.


+1

Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
decide which one to pick based on the use case.

Gustavo.

 
Cheers,

[1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
[2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
--
Galder Zamarreño
Infinispan, Red Hat

> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Galder Zamarreño

--
Galder Zamarreño
Infinispan, Red Hat

> On 13 Apr 2017, at 09:50, Gustavo Fernandes <[hidden email]> wrote:
>
> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
> Hi all,
>
> As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].
>
> In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.
>
> Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.
>
>
> +1
>
> Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
> decide which one to pick based on the use case.

I think that's a better idea.

We could by default have a secured one, but switching to an insecure configuration should be doable with minimal effort, e.g. just switching config file.

As highlighted above, any secured configuration should work out-of-the-box with our docker images, e.g. WRT healthy/running checks.

Cheers,

>
> Gustavo.
>
>  
> Cheers,
>
> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
> [2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> 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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Hot Rod secured by default

Sebastian Laskawiec
I still think it would be better to create an extra switch to run infinispan in "development mode". This means no authentication, no encryption, possibly with JGroups stack tuned for fast discovery (especially in Kubernetes) and a big warning saying "You are in development mode, do not use this in production".

Just something very easy to get you going.

On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño <[hidden email]> wrote:

--
Galder Zamarreño
Infinispan, Red Hat

> On 13 Apr 2017, at 09:50, Gustavo Fernandes <[hidden email]> wrote:
>
> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
> Hi all,
>
> As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].
>
> In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.
>
> Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.
>
>
> +1
>
> Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
> decide which one to pick based on the use case.

I think that's a better idea.

We could by default have a secured one, but switching to an insecure configuration should be doable with minimal effort, e.g. just switching config file.

As highlighted above, any secured configuration should work out-of-the-box with our docker images, e.g. WRT healthy/running checks.

Cheers,

>
> Gustavo.
>
>
> Cheers,
>
> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
> [2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> 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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12
Loading...