oauth2 filter does not verify tokenEndpoint certificate where SNI is not set

[arminabf]

When activating TLS and explicitly specifying a trusted_ca in the corresponding upstream cluster, the oauth2 filter does not check the server certificate for the correctness of the CA.

In fact, the oauth2 filter accepts any upstream, non-expired certificate even though not signed by a whitelisted trusted_ca.

Please find bellow the oaut2 Filter configuration and the cluster configuration with which the issue can be reproduced. In our tests, the /etc/ssl/certs/ca-certificates.crt trusted_ca does NOT contain the CA certificate with which the certificate of the authorizationEndpoint has been issued.

The Envoy version in use is v1.28.

        - name: "envoy.filters.http.oauth2"
          typedConfig:
            '@type': "type.googleapis.com/envoy.extensions.filters.http.oauth2.v3.OAuth2"
            config:
              tokenEndpoint:
                uri: "https://myhost.online/login/sls/oidc-token"
                cluster: "oauth-myauth"
                timeout: "3s"
              authorizationEndpoint: "https://myhost.online/login/sls/oidc-auth"
              credentials:
                clientId: "client"
                tokenSecret:
                  name: "client-secret-ref"
                  sdsConfig:
                    pathConfigSource:
                      path: "/etc/envoy/secrets/oauth/myauth/clientSecret/clientSecret.yaml"
                hmacSecret:
                  name: "hmac-secret-ref"
                  sdsConfig:
                    pathConfigSource:
                      path: "/etc/envoy/secrets/oauth/myauth/hmacSecret/hmacSecret.yaml"
              redirectUri: "%REQ(x-forwarded-proto)%://%REQ(:authority)%/oauth-myauth-callback"
              redirectPathMatcher:
                path:
                  exact: "/oauth-myauth-callback"
              signoutPath:
                path:
                  exact: "/oauth-myauth-signout"
              forwardBearerToken: true
              authScopes:
              - "openid"

- '@type': "type.googleapis.com/envoy.config.cluster.v3.Cluster"
  name: "oauth-myauth"
  type: "LOGICAL_DNS"
  connectTimeout: "5s"
  dnsLookupFamily: "V4_ONLY"
  transportSocket:
    name: "envoy.transport_sockets.tls"
    typedConfig:
      '@type': "type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext"
  common_tls_context:
    validation_context:
      trusted_ca:
        filename: /etc/ssl/certs/ca-certificates.crt
  loadAssignment:
    clusterName: "oauth-myauth"
    endpoints:
    - lbEndpoints:
      - endpoint:
          address:
            socketAddress:
              address: "myhost.online"
              portValue: 443

[phlax]

not sure it detracts from the issue presented as its the same host, but the oauth filter doesnt communicate with the authorizationEndpoint it merely redirects the user there - the tokenEndpoint otoh should validate upstream certs i think

cc @derekargueta @mattklein123

[arminabf]

not sure it detracts from the issue presented as its the same host, but the oauth filter doesnt communicate with the authorizationEndpoint it merely redirects the user there - the tokenEndpoint otoh should validate upstream certs i think

absolutely right, since authorizationEndpoint and tokenEndpoint have the same endpoint, I was a bit too careless in my wording... to be precise, it is the certificate of the tokenEndpoiont cluster that is not verified

[arminabf]

I carried out additional tests with the oauth2 filter and was able to prove that setting sni on the UpstreamTlsContext forces certificates to be verified against trusted_ca.

[phlax]

great @arminabf can we close this ticket ?

[arminabf]

great @arminabf can we close this ticket ?

the documentation doesn't say that the certificate checks only take place when SNI is set, so I think I'm not the last one to run into this. I'll try to fix this myself at a later time and come up with a pull request. From my point of view it would be good if the ticket remained open....

[phlax]

the documentation doesn't say that the certificate checks only take place when SNI is set, so I think I'm not the last one to run into this.

trying to understand what is happening here - i would have thought not setting SNI would essentially be a misconfig and that it wouldnt work - also wondering whether this is specific to oAuth or if there is some other issue related to clusters more generally

I'll try to fix this myself at a later time and come up with a pull request.

great, ill be happy to review

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.