Actually, I was thinking of adding those to just the server. The server usually dictates the security requirements. But we could add it to the client as well. I think it makes sense to keep them symmetric.
Robert Dale On Fri, Aug 10, 2018 at 2:43 PM kARTHIK R <[email protected]> wrote: > 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 > > >> > > > > >> > > > >> > > > > > >
