Repository navigation
TLS re-encrypt vs passthrough incl. security pros/cons and best practices #48002
Description
- This could be a new section in the guide.
- When to use reencrypt vs passthrough.
- Security best practice: If you are using re-encrypt, block all other traffic to Keycloak. Double-check if this is already in the docs.
- There is a note "To ensure that proxy headers are used only from proxies you trust, set the proxy-trusted-addresses" but it doesn't reveal much about the why.
- There is also something in the "Enabling client certificate lookup" section pointing at this, and which is more details. Maybe that part should be moved to a common section.
- URL filtering is only possible with re-encrypt
- Several of the sections are either for re-encrypt (everything about headers), while others are only for passthrough setups (the PROXY protocol), maybe they can be grouped.
Metadata
Metadata
Assignees
Type
Fields
No fields configured for task.
Projects
- Status
Activity
[-](create issue) TLS re-encrypt vs passthrough incl. security pros/cons and best practices. Mostly around "if you are using re-encrypt, block all other traffic to Keycloak". Double-check if this is already in the docs. Could be a new section of the reverse proxy guide.[/-][+]TLS re-encrypt vs passthrough incl. security pros/cons and best practices[/+]ahus1 commentedon Apr 13, 2026
@pruivo - I've extended this, please review. Thanks!
pruivo commentedon Apr 13, 2026
@ahus1 I think it is missing the most important question: when to use reencrypt vs passthrough.
shawkins commentedon Apr 13, 2026
Relates to #35858 - in particular the user there wants to have both front-end and back-end traffic use mtls.
Also relates to #47453 - we don't do a good job currently of distinguishing proxy from non-proxy traffic.
Our biggest issue with passthrough is with certificate management. We don't expose how to configure multiple certs / sni, so everything needs to use the same server certificate. When you want more than one hostname, then you have to use reencrypt or edge termination. Or organizationally certificate management of user facing certs may be required to be done at the proxy level.
ahus1 commentedon Apr 13, 2026
Thanks, updated.
ahus1 commentedon Apr 13, 2026
@shawkins - this might be more focused on what we support and what is secure. For example, we might might restrict it to "if you using a proxy you must not use backchannels"
While this sounds very restrictive, it is IMHO the secure and therefore the right way:
As you pointed out some people might want it, but we're missing some functionality to enable that. While this adds complexity, it might also be more secure to go with a simpler setup.
Let's start simple and secure.
shawkins commentedon Apr 13, 2026
I certainly understand that the perspective here is from documenting what we currently support. I just wanted to link to existing / related issues as your work could also influence the direction things take.
That is the currenct situation, but may change due to quarkusio/quarkus#46345 (but I'll probably have to submit the fix for that one) or #47453
ahus1 commentedon Apr 13, 2026
@pruivo - given issue quarkusio/quarkus#46345, this means that the PROXY protocol can't be used when you want to be able to use any readiness endpoint.
So either
I would consider both setups broken, and wouldn't recommend any of them until quarkusio/quarkus#46345 is fixed.
So this then leaves only the reencrypt setup?
shawkins commentedon Apr 13, 2026
To clarify you mean the readiness endpoint we're running on the main interface (lb-check), not the readiness on the management interface?
Proxy: TLS reencryt and passthrough docs
Proxy: TLS reencryt and passthrough docs
Proxy: TLS reencryt and passthrough docs