ctubbsii commented on issue #4595: URL: https://github.com/apache/accumulo/issues/4595#issuecomment-2252260955
You are correct that the Hadoop CredentialProvider mechanism is not used for the SSL properties. However, I am not sure about implementing that feature. I'm not very familiar with all the CredentialProvider mechanisms, but the one that I've interacted with (jceks file used for tests that I recently updated in #4580) isn't that secure. It is just a Java keystore that doesn't have a passphrase.. which is not much better than a plaintext file. Perhaps CredentialProvider has implementations that are more secure, or there's a way to securely pass a passphrase for the jceks file itself, but I'm not familiar with those methods at the moment. By contract, the whole point of these SSL properties is to allow you to store the relevant SSL/TLS certificates into a keystore. In other words, it seems to serve a similar purpose. It sounds like you're wanting to store the passphrase for the keystore holding the certs in a separate keystore holding the passphrase. But then, is that second keystore going to be encrypted? If so, where are you going to store the passphrase for that second keystore? Wouldn't you just have to pass that to CredentialProvider (assuming it even supports that, which as I said above, I'm not sure about)? I'm sure I have room to learn some more about how the CredentialProvider works, but without more information, it currently seems to me that it's [turtles all the way down](https://en.wikipedia.org/wiki/Turtles_all_the_way_down) and I don't see much point in adding code to support adding another layer. If there is a way to securely unlock an encrypted keystore without a keystore passphrase needing to be stored insecurely, perhaps the JSSE system properties (which these client properties are intended to mirror) support something more naturally, without using Hadoop's CredentialProvider in an insecure way? I'm not sure the answer, but it seems more worth pursuing that than it does adding an extra insecure layer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
