Mutual TLS Client Authentication (mTLS)

[narg95]

After reading the RFC 8705, and based on the issue #1084, the following is my proposal for a minimalistic first version of mTLS authentication in Hydra.

Excluded features are meant to be discussed and added incrementally in further versions:

Included

• mTLS termination at Load Balancer

• Certificate info is forwarded to Hydra using HTTP Headers. A trusted relationship between Hydra and Load balancer MUST be establish. Load Balancer MUST strip those headers if presented in client requests to prevent spoofing. Headers' names should be configurable

  • Option 1: DN or SAN entries in certificate are forwarded as http header with a known prefix e.g. X-SSL-Client-* in HAPRoxy
  • Option 2: Complete certificate is forwarded (PEM or raw) in a HTTP Header, e.g. X-Forwarded-Client-Cert as in Cloud Foundry

• Verify tls_client_auth param in token end-point to trigger mTLS authentication

• Client must provide at registration one of the following client certificates params with its expected value to be checked for authentication, see RFC Section 2.1.2

  • tls_client_auth_subject_dn
  • tls_client_auth_san_dns
  • tls_client_auth_san_uri
  • tls_client_auth_san_ip
  • tls_client_auth_san_email

• Use mTLS endpoints aliases Section 5: This makes load balancer configuration easier because mTLS is enforced in those endpoints and it prevents unintended impact on the TLS behavior of existing endpoints, see RFC Implementation Considerations.

  "mtls_endpoint_aliases": {
      "token_endpoint": "https://mtls.example.com/token",
      "revocation_endpoint": "https://mtls.example.com/revo",
      "introspection_endpoint": "https://mtls.example.com/introspect"
      }
  

• Certificates Revocation should be configured in the Load Balancer

Excluded

• Self-Signed Certificates see RFC Section 2.2
• Token Binding see Section 3
• ONLY Token Binding without mTLS Authentication Section 4
• Use Proxy Protocol to forward client certificate info from Load Balancer to Hydra
• mTLS termination at Hydra server: Includes configuration of certificates, revocation list or OCSP

Please let me know if this feature is wanted in Hydra and your feedback on the described approach for the first version.

[aeneasr]

Interesting approach! Would there be an option to forward cryptographic information as well which could be validated to prevent misconfiguration from failing to strip X-SSL-Client- and other fields?

[aeneasr]

Hm, thinking about this a bit - I think a major issue would be that developers might use this flow to fake X-SSL-Client- in order to work around desired limitations on who can generate such a token. It would effectively allow people to forge tokens by abusing the X-SSL-Client-* headers.

[narg95]

Very good point, Hydra must verify the authenticity of the load-balancer's appended http headers either by:

1. Configuring a mTLS authentication between LB <-> Hydra for all requests to mtls endpoints.
2. Signing with a shared secret (e.g. HMAC) or Public/Private Key (e.g. RSA) the added http headers e.g. using RFC HTTP Headers Signatures draft

Effort

• Option 1 requires configuration of certificates between LB and Hydra for the mTLS end-points . This effort can be reuse in the future for mTLS termination at Hydra server.

• Option 2 requires an agreement on the public key e.g. a jwks_uri or shared secret plus configuring and figureing out how the Load Balancer can sign the appended HTTP headers

Option 1 looks better in my opinion. What do you think?

[aeneasr]

Sorry for my sluggish reply, still a bit in holiday mode ;)

I think the second option is difficult because most LBs I know don't implement that. The first option looks better to me. Are there any "de-facto" HTTP headers included as part of mTLS termination?

Can the LB be configured to simply pass traffic through? Meaning not terminating the TLS connection?

[narg95]

No worries ;)

Can the LB be configured to simply pass traffic through? Meaning not terminating the TLS connection?

Yes, with a tcp LB and tls termination in hydra serve a.k.a. SSL-Passthrough.
This has the advantage to validate the client certificate in the server, but the disadvantage of:

• TLS cpu overhead for handshakes
• TLS resume session not possible when scaling multiple server instances/pods
• Server needs to handle DoS and SSL attacks
• Updates in the TLS stack requires a redeploy of the server

There seems to be an intermediary option, that is sharing the same certificate and private key between LB and Server, but this is not well-known and supported by most LB, and it can not do Diffie-Hellman.

I think both SSL-Offloading and SSL-Passthrough could be supported in hydra, both seem to be common use cases, one does not exclude the other, both share most of the functionality, but we need to pick one to start :)
If I had to pick I would choose SSL-Offloading, since tls termination at LB is a very common practice.

[aeneasr]

Thank you for the explanation - that makes sense. Is there a common way of TLS Terminating Load Balancers to authenticate themselves against the upstream services?

[narg95]

It is basically m2m authentication.
The most common way is mutual TLS:

• ngnix
• hydra
• AWS Gateway
• GCP Load Balancer

which lays also the ground when implementing tls termination in oauth server(hydra).
Re-encrypting adds no much overhead, handshakes are seldom, only one client (LB), and encryption is symmetric.
Hydra must only know the CA certificate used to sign the LB certificate.

Other options are using HTTP methods:

• HTTP Signing Headers symmetrically (e.g.HMAC) or asymmetrically (RSA256): No traffic re-encrytion needed, but no out-of-the-box in LB, devs have to script it in the LB
• HTTP Base Authentication (very weak to protect a token endpoint imo.)

Given the wide support for mTLS authentication with backend/upstream, that seems the best option.

[narg95]

I started to craft something in ory/fosite to get a better feeling :)
I created a WIP branch here: https://github.com/narg95/fosite/tree/tls_auth
Take a look to my first commit 33ff8a3
and let me know your thoughts :) !

[luanmm]

Hello, people.

I'm looking for a way to authenticate using client certificates, which I think is something related to this effort, right?

But, at least for my needs, the user could use the certificate just to authenticate and it wouldn't be needed anymore (you may think of the certificate as the username/password combination). After this process, I would expect that the backend could give the user a JWT/cookie as usual (with the same identity as the user would get if using username/password, for instance).

This scenario is covered somehow today or by this last stated test/commit presented in Jan/2021?

I would like to evaluate Ory platform, because the security and "lightweightness" interests me a lot, but I need to achieve this requirement somehow. Do you see any possibilities here? Even creating an external service or something that can ensure that the client certificate is valid, or something more customized (if needed).

Thanks in advance! Great job in this libraries, btw!

Best regards!