We’re planning on using FDB 6.0.18 (or 6.1 if it’s ready) with the TLS Plugin, but ran into some questions regarding the TLS plugin:
Does FDB provide support for automatic Hostname / IP verification against a peers provided certificate during connection?
If not, are there any plans to add this feature in future releases?
Are there any published guidelines or guidance on how to safely update the tls_verify_peers settings in a live cluster like without data loss / down time? (example: If you need to add or remove authorization for a specific subjectNameAlt, root CN, etc.)
Research Performed so Far
I’ve done some (limited) testing in my own environment using a self-signed certificate and it seems like the Hostname / IP of the peer is not verified against its provided certificate by default. I couldn’t verify if this was a unique nuance of using a self-signed certificate or if this is just the default mode of operation.
I was able to enable rudimentary Hostname / IP verification by using the tls_verify_peers setting to verify against known subjectNameAlt values (which works as expected), but this doesn’t ensure that the peer presenting the certificate owns / is associated with the certificate. Furthermore, there doesn’t seem to be any way for us to verify that each peer in the cluster is using a certificate which is assigned to them.
I’ve read the main documentation on Transport Layer Security which seems to imply that the default verification is just verifying that the provided Certificate and Key match and that they are signed by the provided Cert Authority, but neither of these appear to help with common security holes.
I’ve also read several of the common threads on TLS, Authentication and security (referenced below), so I realize that FDB only provides limited TLS support and isn’t attempting to sell itself as a secure solution. I just want to make sure we aren’t missing something obvious in the implementation that isn’t fully documented which may address some of our specific needs (without building a full Auth / Auth solution framework on top of FDB).
( TLS as a plugin was removed in 6.0, and since is just compiled in by default. If you see any documentation text still talking about TLS as a plugin, please point it out so that we can fix the text. )
You are 100% correct. FDB only verify that the certificate is valid, and has the fields matching the tls_verify_peers string. The security model assumes that the certificates issued to clients are securely locked down. So if an attacker has a copy of one of the certificates, then they are allowed to re-use from any location at will.
You’re also correct that the bespoke configuration language gives enough to be able to match against common fields in certificates that clients might have, but it’s not able to verify that client 17 has certificate number 17.
Data loss shouldn’t be a concern. Downtime is… much more possible.
This is one of the few cases where you can easily canary and gradually roll out a change across a cluster. If you take one storage server to change the verify peers string on first, you should be able to pretty quickly find out from the trace logs if you’re now dropping a large number of TLS connections, or if everything appears to still be going smoothly.
Any thoughts regarding my second question: Are there any plan to enable support for this automatic validation?
It seems like implementing a feature to verify a server’s IP address against a Subject Name Alternative IP should be possible. I can open a feature request to discuss it further but I wanted to check to make sure there wasn’t already a plan to implement this (or some technical or philosophical reason for why it shouldn’t be).
Here are a a couple of references that appear to have been missed: