Bruce, > To which SSL connections would this apply? All of them? When enabled, these validations affect any client connecting to ssl enabled component depending on `ssl-enabled-components`.
Sai On Tue, Aug 14, 2018 at 11:26 AM Bruce Schuchardt <bschucha...@pivotal.io> wrote: > Hi Sai > > To which SSL connections would this apply? All of them? > > > On 8/14/18 7:46 AM, Sai Boorlagadda wrote: > > Geode currently does not implement hostname verification and is probably > > not required per TLS spec. But it can be supported on TLS as an > additional > > check. The new proposed[1] implementation to use the default SSL context > > could cause certain man-in-the-middle attacks possible if there is no > > hostname verification. So in order to harden against such attacks, it > puts > > additional responsibilities on users to provide a custom TrustManager to > > perform additional checks on server identity. > > > > This is a proposal to add a new boolean SSL property > > `ssl-enable-endpoint-identification` which enables hostname verification > > for secure connections. For services exposed on HTTPS like pulse, > dev-rest, > > and admin-rest API, hostname validation is enabled by default and can be > > skipped using `--skip-ssl-validation'. This new parameter especially > > enables client applications to verify server's hostname using server > > certificate during SSL handshake. The same parameter can also provide a > > means to enable verification within distributed systems when a peer > (acting > > as an HTTPS client) accepting a connection from another peer (acting as > > HTTPS server). > > > > The proposed parameter can also be enabled when not using the default > > context, in any case, we should update the documentation to clarify the > > current behavior and a recommendation. > > > > [1] > > > https://lists.apache.org/thread.html/b89beb6e57eb043786791c9309f13feca225a1c5119632f3fa7b7cb9@%3Cdev.geode.apache.org%3E > > > > Sai > > > >
