I agree to the proposal, thanks for driving it! Would like to understand what your thoughts are on the fix/change though. From my understanding, this is your plan: 1. trustCertChain file will be an optional setting, if mentioned, we would create a TrustManager that would use the mentioned CA. Else it would use the default runtime truststore. (default JRE truststore in the case of Java) 2. Add a new setting (say skipCertValidation) which will be similar to -k option of CURL where endpoint validation would be skipped. Defaulted to false. Clients would need to opt in to this.
One thing to note is that this would be a backwards incompatible change for clients if I'm not mistaken. Clients who originally used the old driver (and used to skip cert validation) would start to break now unless they explicitly update the skipCertValidation setting to true. Let me know your thoughts. I'm pretty much blocked on this as of now, and as a workaround I'm trying to download the CA cert and wiring that to my client. Karthik R On Thu, Aug 9, 2018 at 9:06 AM Robert Dale <[email protected]> wrote: > 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 > > >
