Dear Wagner,
shortly, i need a way to implement certificate pinning in my XData client and Server applications.
For a better understanding i made a copy paste from my ChatGPT discussion about this:
We need stronger protection against MITM attacks in XData client apps, especially on untrusted networks (public Wi-Fi, proxies, compromised devices). Today, XData (via Sparkle) performs standard TLS chain validation, but there isn’t an official, simple, cross-platform way to enable certificate pinning (e.g., SPKI/sha256 or certificate thumbprint).
Primary Goal
Eliminate the need to install or manage any certificates on end-user machines. The application should ship with built-in pins and validate the server at runtime—no per-device certificate deployment, no OS-store changes, and no custom CA installation.
What we’re requesting
Native certificate pinning support in TXDataClient (and ideally SparkleHttpClient) that validates the server using configurable pins before accepting the TLS connection.
Acceptance criteria
- Supported pin types
- SPKI (Subject Public Key Info) hash (sha256) — recommended.
- Certificate thumbprint (sha1/sha256) for compatibility.
- Multiple pins + backup pins
-
- Allow a list of hashes; connection succeeds if any match.
- Operating modes
Strict(fail connection on mismatch).ReportOnly(log/telemetry without blocking; useful for rollout).
- Clear, easy API
- Configurable at
TXDataClientandSparkleHttpClientlevels. - Event for pinning failures (for logging, telemetry, retry/fallback).
- Cross-platform
- Windows (SChannel/OpenSSL), macOS/iOS, Android/Linux (OpenSSL).
- Backwards compatibility
- Pinning off by default so existing projects remain unaffected.
- Documentation
- Short guide on calculating SPKI hashes, planning key rotations, and best practices.
Proposed API (Delphi — XData client)
uses XData.Client, Sparkle.Http.Engine, Sparkle.Security;
var
Client: TXDataClient;
begin
Client := TXDataClient.Create;
// Set base URL, etc.
// 1) Pinning – SPKI sha256, multiple pins (active + backup)
Client.Security.Pins.Add(
TCertificatePin.SPkiSha256('u2FsdGVkX1+...base64...')
);
Client.Security.Pins.Add(
TCertificatePin.SPkiSha256('Q29tcGFuaW9u...base64...')
);
// 2) Optional: certificate thumbprint as a fallback
Client.Security.Pins.Add(
TCertificatePin.CertSha256('AB CD EF ...')
);
// 3) Mode
Client.Security.PinningMode := TPinningMode.Strict; // or ReportOnly
// 4) Failure handler
Client.Security.OnPinningFailure :=
procedure(const Info: TPinningFailureInfo; var Allow: Boolean)
begin
// log/telemetry; Allow stays False in Strict
end;
// ...XData calls
end;
Proposed API (SparkleHttpClient — optional / recommended)
delphi
Copy code
var
Http: ISparkleHttpClient;
begin
Http := TSparkleHttpClient.Create;
Http.Security.Pins := [
TCertificatePin.SPkiSha256('...'),
TCertificatePin.CertSha256('...')
];
Http.Security.PinningMode := TPinningMode.Strict;
Http.Security.OnPinningFailure := ...
end;
Security considerations
- Prefer SPKI sha256 pinning (instead of full certificate hash) to allow certificate renewals using the same key.
- Support multiple pins (active + backup) to enable seamless rollout/rotation without downtime.
- Avoid “TOFU” (Trust On First Use) persistence by default; if offered, keep it as an advanced/opt-in feature.
- Provide clear logging on failure reasons (chain OK but pin mismatch, etc.).
Benefits
- No certificates to install on client machines—apps carry the pins and validate at runtime.
- Stronger defense against MITM beyond standard CA validation.
- Simple, correct, cross-platform implementation for XData/Sparkle users—no custom per-platform code.
Impact / Compatibility
- Off by default ⇒ zero breaking changes.
- A dedicated
Security/PinsAPI keeps current TLS validation behavior intact.
Nice-to-have
- A build-time utility or documented snippet to compute SPKI sha256 from
.cer/PEM files. - Examples for certificate/key rotation (active + backup pins) and platform-specific notes.
Best regards,
Radu Capota