[BUG] VLESS encryption mlkem768x25519plus — silent fail on 1.2.18.2102 (regression of #1434)

[luvkult]

v1.2.18.2102, Android arm64. URI with encryption=mlkem768x25519plus.native.0rtt.<seed> silently fails — no UI error, nothing in client logs, server never sees the connection attempt. Stripping the encryption= param from the same URI connects normally.

Looks like a regression — #1434 was closed as fixed in April with the same symptom.

Repro:

• xray-core v26.3.27 on server, VLESS+Reality+Vision, decryption mlkem768x25519plus.native.600s.<seed>
• client URI:

  vless://<uuid>@host:443?security=reality&pbk=<...>&sid=<...>&fp=chrome&sni=<dest>&flow=xtls-rprx-vision&type=tcp&encryption=mlkem768x25519plus.native.0rtt.<client_seed>#test
  

• import, connect → nothing happens
• drop the encryption= param → connects fine

Reads like the param isn't being passed through to the kernel, or the bundled kernel is missing the recent VLESS encryption bits (XTLS/Xray-core#5067).

Related: #1371, #1434.

[luvkult]

Root cause confirmed.

The embedded sing-box kernel in karing builds (branch karing_v1.13.12) has explicit filter in common/tls/reality_client.go that strips X25519MLKEM768 from both SupportedCurves and KeyShare extensions before sending ClientHello:

for _, extension := range uConn.Extensions {
    if ce, ok := extension.(*utls.SupportedCurvesExtension); ok {
        ce.Curves = common.Filter(ce.Curves, func(curveID utls.CurveID) bool {
            return curveID != utls.X25519MLKEM768
        })
    }
    if ks, ok := extension.(*utls.KeyShareExtension); ok {
        ks.KeyShares = common.Filter(ks.KeyShares, func(share utls.KeyShare) bool {
            return share.Group != utls.X25519MLKEM768
        })
    }
}

Source: https://github.com/KaringX/sing-box/blob/karing_v1.13.12/common/tls/reality_client.go

This is separate from the vless encryption: mlkem768x25519plus parameter (that one needs upstream sing-box support, tracked at SagerNet/sing-box#4179). This filter blocks PQ TLS key exchange at the handshake layer regardless of any upstream changes.

Effect: when the REALITY server is configured with X25519MLKEM768 (Xray default since the PQ rollout), the server expects this group in client KeyShare. The filter strips it, server's REALITY handshake rejects, connection silently fails.

Reproduction matches this issue exactly.

Was this filter added as a workaround for a specific regression? If so, is the workaround still needed against current upstream?

Suggestion: drop the filter and let upstream REALITY handshake handle X25519MLKEM768 negotiation natively.

[GooRingX]

Waiting for official improvements from Singbox