2 Commits

Include renames

Author	SHA1	Message	Date
lockbitchat	2a7142c722	feat(webrtc): recover a dropped connection without a signalling server; release v5.6.0 ... A chat no longer dies when the network moves under it. A NAT rebind, a lift, a Wi-Fi radio parking itself, a phone that dozed: the session repairs its own network path in place, and the messages typed meanwhile go out when it returns. Recovery is an ICE restart, which renegotiates only the transport path — the DTLS handshake, the session keys and the SCTP association carrying the data channel all sit above ICE and survive it. The renegotiation SDP therefore travels over the existing end-to-end encrypted, SAS-verified channel: no signalling service enters the design, and an attacker who cannot already decrypt the session cannot inject a reconnection. A restart is refused outright unless the DTLS fingerprint in the incoming SDP matches the live session's, so recovery can never re-point a conversation at a different peer. When the path is gone for good the session is ended and its data wiped rather than left half-alive: with no server there is nothing to re-signal through, and a conversation whose transport is gone should not leave its plaintext in an open tab. The two cases where that is already certain are recognised in seconds instead of being retried for two minutes — a channel that has delivered nothing at all since the drop cannot carry a renegotiation, and an ICE agent left bound to a network that no longer exists reports zero candidate pairs on every restart. Judging liveness was the hard part. Silence is not evidence of death: browsers freeze backgrounded tabs outright, and a frozen peer answers nothing while being perfectly healthy. What survives that freeze is ICE consent, which the browser runs in its network stack rather than on the page's thread — so a connected ICE state means a silent peer is asleep, and only a degraded one turns an unanswered probe into a teardown. The grace window before a restart is sized to the browser's own timings: 'disconnected' arrives after ~5s of missed consent responses and is held ~25s before 'failed', and that window exists for self-healing, so restarting at the start of it broke connections that were about to recover. Several long-standing bugs surfaced along the way and are fixed here: - handleHeartbeat() was dispatched to but never defined, so every inbound heartbeat threw a TypeError and peer liveness was never observed at all. - Heartbeats were folded into the 5-minute maintenance cycle instead of running on their own timer, far too coarse to notice a dead path. - ondatachannel can hand over a channel that is already open, so the answering side's 'open' event had been dispatched before the handler was assigned and never fired, leaving that side with no heartbeat, no watchdog and no file-transfer init. The peer whose network was fine kept showing "connected" indefinitely because nothing was running to notice. - Answering a heartbeat required the peer to have finished verifying, but the two sides confirm a SAS code at different moments; for that whole window one of them could not reply and was declared dead on a healthy connection. - Sending on a channel that was not ready returned in silence: the text stayed in the box, nothing was transmitted, and nothing said why. - The send path gated on navigator.onLine and the offline/online events, which report whether an interface exists rather than whether anything is reachable. A tab the OS froze misses the 'online' edge, and this side then queued every message forever: one tick on everything it sent, while incoming messages kept arriving. Sending is now decided by the data channel, and queues drain by polling rather than on an edge, so a missed event cannot strand them. - A false offline modal appeared on a working session, because the offline event was taken at face value. tests/session-recovery.test.mjs covers the state machine, the backoff and its serialisation, the offline hold, the sleeping-peer discriminator and the identity check.	2026-08-02 21:16:13 -04:00
lockbitchat	6152a77b51	security: fix SAS verification bypass and unauthenticated frame injection; release v5.5.2 ... A security review of the transport and verification layers. Every item is a fix to how untrusted peer input is handled; no features changed. - SAS verification could be bypassed. `verification_both_confirmed` is an unauthenticated frame on a channel that is not yet trusted, but it was taken as proof that both sides had compared their codes — so a peer who completed the signalling exchange could send it right after the data channel opened and drive the other side to a "verified" session while the user never looked at the code. It is now only an acknowledgement: refused unless this side already confirmed locally, and _setVerifiedStatus() independently rejects any SAS-based transition without a local confirmation. Holding ECDH-derived keys was never proof of identity — a MITM has those too. - Unauthenticated frames could be injected into the chat. A bare {type:"message"} frame, a raw non-JSON frame and a binary frame were each decoded and rendered, bypassing decryption, the HMAC check and the verification gate; the injected text was indistinguishable from a genuine message. Chat content now reaches the UI only through the authenticated enhanced_message path. - A peer could supply the verification code. `sas_code` announcements were adopted verbatim when no local SAS had been derived yet. They may now only corroborate the locally derived code. - Anti-replay never ran. The sequence-number and AAD validators were defined on SecureKeyStorage instead of the connection manager, so every call site failed with a TypeError and the sliding replay window was dead code. Moved onto the manager, wired into the live chat path, and a missing or non-numeric sequence number now fails closed instead of sailing through the range checks. - File transfers are gated on verification in both directions. Control frames are written straight to the data channel by the transfer system; sending was already gated, receiving now is too. - Tighter CSP: connect-src and img-src no longer allow arbitrary https: hosts (nothing in the app talks to a third party), plus base-uri 'none'. - The SAS is no longer written to logs, and is compared in constant time on every path. Fixed SecureMasterKeyManager.isUnlocked() testing a field renamed long ago, so it never actually gated anything. - Fixed the header showing "Secure undefined%": getRealSecurityLevel() became reachable for the first time by the move above and returned only per-feature booleans, while the header renders `level` and `score` directly. It now runs the same verified scoring as every other consumer. Adds regression tests for the verification gate, inbound frame authentication and the security-level shape.	2026-07-27 00:10:29 -04:00