Skip to content

Increase REALITY target TLS record buffer to 17 KiB - #33

Open
fanyangCS wants to merge 2 commits into
XTLS:mainfrom
fanyangCS:fix-reality-target-record-16k
Open

Increase REALITY target TLS record buffer to 17 KiB#33
fanyangCS wants to merge 2 commits into
XTLS:mainfrom
fanyangCS:fix-reality-target-record-16k

Conversation

@fanyangCS

Copy link
Copy Markdown

Fixes XTLS/Xray-core#6356.

Summary

Increase REALITY's target TLS record buffer from 8192 bytes to 16384 bytes.

This fixes a reproducible REALITY failure when the legitimate target server returns a TLS Certificate record slightly larger than 8192 bytes. In the linked Xray-core issue, www.microsoft.com can return a Certificate record with total record length 8273 bytes when OCSP/status is included:

RecordHeader: 17 03 03 20 4c
Certificate handshake length: 0x203b
0x204c + 5 = 8273

The current REALITY code rejects it because:

size = 8192
...
if handshakeLen > size { // too long
    break f
}

The resulting user-facing/server log error is only:

REALITY: processed invalid connection ... handshake did not complete successfully

Validation

I reproduced the failure with Xray-core v26.3.27 using:

  • VLESS + TCP + REALITY + Vision
  • REALITY dest: www.microsoft.com:443
  • serverNames: www.microsoft.com
  • client fingerprint: chrome

Unpatched Xray failed locally with:

curl: (35) Recv failure: Connection reset by peer
Certificate: 8273
hs.c.isHandshakeComplete.Load(): false
handshake did not complete successfully

After this patch, the same localhost REALITY server/client setup succeeds:

https://www.google.com/generate_204 -> HTTP 204

A production deployment using the patched binary was also verified by the reporter.

Notes

TLS records can be up to around 16 KiB, so 8192 is too tight for real-world OCSP-stapled Certificate records from some large sites/CDN edges. This patch keeps the change minimal and avoids changing protocol behavior beyond allowing larger legitimate target handshake records.

@fanyangCS

Copy link
Copy Markdown
Author

Update: changed the proposed bound from 16384 to 17 * 1024.

Reason: TLS plaintext records are commonly described as 16 KiB, but TLS 1.3 encrypted records can exceed 16 KiB slightly due to overhead (RFC allows TLSCiphertext length up to 2^14 + 256). A 17 KiB bounded buffer covers valid ~16 KiB TLS records plus overhead while still remaining small and bounded.

The original reproducer (www.microsoft.com Certificate record total length 8273) is still covered; this just makes the fix less edge-case-prone.

@jcdong98

Copy link
Copy Markdown

I met the same issue. LGTM👍

Nit: Please update the PR title accordingly to align with your change.

@fanyangCS fanyangCS changed the title Increase REALITY target TLS record buffer to 16 KiB Increase REALITY target TLS record buffer to 17 KiB Jul 3, 2026
@papka1974

Copy link
Copy Markdown

Is this fix included in v26.7.11? As i remember it was promised to include it to next release...

@Szer

Szer commented Jul 18, 2026

Copy link
Copy Markdown

Really interested in merging this, otherwise clients (which I can't change) are broken for dest with big certs

helloandworlder pushed a commit to SynexIM/xray-core that referenced this pull request Aug 26, 2026
现象是 REALITY 客户端已经通过认证,然后在 VLESS 开始之前失败。根因在上游:
读取目标 TLS 记录的缓冲区小于 RFC 8446 给 TLSCiphertext 的上界,
8–17 KiB 的证书记录(链稍长就会到这个量级)读不完整。

这不是配置问题,所以没有绕过它的配置写法。XTLS/REALITY#33 修的就是这个。

⚠️ 当前 replace 指向 fanyangCS/REALITY —— 一个第三方个人 fork。
上线前必须换掉:要么上游合并后回到 xtls/reality,要么把这个补丁拿进我们自己的
synexim fork。生产依赖握手路径上的陌生人仓库,是我们控制不住的风险。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

REALITY fails with www.microsoft.com target when Certificate TLS record is 8273 bytes (>8192 hardcoded limit)

4 participants