Glob CN or DNS alternative name?

[waybeforenow]

Hi, thanks for developing this neat tool!

I'm considering deploying ghostunnel in an environment where I have many nodes (on the order of thousands) that need to connect to an upstream time-series database for hardware and application monitoring. The database doesn't support client authentication, so I'd like to put it behind ghostunnel to transparently put mutual TLS auth in place.

The nodes each have a valid SSL/TLS certificate for one unique subdomain of the same second-level domain. I'd like to use these certificates for client authentication as well. They manage their certificates with Let's Encrypt via certbot. As far as I can tell, this configuration doesn't support URI-type Subject Alternative Names in certs.

I think that I have two options?

• Every time a new node gets deployed or decommissioned, modify the --allow-dns argument to the ghostunnel server and restart it
  • This is doable, but potentially toilsome. It may run into issues with CLI argument length limits, as well.
• Manage my own PKI, so I can issue certificates with URI SANs
  • I'd rather not do this.

My question: Is there another way to accomplish this? Or is it possible to glob CNs or DNS alternative names in ghostunnel, and if not, is this a feature you would consider adding?

[csstaub]

That's not currently possible, though we could add this for DNS names since globbing/wildcards is a known concept there. Also, DNS names can't contain * today so it'd be non-ambiguous. Less excited about supporting it for CNs since they can theoretically be any arbitrary string.

Ideally the globbing would work the same was as a wildcard cert, i.e. it would only be possible to glob on the left-most component of a domain and globbing would have to be delimited by a ..

So, this would be valid: *.example.com *.sub.example.com

This would not be valid: some-prefix-*.example.com some-*-infix.example.com test.example.* test.*.com

Would that work for you?

[csstaub]

Also, as far as CLI argument length limits go, you can also put flags into a config file and load it with ghostunnel @file, it's a feature in the argument parsing lib we use. I should probably document that at some point (and maybe add an integration test for it too).

[waybeforenow]

The DNS globbing you've described is sufficient for my use-case.

To avoid a scenario where someone wants to match only a wildcard cert, but ends up inadvertently matching subdomains as well, maybe you could use a different character for globbing? One that wouldn't be legal in any DNS name, to avoid collisions.

For example, maybe:

+.example.com matches bar.example.com but not foo.bar.example.com.

++.example.com matches bar.example.com and also foo.bar.baz.example.com.

However, I can understand if you'd feel this is too much complexity, or would be confusing to users. I would just caution against using * as a glob-matcher since wildcard domains can appear in DNS SANs.

[csstaub]

Hm, yeah, that's entirely possible. We're already using * as a glob for URI SANs though so having another character might be unintuitive. Maybe a prefix or separate flag, like --allow-dns-glob?

[waybeforenow]

--allow-dns-glob works, as long as you're explicit about whether it does or does not support wildcard domains.

[csstaub]

This is possible on the main branch now with OPA policies: https://github.com/ghostunnel/ghostunnel/blob/master/docs/ACCESS-FLAGS.md