Just to clarify, the PR shall be done, not CTR'ed. Robert Dale
On Thu, Aug 9, 2018 at 8:42 AM Robert Dale <[email protected]> wrote: > > An issue was raised on the user list [1] that the Cluster client SSL > requires the trustCertChain to be set explicitly or suffer the wrath of > WARN logging. And that got me thinking about the server too. It seems > like the only good reason to have the client trust everything by default is > simply because the server's most simple ssl default is to create > self-signed certs. Since there is no access to these certs, they can not > be imported into the client thus the client must trust anything. Well, > this is not good security all the way around. > > If we take a 'security should be secure be default' posture, then > 1) the client would never trust all certs without verification by default. > logging messages, at any level, are not sufficient. > 2) the server would never create self-signed certs. It's not that hard to > create self-signed certs anyway. > > Instead, the server should require certs to be configured explicitly > whether self-signed or commercial. The client should trust packaged ca > certs by default. The client can be configured to trust self-signed certs. > An additional config option can be used to configure the client to > disregard hostname. (This is where the hostname doesn't match the cert. It > is sometimes a necessary evil). In order to use self-signed certs, the > rather painless process to configure the client and server will have to be > followed. This is pretty standard stuff for applications. > > I've create two tickets to address these issues. > TINKERPOP-2022 - https://issues.apache.org/jira/browse/TINKERPOP-2022 > TINKERPOP-2023 - https://issues.apache.org/jira/browse/TINKERPOP-2023 > > If there are no objections in 72 hours then it shall be done starting with > tp32. > > 1. https://groups.google.com/d/msg/gremlin-users/2z7Si4wM0SU/lL3OqR0LCgAJ > > Robert Dale >
