Skip to content
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

Pomerium will prompt user for client certificate twice when setting client_ca or tls_downstream_client_ca #4364

Open
gp666 opened this issue Jul 14, 2023 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@gp666
Copy link

gp666 commented Jul 14, 2023

What happened?

If client_ca or tls_downstream_client_ca were set in config, Pomerium prompted to select client cerificate twice when user accessed application services behind on pomerium.

For the 1st prompt to select client certificate, the Pomerium should verify the client certificate at very beginning when user request to access. However, Pomerium showed the 2nd prompt to select client certificate when redirecting to authenticate URL, and Pomerium ignored the selection (cancel prompt, or select any client certificate) that Pomerium was regardless the user choice. The interaction is poor user experiences.

In addition, Pomerium also prompt to select client cerificate twice when user accessed any other route if tls_downstream_client_ca was set at specific route in config.

What did you expect to happen?

Pomerium should prompt user for client cerificate only once, and Pomerium should not prompt the second item that is meaningless in using mTLS scenarios.

How'd it happen?

  1. Set client-ca or tls_downstream_client_ca in Pomerium config
  2. Access an application URL, pomerium will prompt user for client cerificate (have to select vaild certificate)
  3. Redirect to authenticate URL, pomerium will always prompt user for client cerificate again
  4. Successfully access the application

What's your environment like?

  • Pomerium Version: pomerium: 0.22.2-1685134689+6efd1d6b
    envoy: 1.25.5+b1095c058415dfb2261e695a0f144311a7dc346b6eb47ecbb0a01b7de2c7299f

  • OS: ubuntu 20.04

What's your config.yaml?

address: :443
grpc_address: :5443
grpc_insecure: false
authenticate_service_url: https://auth.domain.tld

certificate_authority_file: /certs/root/ca.crt
client_ca_file: /certs/client/client-ca.crt

certificates:
  - cert: /certs/wildcard.crt
    key: /certs/wildcard.key
    
cookie_secret: <>
shared_secret: <>
signing_key: <>

idp_provider: google
idp_client_id: <>
idp_client_secret: <>

routes:
  - from: https://test.domain.tld
    to: https://127.0.0.1:9201
    policy:
      - allow:
          and:
            - email:
                is: alice@domain.tld
    pass_identity_headers: true

What did you see in the logs?

N/A

Additional context

N/A

@desimone desimone added the question Further information is requested label Jul 17, 2023
@desimone desimone assigned desimone and kenjenkins and unassigned desimone Jul 17, 2023
@kenjenkins
Copy link
Contributor

This is indeed a limitation of our current mTLS implementation: Pomerium applies the same mTLS validation settings across all configured domains (including the authenticate service domain), so the browser will generally prompt for a client certificate for each separate domain.

It's not clear to me how we could avoid this behavior. We could potentially move the authenticate domain to its own separate Envoy filter chain, and avoid setting any downstream validation context there, but then we may run into other issues. For example, if a user were to visit the authenticate domain directly, and then a user-defined Pomerium route, the browser may attempt to reuse the first connection,1 which would likely not trigger a prompt for a client certificate, instead resulting in an error page.

Also note that some of our other customers explicitly want mTLS validation to apply to the authenticate service as well as any other Pomerium routes.

@gp666, is the current behavior a deal-breaker for your organization, or more of an annoyance that you can live with? Do you have any way to apply a device policy to your users' browsers to automatically select the correct client certificate? (For example, Chrome provides an AutoSelectCertificateForUrls policy that looks like it might help with this situation.)

Footnotes

  1. See https://datatracker.ietf.org/doc/html/rfc9113#name-connection-reuse for more details about when this can happen.

@gp666
Copy link
Author

gp666 commented Jul 26, 2023

Apologies for the delay. I can understand that the authenticate domain have the requirement of mTLS vaildation.
But in current version, the mTLS vaildation of the authenticate service may not work when accessed the authenticate domain directly and selected any choices(cancel prompt, or select any client certificate). (Setting client_ca in config)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants