Add WeirdSplitter
sequenceDiagram
Client --x Router : 1st segment, TTL = 1
Client ->> Server: 2nd segment, TTL = 64
Client ->> Server: 1st segment, TTL = 64
WeirdSplitter can access some websites that cannot handle handshake messages that are fragmented to multiple TCP segments. (e.g. www.itu.int)
Suggest a name please.
Suggest a name please.
Following current dialers (DialWithSplit, DialWithSplitRetry), how about:
-
DialWithSplitAndDesync,DialWithSplitAndDesyncRetry -
DialWithDesync,DialWithDesyncRetry
Suggest a name please.
Following current dialers (
DialWithSplit,DialWithSplitRetry), how about:* `DialWithSplitAndDesync`, `DialWithSplitAndDesyncRetry` * `DialWithDesync`, `DialWithDesyncRetry`
Are they for #48? #45 doesn't implement TCB Desynchronization.
Are they for #48? #45 doesn't implement TCB Desynchronization
Well, I am confused as to what weirdsplitter does vs what desync is doing. Can these two be a single PR?
@ignoramous weirdsplitter is similar to direct_split from DPI perspective (can bypass stateless DPI but cannot bypass stateful DPI), the only advantage of weirdsplitter is that it works with websites which can't handle segmented TLS ClientHello. #48 also has this advantage, because they are implemented in similar ways. In addition, #48 overwrites the buffer before retransmitting, so TCP stack will retransmit different payload.
Why does weirdsplitter not cause desynchronization? If original 1st segment and 2nd segment are reassembled, the censor will inject RST. But our prepared payload + 2nd segment doesn't trigger RST, so the censor increases the sequence number in TCB and waits for more packets.
Why is the sequence number of the server inconsistent with the sequence number of censor ? Only the censor sees the first packet.