-
Notifications
You must be signed in to change notification settings - Fork 968
[POC] Allow clients to specify set TLS specifications per-request #6516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
6d0c923 to
bed240c
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6516 +/- ##
============================================
- Coverage 74.46% 74.20% -0.27%
- Complexity 22234 23445 +1211
============================================
Files 1963 2110 +147
Lines 82437 87666 +5229
Branches 10764 11500 +736
============================================
+ Hits 61385 65050 +3665
- Misses 15918 17126 +1208
- Partials 5134 5490 +356 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ea6d7cf to
2f43df4
Compare
2f43df4 to
d4c99af
Compare
…ertificateExtension (#6519) Motivation: This is the first of a series of PRs included by #6516. Currently, our mTLS tests are not realistic in that: - Certificate chains aren't verified - We set TLS configurations to not verify the peer, which means in reality there's no point in using mTLS. For this, I propose that a `SignedCertificate` is introduced. This is a certificate which is signed by another certificate (another `SignedCertificate` or `SelfSignedCertificate`). A JUnit `Extension` has also been introduced so users can easily test this behavior. In the process, I found that `SelfSingedCertificateNameType` has a typo, and isn't adding much value. This enum has been removed. Modifications: - Introduced `SignedCertificate`, `SignedCertificateExtension` - `SelfSignedCertificate`, `SelfSignedCertificateExtension` inherits the newly introduced constructs - Default behavior has been modified so that all generated certificates can act as a ca. - `SelfSingedCertificateNameType` has been removed Result: - Users can easily create a certificate chain for testing using `SignedCertificateExtension` <!-- Visit this URL to learn more about how to write a pull request description: https://armeria.dev/community/developer-guide#how-to-write-pull-request-description -->
) Motivation: This is part of an ongoing effort to apply per-request TLS: #6516 Currently, SNI is determined as follows: - If an `Endpoint` has a hostname, the hostname is used - Otherwise, the `:authority` at the time of setting the `Endpoint` is used https://github.com/line/armeria/blob/ee1836f9de74a8c10166860f533d08cfe4930079/core/src/main/java/com/linecorp/armeria/internal/client/DefaultClientRequestContext.java#L584-L593 When using the `:authority`, it does not consider headers that might have been set after the endpoint is determined (e.g. in the decorators) I propose that the final SNI is determined right before `PoolKey` generation. This will be useful in the upcoming PR to determine the exact `TLS` specification associated with a HTTP request. Modifications: - Moved SNI determining logic to `HttpClientDelegate` - Removed unnecessary recomputation of the `Origin` header Result: - More consistent behavior regarding SNI determination <!-- Visit this URL to learn more about how to write a pull request description: https://armeria.dev/community/developer-guide#how-to-write-pull-request-description -->
Motivation:
Explain why you're making this change and what problem you're trying to solve.
Modifications:
Result: