geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce Schuchardt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-420) locator ssl configuration
Date Thu, 05 May 2016 21:41:13 GMT

    [ https://issues.apache.org/jira/browse/GEODE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15273143#comment-15273143
] 

Bruce Schuchardt commented on GEODE-420:
----------------------------------------

This is a response to the above proposal from Jens Deppe:

For the current proposal, how would this affect WAN configurations? Given our current SSL
mindset wouldn't there also potentially need to be a third locator port for the remote side
to communicate with for gateway discovery?

That's somewhat of a rhetorical question because I think we should be considering our SSL
configuration differently.

Instead of a 'cluster-ssl' port and 'server-ssl' port we should just have the ability for
the locator to listen on a regular port and/or a SSL port. In addition, we should do away
with almost all of the current ssl properties. For the whole cluster we really just need:

    A single keystore which contains multiple keys - one for each component as necessary
    A single truststore
    The ability for each component to use a key (either as client or server) identified by
an alias in the keystore
    A single, cluster wide set of parameters used to configure SSL (cipher and protocols)
- Do customers really have a need to configure SSL differently for different secured ways
of accessing the same system?

So, we'd end up with parameters something like the following (excluding each associated password
option):

    cluster-ssl-keystore
    cluster-ssl-truststore
    locator-ssl-alias
    server-ssl-alias
    cluster-ssl-alias
    gateway-ssl-alias
    jmx-ssl-alias
    http-ssl-alias

Essentially, each component which can listen on a secured port needs an alias and each client
socket we set up needs to be able to use an alias

This gets away from thinking about each communications subsystem (client-server, p2p, WAN,
etc.) as requiring it's own set of configuration. That leads to the current problem where
we have overlapping components (locator in this case) suggesting we need separate ports and
configuration for each subsystem. Rather, each individual listening component just needs to
be able use a specific key. To provide fully authenticated communications (mutual auth) all
that someone needs do is make sure their keys are appropriately signed and that the single
signing authority be distributed everywhere.

--Jens



> locator ssl configuration
> -------------------------
>
>                 Key: GEODE-420
>                 URL: https://issues.apache.org/jira/browse/GEODE-420
>             Project: Geode
>          Issue Type: New Feature
>          Components: locator
>            Reporter: Darrel Schneider
>            Assignee: Bruce Schuchardt
>
> We currently allow separate SSL configuration for cluster, server, gateway, jmx-manager,
and http-service.
> The "server" attributes configure the ssl connections from clients to a cache server.
> The "gateway" attributes configure the ssl connections between a gateway sender and receiver.
> The "jmx-manager" attributes configure the ssl connections between an admin client (for
example gfsh) and the jmx-manager.
> The "http-service" attributes configure the ssl connections between REST clients and
the http-service.
> The "cluster" attributes configure the ssl connections between the members of a distributed
system (peer-to-peer connections) AND to the locators.
> Using "cluster" for the connections to a locator can be a problem.
> Say you trust all your members of a distributed system since they are running on your
private network. So no need for ssl on the p2p connections.
> So you disable cluster-ssl. These means that your peers are locators are all using unsecure
connections.
> But some of these members are hosting a cache server and have clients connecting to them.
So you configure "server" ssl for the client to server connections. But for your clients to
find you servers they need to talk to the locator. Since the clients are coming from the outside
world you want them to use SSL. So you configure "server" ssl on them for when they connect
to the cache server and "cluster" SSL on them for when they connect to the locator. But your
locators are configured with "cluster" SSL disabled so that the p2p connects on the internal
network will not be SSL.
> So you are either forced to have you client to locator connections to be unsecure or
you need to secure all the cluster connections forcing the peers to also use SSL.
> I think we should introduce "locator" SSL configuration options that would allow you
to have just the locator and server using SSL and the "cluster" to have SSL disabled.
> Something else to consider would be for the locator to be able to use SSL for clients
but non-SSL for locator-to-locator and peers-to-locator connections. I think this would be
more complicated because we would need to have different ports that the locator listens on
(one for clients and one for locators and members).
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message