Per RPRX's clarification, the original order was correct. Reverted the buffer processing order back to: input → rawInput. The issue is not an ordering problem as I misunderstood.
Awaiting clarification on the actual fix needed.
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
Per RPRX's feedback, the original code logic was correct, but the processing order matters. When switching to direct copy mode, rawInput (encrypted TLS records from the outer layer) should be processed and merged into the buffer before input (decrypted application data).
This ensures proper ordering of data when transitioning from Vision-padded mode to direct copy mode, preventing SSL errors especially with testpre connections.
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
The issue was in the timing/conditions for switching to direct copy mode. When Vision receives CommandPaddingDirect from the server, it would immediately switch to direct mode even if the current buffer contains incomplete TLS records. This caused SSL protocol errors, especially with testpre where connections may have fragmented data.
The fix: Before actually performing the switch to direct copy mode, check if the current buffer contains complete TLS records using IsCompleteRecord(). If records are incomplete, return the buffer and delay the switch until the next read cycle when complete records are available.
This ensures Vision only switches to direct mode at safe TLS record boundaries, preventing data corruption.
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
When switching to direct copy mode, add defensive nil checks before reading from input and rawInput pointers. This prevents potential issues if these pointers are not set for certain connection types.
While the TLS library handles these buffers internally, adding nil safety ensures robust operation across different connection configurations.
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
When testpre is enabled, connections are pre-established and may sit idle for up to 2 minutes. During this time, TLS 1.3 post-handshake messages (NewSessionTicket, etc.) can accumulate in the TLS connection's internal buffers (input and rawInput).
These stale messages are not part of the proxied application data and should not be forwarded by Vision. The fix clears these buffers immediately after extracting them for Vision use, before any data transfer begins.
This prevents the SSL protocol errors that occur when Vision later reads and forwards these stale TLS control messages as if they were application data.
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
The issue occurs when switching to direct copy mode - Vision was incorrectly reading from rawInput buffer which contains ENCRYPTED outer TLS/Reality records and merging them with decrypted application data. This caused SSL protocol errors, especially with testpre where pre-established connections may have TLS session tickets or other post-handshake messages in rawInput.
The fix: Only read from input buffer (decrypted application data), skip rawInput (encrypted TLS records).
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
