mirror of https://github.com/ospab/ostp.git
53 lines
3.8 KiB
Markdown
53 lines
3.8 KiB
Markdown
# OSTP Traffic Obfuscation
|
||
|
||
## Design Philosophy
|
||
Traditional tunneling protocols (such as TLS, OpenVPN, and WireGuard) exhibit distinct, recognizable fingerprints during key exchanges or carry static protocol headers. The OSTP obfuscation engine is explicitly designed to achieve **maximum entropy from the first byte**, rendering the transport completely indistinguishable from random, high-entropy noise to Deep Packet Inspection (DPI) systems.
|
||
|
||
---
|
||
|
||
## Obfuscation Key Derivation
|
||
|
||
To dynamically mask protocol data, an 8-byte obfuscation key is statically derived from the shared `access_key` configured on both the client and the server:
|
||
|
||
$$\text{Key} = \text{SHA-256}(\text{access\_key})[0..8]$$
|
||
|
||
This key is established pre-session and is never transmitted across the wire in any capacity.
|
||
|
||
---
|
||
|
||
## Dynamic In-Place Masking Algorithm
|
||
|
||
OSTP datagrams are processed "in-place" immediately prior to transmission and right after arrival. Two distinct mathematical modes are utilized based on the current handshake phase:
|
||
|
||
### 1. Handshake Phase Mode (`is_handshake = true`)
|
||
During connection initiation (Noise Handshake), the wire packet consists of a 4-byte `session_id` prefixed to the Noise payload. To mask the fixed session ID:
|
||
|
||
* **Masking**: The first 4 bytes are XORed with the first 4 bytes of the derived obfuscation key:
|
||
$$\text{raw}[i] = \text{raw}[i] \oplus \text{Key}[i \pmod 8], \quad i \in [0..3]$$
|
||
* **De-masking**: A repeated XOR with the identical key bytes recovers the original `session_id`.
|
||
|
||
### 2. Data Transmission Mode (`is_handshake = false`)
|
||
Post-handshake, the wire layout contains:
|
||
`[4-byte session_id]` + `[8-byte nonce]` + `[AEAD Ciphertext]`
|
||
|
||
To completely randomize metadata, a two-tiered dynamic XOR masking process is applied:
|
||
|
||
1. **Nonce Masking**: The 8-byte `nonce` (sequence counter) is XORed with the full 8-byte static key:
|
||
$$\text{nonce\_bytes}[i] = \text{nonce\_bytes}[i] \oplus \text{Key}[i], \quad i \in [0..7]$$
|
||
2. **Session ID Masking**: The 4-byte `session_id` is masked using high dynamic entropy — the lower 32 bits of the **original (unmasked)** `nonce` value:
|
||
$$\text{session\_id\_bytes}[i] = \text{session\_id\_bytes}[i] \oplus \text{real\_nonce\_low32\_bytes}[i], \quad i \in [0..3]$$
|
||
|
||
#### Impact of the Scheme:
|
||
Because the `nonce` increments strictly with each outgoing datagram, the session ID's masking keystream continuously changes. This breaks all packet header correlations and eliminates repeating byte patterns, rendering statistical fingerprinting futile.
|
||
|
||
---
|
||
|
||
## Statistical Padding & Shaping
|
||
|
||
In addition to header obfuscation, OSTP defends against Traffic Length Analysis (TLA).
|
||
The `AdaptivePadder` calculates dynamic dummy byte quantities to append to the packet payload before it enters the cryptographic step:
|
||
|
||
- **Dynamic Distributions**: The padding algorithms emulate length profiles commonly seen in whitelisted HTTPS or real-time video streams.
|
||
- **Encrypted Overheads**: The appended padding resides within the AEAD cipher scope. Consequently, passive observers cannot distinguish padding bytes from useful application payload, hiding the true message boundary lengths.
|
||
\ n # # X T L S - R e a l i t y I m p e r s o n a t i o n \ n \ n O S T P p r o v i d e s a c u s t o m , d e p e n d e n c y - f r e e i m p l e m e n t a t i o n o f t h e X T L S - R e a l i t y p r o t o c o l . I t f u l l y s i m u l a t e s a T L S 1 . 3 h a n d s h a k e ( w i t h r e a l i s t i c C l i e n t H e l l o p r o f i l e s ) t o b y p a s s a d v a n c e d D P I f i l t e r s . P o s t - h a n d s h a k e , i t u t i l i z e s C h a C h a 2 0 P o l y 1 3 0 5 t o s e a m l e s s l y e n c r y p t a n d t u n n e l t h e i n n e r H T T P / W S S c o n n e c t i o n s .
|
||
|
||
|