[Feature Request]: `certificatePinningHosts` wildcard support

[AzureFlow]

Describe the feature / enhancement and how it would improve things

I was wondering if it's possible to add wildcard support (like OkHttp) to the certificatePinningHosts option.

Describe how your proposal will work, with code and/or pseudo-code

For example:

certificatePinningHosts: {
    "*.example.com": [
        "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=",
    ],
},

This would match all subdomains including: test.example.com, dev.example.com, etc.

[bogdanfinn]

@AzureFlow i like this suggestion.

maybe i can directly implement also multiple different pins per host. but this most likely will be a BC break

[AzureFlow]

Nice, that would be very helpful.

Does CertificatePinningHosts not already have support for supplying multiple pins per host as shown here and here?

[bogdanfinn]

@AzureFlow please check out release 1.5.0

[AzureFlow]

@AzureFlow please check out release 1.5.0

Hey, thanks for taking the time to add this feature.

I tried with the following payload (using tls-client-windows-64-1.5.0.dll):

{
  "requestUrl": "https://example.com",
  "requestMethod": "GET",
  "requestBody": "",
  "headerOrder": [
    "accept",
    "user-agent",
    "accept-encoding",
    "accept-language"
  ],
  "proxyUrl": "http://localhost:8888",
  "certificatePinningHosts": {
    "*.example.com": [
      "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx="
    ]
  },
  "tlsClientIdentifier": "okhttp4_android_9",
  "insecureSkipVerify": false,
  "followRedirects": true,
  "sessionId": "5da527e2-d7b5-4f7f-96c2-24b163011dcb",
  "timeoutSeconds": 20,
  "withoutCookieJar": true
}

I used a local Charles proxy to MITM my traffic and a pin of xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= since it should always be invalid. However, it still succeeds:

{
  "id": "7ffdb420-50e0-4d8d-bebd-edbe8754a4ab",
  "body": "*SNIP* <h1>Example Domain</h1>",
  "cookies": {},
  "headers": {
    "Accept-Ranges": [
      "bytes"
    ],
    "Age": [
      "429223"
    ],
    "Cache-Control": [
      "max-age=604800"
    ],
    "Content-Encoding": [
      "gzip"
    ],
    "Content-Length": [
      "648"
    ],
    "Content-Type": [
      "text/html; charset=UTF-8"
    ],
    "Date": [
      "Sun, 30 Jul 2023 00:29:02 GMT"
    ],
    "Etag": [
      "\"3147526947\""
    ],
    "Expires": [
      "Sun, 06 Aug 2023 00:29:02 GMT"
    ],
    "Last-Modified": [
      "Thu, 17 Oct 2019 07:18:26 GMT"
    ],
    "Server": [
      "ECS (cha/8094)"
    ],
    "Vary": [
      "Accept-Encoding"
    ],
    "X-Cache": [
      "HIT"
    ]
  },
  "sessionId": "5da527e2-d7b5-4f7f-96c2-24b163011dcb",
  "status": 200,
  "target": "https://example.com",
  "usedProtocol": "HTTP/2.0"
}

Same result with www.example.com.

No rush or anything, take your time. Thanks.

[bogdanfinn]

@AzureFlow thanks for providing the code to reproduce your issue. it seems like its somehow related to the tls client profile.

When you run your code with chrome112 for example instead of okhttp4_android_9 then the wildcard pinning works.

I did not check every client when i implemented the wildcard support. Will try to debug a bit more.

[bogdanfinn]

@AzureFlow no forget that ... i was confused. i dont know why it does not work in the shared library.. but it works in pure go.

i will debug more.

[bogdanfinn]

@AzureFlow i just updated all the shared libaries in the release 1.5.0 Seems like yesterday i compiled the libs with an old version of the tls client.

https://github.com/bogdanfinn/tls-client/releases/tag/v1.5.0

Now it should work as the change is really inside this build.

[AzureFlow]

Nice, works perfect now. Thanks.