Igor Artamonov
4768065e72
The Read path treated every TLS record's payload as application data and wrote it into readBuf — including the 1-byte payload (0x01) of ChangeCipherSpec records. mtg sends those records intermittently as a TLS-compat keep-alive; once one arrived inside the data stream it desynced the obfuscated2 CTR keystream by one byte. From that point on every MTProto message decrypted to garbage and the engine failed with "decrypt: msg_key is invalid", forcibly closed the connection, and looped. The Go switch cases for ChangeCipherSpec and Application were both empty (no fallthrough, no continue), so control reached the o.readBuf.Write(rec.Data) call below the switch for both — exactly the wrong behaviour for CCS. Reshape the loop so that: - ChangeCipherSpec records are silently dropped - Application records are written to readBuf and returned - Handshake / unsupported types still error out This matches tdlib's TlsTransport (CCS is skipped at the TLS framing layer and never reaches the MTProto decoder). 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)