# TLS Plugin Automatic Hostname / IP Verification **URL:** \ **Category:** Using FoundationDB\ **Created:** [April 17, 2019, 11:51pm UTC](https://forums.foundationdb.org/t/tls-plugin-automatic-hostname-ip-verification/1314 "2019-04-17T23:51:36Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![swest](https://avatars.discourse-cdn.com/v4/letter/s/7ab992/32.png) [@swest](https://forums.foundationdb.org/u/swest)\ **Post date:** [April 17, 2019, 11:51pm UTC](https://forums.foundationdb.org/t/tls-plugin-automatic-hostname-ip-verification/1314/1 "2019-04-17T23:51:36Z")
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: 1. Does FDB provide support for automatic Hostname / IP verification against a peers provided certificate during connection? 2. If not, are there any plans to add this feature in future releases? 3. 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). **References Reviewed** - [https://apple.github.io/foundationdb/tls.html](https://apple.github.io/foundationdb/tls.html) - [What are the authentication/authorization options?](https://forums.foundationdb.org/t/what-are-the-authentication-authorization-options/209) - [Upgrading FoundationDB](https://forums.foundationdb.org/t/upgrading-foundationdb/191) Thanks in advance! ---
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [April 21, 2019, 9:57am UTC](https://forums.foundationdb.org/t/tls-plugin-automatic-hostname-ip-verification/1314/2 "2019-04-21T09:57:27Z")
( 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. ) > [@swest](#): > > 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 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. > [@swest](#): > > 1. 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.) 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. ---
**Author:** ![swest](https://avatars.discourse-cdn.com/v4/letter/s/7ab992/32.png) [@swest](https://forums.foundationdb.org/u/swest)\ **Post date:** [April 22, 2019, 4:52pm UTC](https://forums.foundationdb.org/t/tls-plugin-automatic-hostname-ip-verification/1314/3 "2019-04-22T16:52:35Z")
> [@alexmiller](#): > > 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. That aligns with my findings. 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). > [@alexmiller](#): > > ( 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. ) Here are a a couple of references that appear to have been missed: - [Backup, Restore, and Replication for Disaster Recovery — FoundationDB 7.1](https://apple.github.io/foundationdb/backups.html?highlight=plugin) - [Configuration — FoundationDB 7.1](https://apple.github.io/foundationdb/configuration.html?highlight=plugin) Let me know if you need me to open them as issues for tracking / remediation. ---
**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\ **Post date:** [April 22, 2019, 8:11pm UTC](https://forums.foundationdb.org/t/tls-plugin-automatic-hostname-ip-verification/1314/4 "2019-04-22T20:11:50Z")
> [@swest](#): > > Any thoughts regarding my second question: Are there any plan to enable support for this automatic validation? There is no active work for this, nor an issue to track it, I think. You’re more than welcome to file one. > [@swest](#): > > Here are a a couple of references that appear to have been missed: Thanks! ---
**Author:** ![doublemax](https://avatars.discourse-cdn.com/v4/letter/d/8e7dd6/32.png) [@doublemax](https://forums.foundationdb.org/u/doublemax)\ **Post date:** [February 24, 2023, 12:59pm UTC](https://forums.foundationdb.org/t/tls-plugin-automatic-hostname-ip-verification/1314/5 "2023-02-24T12:59:31Z")
OpenSSL cert check by default does not include host identity. There is a `-verify_ip` parameter to address this issue. Maybe it would be enough to call the corresponding function? [https://www.openssl.org/docs/man3.1/man1/openssl-verify.html](https://www.openssl.org/docs/man3.1/man1/openssl-verify.html)