Igor Artamonov
64bf6bfe90
The ClientHello builder used a closure G(n) that was supposed to insert two random GREASE bytes (RFC 8701, 0x?A?A pattern) at known positions but expanded the buffer by zero. Every grease slot was therefore omitted, and the trailing padding extension was written as a bare ext id 0x0015 followed by raw zeros — its length field was never set. Concretely, the old output looked structurally invalid to mtg's faketls validator: the cipher list was off by two, supported_groups declared a list_length larger than its body, and what should have been the padding extension parsed as a stream of empty server_name extensions. mtg responded with a fatal TLS Alert (description 50, decode_error) and shut the connection. Fix: - generate seven distinct GREASE bytes per ClientHello, with the tdlib constraint grease[3] != grease[4] - thread an io.Reader through writeClientHello so generation is deterministic in tests and keyed off the FakeTLS rand source in prod - replace the trailing zero-pad with a proper padding extension whose length field is computed so the ClientHello is exactly 517 bytes Add a regression test (structure_test.go) that feeds the result to crypto/tls.Server: it must not return decode_error / malformed / syntax errors. The previous output failed this; the new output passes. The TestTLS golden vector is regenerated for the new layout. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mautrix-telegram
A Matrix-Telegram puppeting/relaybot bridge.
Sponsors
Documentation
All setup and usage instructions are located on docs.mau.fi. Some quick links:
- Bridge setup (or with Docker)
- Basic usage: Authentication
Features & Roadmap
ROADMAP.md contains a general overview of what is supported by the bridge.
Discussion
Matrix room: #telegram:maunium.net
Telegram chat: mautrix_telegram (bridged to Matrix room)