Add TrustedKeys to TLS Config
#10803
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10803 +/- ##
==========================================
- Coverage 91.71% 91.65% -0.07%
==========================================
Files 406 406
Lines 18947 19019 +72
==========================================
+ Hits 17378 17432 +54
- Misses 1209 1227 +18
Partials 360 360 ☔ View full report in Codecov by Sentry. |
sinkingpoint
force-pushed
the
sinkingpoint/trusted-keys
branch
4 times, most recently
from
772fd3a
to
231cc73
Compare
When using client certificates, it's sometimes useful to use publically signed certificates to avoid having to run your own CA infrastructure. This leaves you open though, because if you trust a public cert then _any_ public cert will work. This alleviates this by allowing specifying a list of "Trusted Keys". This is an array of SHA256 fingerprints of certs that are trusted, allowing us to reject any certs that are not the exact one we expect. Signed-off-by: sinkingpoint <[email protected]>
sinkingpoint
force-pushed
the
sinkingpoint/trusted-keys
branch
from
231cc73
to
259770f
Compare
|
@mx-psi Could I get your eyes on this when you get a sec? |
| @@ -72,6 +72,14 @@ Additionally certificates may be reloaded by setting the below configuration. | |||
| Accepts a [duration string](https://pkg.go.dev/time#ParseDuration), | |||
| valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". | |||
|
|
|||
| - `trusted_keys` (optional) : TrustedKeys allows specifying a list of SHA256 hashes to trust when verifying client certificates. This allows only trusting a specific set of keys, rather than all the keys signed by a given CA. Note: The client certificate still has to pass standard TLS verification, so you must still set the required CA values. | |||
There was a problem hiding this comment.
We don't necessarily need to implement this now (if it doesn't lead to a breaking change), but if we want to change the hashing algorithm used here, how do you see that transition happening? I guess we could have something like this:
tls:
trusted_keys:
hashing_function: sha256
hashes:
- "29:9D:39:8E:26:E7:72:88:D7:5D:2D:34:FE:8C:41:FA:9F:F1:C3:D7"or instead each element of tls::trusted_keys could be something like this:
tls:
trusted_keys:
- sha256: "29:9D:39:8E:26:E7:72:88:D7:5D:2D:34:FE:8C:41:FA:9F:F1:C3:D7"What do you think is the best approach? I am leaning towards the latter option (it's a bit more flexible)
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
|
Hello @mx-psi, we'd like to see this implemented, is there anything we can do to get this change merged? I can take over and implement the approach 2 you proposed if needed. |
|
Hey @namco1992 , feel free to open a PR. I still would want to explore if other applications do this and what's their UX like to make sure we are aligned with them if it makes sense |
Description
When using client certificates, it's sometimes useful to use publicly signed certificates to avoid
having to run your own CA infrastructure. This leaves you open though, because if you trust a public cert then any public cert will work.
This alleviates this by allowing specifying a list of "Trusted Keys". This is an array of SHA256
fingerprints of certs that are trusted, allowing
us to reject any certs that are not the exact one we expect.
Link to tracking issue
Fixes #10523
Testing
Added two tests where we create a server that trusts a specific key, and then asserts that that key passes verification whereas the other cert doesn't.
Documentation
Added new option to README, along with an example