Update Dart fetchOhttpKeys to support https

[spacebear21]

Bespoke implementation of tls-in-tls proxy because it's apparently not supported by any dart native library

Take this with a massive grain of salt, it's unreviewed uncut uncensored slop that may or may not work. Posting this draft for consideration against the alternative of restoring the bindings behind a feature flag in payjoin-ffi.

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Coverage Report for CI Build 24814741978

Coverage remained the same at 84.953%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	13371
Covered Lines:	11359
Line Coverage:	84.95%
Coverage Strength:	400.78 hits per line

---

💛 - Coveralls

[DanGould]

Concept ACK. This approach makes way more sense than shipping another TLS stack for one function by binding reqwest/bitreq etc. Dart bindings can own this as just one weird trick in dart, it's really not that much code surface, and we're not inventing anything new here. This is well studied protocol work that's really well understood. The one thing I'd might flag is whether/how this fingerprints requests vs any other https-in-https CONNECT client used for payjoin.

[spacebear21]

The one thing I'd might flag is whether/how this fingerprints requests vs any other https-in-https CONNECT client used for payjoin.

Hmm good point... I had Claude compare each implementation and this looks like an intractable problem. Each implementation uses different request headers which would be trivial to fix, but the bigger issue is that each TLS implementation also produces a distinct fingerprint. Both the relay and directory see this fingerprint.

  ┌───────────────────┬────────────────────────────────┬───────────────────────────────────────────────────────┬─────────────────────┬─────────────────────────────────┐
  │      Signal       │         Rust (reqwest)         │                    Python (httpx)                     │   C# (HttpClient)   │        Dart (raw socket)        │
  ├───────────────────┼────────────────────────────────┼───────────────────────────────────────────────────────┼─────────────────────┼─────────────────────────────────┤
  │ Inner TLS library │ rustls                         │ OpenSSL                                               │ SChannel/OpenSSL    │ BoringSSL                       │

Each library ships a different cipher suite list and ordering, TLS extensions, supported groups, etc.

[DanGould]

I think the trade-off between shipping a complete TLS stack with each integration for this one function and losing this fingerprint just for the bootstrap mechanism is one where I lean on dealing with the fingerprint. This is all the more reason to make sure caching is done properly in the reference implementation and perhaps bootstrapping properly is even documented in the spec.