Both proposals look good, if we are making a backwards incompatible change, then it makes sense to clean it up and address other issues around that space. Limiting cipherSuites and TLS versions -> Are you planning to add those settings to Gremlin Server as well, or just on the client? Is this something that you will be picking up soon? Just wanted to weigh the option of waiting for this fix versus hacking something up at my end.
Thanks! Karthik R On Thu, Aug 9, 2018 at 1:06 PM Robert Dale <[email protected]> wrote: > The other thing we can do is add these configuration keys: > keyStore > keyStorePassword > trustStore > trustStorePassword > keystoreType > > This is more natural for a java application and would allow reading Java > keystore and PKCS12 files. > > Then keyCertChainFile, keyFile, keyPassword, trustCertChainFile become > optional. We could even go as far as deprecating these. > > Also, add ability to limit enabled protocols. Because no one should be > using < TLSv1.2, right? This should be the default. Will also add cipher > suites. > sslEnabledProtocols > sslCipherSuites > > Robert Dale > > > On Thu, Aug 9, 2018 at 3:21 PM Robert Dale <[email protected]> wrote: > > > Looks about right. Yes, it would be a breaking change. And something > will > > be included in the Upgrade section. > > > > As a workaround, you can just point to your local system ca cert bundle. > > e.g. on Fedora 27, you would configure like this: > > > > conf/remote-secure.yaml: > > hosts: [my.fqdn.com] > > port: 443 > > connectionPool: { > > enableSsl: true, > > trustCertChainFile: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem} > > serializer: { className: > > org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, > config: > > { serializeResultToString: true }} > > > > > > > > Robert Dale > > > > > > On Thu, Aug 9, 2018 at 2:50 PM kARTHIK R <[email protected]> wrote: > > > >> 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 > >> > > > >> > > >> > > >
