Reading mode:
Engineering & Legal Research Notice: This publication is prepared by the PROSTO24 Systems Engineering Desk strictly for academic protocol analysis, enterprise network security administration (hardening site-to-site and remote corporate tunnels against MITM and active probing), and NGFW/DPI telemetry auditing. It contains zero promotion or advertising of commercial VPN services and is intended solely for lawful corporate infrastructure protection.

When architecting secure enterprise gateways over TCP/TLS, security engineers face two core challenges: the CPU and statistical overhead of double encryption (TLS-inside-TLS) and vulnerability to automated Active Probing by internet-wide scanners such as Shodan and Censys. In this technical study, we examine the byte-level cryptographic mechanics of the VLESS protocol paired with XTLS-RPRX-Vision and REALITY pre-authentication.

Executive Summary (TL;DR)
  • Stateless VLESS Framing: Eliminates redundant inner symmetric ciphers in favor of native TLS 1.3 (RFC 8446) security, using a lightweight 16-byte session UUID header.
  • REALITY Zero-Trust Pre-Authentication: Embeds an AEAD-authenticated token (derived via X25519 ECDH + ShortId) directly inside the 32-byte SessionId field of the initial TLS 1.3 ClientHello packet, neutralizing active probing.
  • XTLS-RPRX-Vision Flow: Pads inner TLS handshake frames and switches to zero-copy packet splicing once inner TLS 1.3 Application Data begins, eliminating double encryption overhead.
  • SOC / NGFW Detection Telemetry: Modern enterprise NGFWs detect unauthorized Reality tunnels primarily via SNI-to-ASN / Reverse DNS mismatch correlation rather than static TLS packet signatures.

1. How REALITY Authenticates Clients Inside TLS 1.3 ClientHello

Traditional TLS gateways expose their certificates in public Certificate Transparency (CT) logs and respond predictably to active probers. REALITY embeds client authentication directly into the initial TLS 1.3 ClientHello:

  • The client generates an ephemeral X25519 keypair in the key_share extension and computes a shared ECDH secret using the gateway’s pre-shared public key.
  • Using this derived key, the client encrypts an AEAD payload containing the protocol version, timestamp, and ShortId, placing the ciphertext inside the 32-byte SessionId field of ClientHello.
  • If the gateway validates the AEAD tag, it completes the tunnel session; if verification fails (e.g., an unauthorized scanner), it transparently forwards the raw TCP stream to a designated target server without exposing any local certificate.
Real open windows of the 3X-UI v3.8.5 (Xray-core) panel: VLESS Inbounds table (port 443) and Reality Scan Candidates selector
Real management interface of Xray-core in 3X-UI v3.8.5: active VLESS inbounds table (TCP/443 with per-client traffic telemetry) alongside the built-in TLS 1.3 Reality Scan Candidates configuration window
Interactive Security CheckFull Security Audit →
Quick Password Entropy & Brute-Force Calculator
Entropy: 85 bitsCrack Time (RTX 5090): 12+ млн летStrong Protection

2. Eliminating TLS-in-TLS Overhead with XTLS-RPRX-Vision

When an encrypted HTTPS session runs inside an outer TLS tunnel, encrypting already-encrypted TLS records wastes CPU cycles and creates recognizable packet-length signatures. xtls-rprx-vision inspects record headers (0x16 0x03 vs 0x17 0x03 0x03), applies randomized padding during the inner handshake, and transitions to direct zero-copy forwarding (leveraging Linux splice(2)) once inner application data flows.

Protocol Feature Shadowsocks (AEAD-2022) VMess + WS + TLS Trojan-TLS VLESS + XTLS-Vision + REALITY
Outer Wire Format Raw high-entropy stream HTTPS WebSocket TLS 1.3 (Own Cert) TLS 1.3 (Auth in ClientHello)
Active Probing Defense Low / Moderate Exposed in CT Logs Exposed in CT Logs High (Zero certificate footprint)
Inner TLS Double Encryption Yes Yes (High CPU load) Yes Eliminated via xtls-rprx-vision
PROSTO24 Engineering Verdict: VLESS + XTLS-Vision + REALITY demonstrates how modern transport protocols leverage native TLS 1.3 cryptography and Linux zero-copy splicing to eliminate double-encryption overhead and protect enterprise endpoints against automated active probing.

Frequently Asked Questions (FAQ)

How does XTLS-RPRX-Vision avoid double encryption?

Once the inner TLS 1.3 session completes its handshake and begins transmitting encrypted Application Data records (0x17 0x03 0x03), Vision stops re-encrypting those frames at the outer layer and forwards them directly.

How do enterprise NGFWs identify unauthorized Reality connections?

Enterprise NGFWs correlate the cleartext SNI hostname in ClientHello against the destination IP’s BGP Autonomous System (ASN) and DNS history, flagging sessions where the destination VPS subnet does not match the claimed SNI domain.