Controller returns information even if client cert is not valid

[mvelbaum]

When I curl the controller on its advertised edge port with an invalid (or no) client cert I get some information, such as the ziti version number:

$  curl -k https://example.com:8441
{"data":{"apiVersions":{"edge":{"v1":{"apiBaseUrls":["https://example.com:8441/edge/client/v1"],"path":"/edge/client/v1"}},"edge-client":{"v1":{"apiBaseUrls":["https://example.com:8441/edge/client/v1"],"path":"/edge/client/v1"}},"edge-management":{"v1":{"apiBaseUrls":["https://example.com:8441/edge/management/v1"],"path":"/edge/management/v1"}}},"buildDate":"2023-09-01T21:03:45Z","revision":"c7a0a41867c4","runtimeVersion":"go1.20.7","version":"v0.30.3"},"meta":{}}

I don't know if this is a bug or not, but it's probably not a good idea to advertise version numbers of either the runtime or the fabric to unauthenticated users.

[mikegorman-nf]

It is not a bug, it is by design. There are a couple of endpoints that return things like version numbers for the sake of operations. When a new client is coming up, it needs the version information so that it can match it, and may not be able to attach until it does. Understanding that it is a small window of opportunity for malicious actors, it is, in fact, well defended by other means, and the overall security of the network is not significantly reduced, particularly when compared with the ability to operate.

[mvelbaum]

Thanks for the explanation! I don't have knowledge of what specifically goes on during client bootstrap - I just assumed that any of that information would only be useful on the application-level after a proper mTLS negotiation anyway.

[dovholuknf]

i'm gonna close this issue now. reoopen as needed. thanks