fix: S3 backups to Backblaze B2 us-west-000 failing the TLS handshake #36

Merged

jfro merged 1 commit from fix-s3-tls-hrr into main

2026-10-17 16:45:31 +00:00

jfro commented

2026-10-17 16:43:22 +00:00

Owner

Backups to Backblaze B2's us-west-000 S3 endpoint fail with TLS client: In state hello_retry_middlebox_assert … Unexpected Message {server_hello …}.

Cause: OTP 29 leads TLS 1.3 with the post-quantum x25519mlkem768 key share. B2's us-west-000 doesn't support it, so it answers with a HelloRetryRequest for x25519, and then sends its ServerHello without the dummy ChangeCipherSpec that OTP's middlebox-compatibility mode waits for. Other B2 regions (us-west-001/002/004, us-east-005, eu-central-003, ca-east-006) don't hit it. It isn't the IP pinning: a plain Req.get by hostname fails the same way.

Fix: S3 connections offer x25519 first (Storage.S3.tls_options/0), so no retry is needed; every other group, post-quantum ones included, is still offered after it.

Checked live against s3.us-west-000.backblazeb2.com: before, Storage.check fails with the TLS error; after, 4/4 reach B2 (which rejects the fake key with a 403). Alternatives that also worked: middlebox_comp_mode: false or TLS 1.2 only; offering x25519 first changes the least. 711 tests pass.

Backups to Backblaze B2's `us-west-000` S3 endpoint fail with `TLS client: In state hello_retry_middlebox_assert … Unexpected Message {server_hello …}`. **Cause:** OTP 29 leads TLS 1.3 with the post-quantum `x25519mlkem768` key share. B2's us-west-000 doesn't support it, so it answers with a HelloRetryRequest for `x25519`, and then sends its ServerHello without the dummy ChangeCipherSpec that OTP's middlebox-compatibility mode waits for. Other B2 regions (us-west-001/002/004, us-east-005, eu-central-003, ca-east-006) don't hit it. It isn't the IP pinning: a plain `Req.get` by hostname fails the same way. **Fix:** S3 connections offer `x25519` first (`Storage.S3.tls_options/0`), so no retry is needed; every other group, post-quantum ones included, is still offered after it. **Checked live** against `s3.us-west-000.backblazeb2.com`: before, `Storage.check` fails with the TLS error; after, 4/4 reach B2 (which rejects the fake key with a 403). Alternatives that also worked: `middlebox_comp_mode: false` or TLS 1.2 only; offering x25519 first changes the least. 711 tests pass.

jfro added 1 commit

2026-10-17 16:43:22 +00:00

fix: S3 backups to Backblaze B2 us-west-000 failing the TLS handshake

CI / test (pull_request) Successful in 1m11s

Details

751e1da341

OTP 29 leads TLS 1.3 with x25519mlkem768; B2's us-west-000 asks for x25519
instead and then leaves out the ChangeCipherSpec OTP waits for. Offer
x25519 first for S3 connections.

jfro merged commit 68c7a77af9 into main

2026-10-17 16:45:31 +00:00

jfro deleted branch fix-s3-tls-hrr

2026-10-17 16:45:31 +00:00

jfro referenced this pull request from a commit

2026-10-17 16:45:32 +00:00

Merge pull request 'fix: S3 backups to Backblaze B2 us-west-000 failing the TLS handshake' (#36) from fix-s3-tls-hrr into main