0
0
mirror of https://github.com/XTLS/REALITY.git synced 2025-08-22 14:38:35 +00:00
THE NEXT FUTURE
Go to file
yuhan6665 3c80a18847 crypto/tls: use decode alert for handshake msg unmarshal err
Previously if instances of the handshakeMessage interface returned false
from unmarshal(), indicating an umarshalling error, the crypto/tls
package would emit an unexpected_message alert. This commit changes to
use a decode_error alert for this condition instead.

The usage-pattern of the handshakeMessage interface is that we switch on
the message type, invoke a specific concrete handshakeMessage type's
unmarshal function, and then return it to the caller on success. At this
point the caller looks at the message type and can determine if the
message was unexpected or not. If it was unexpected, the call-sites emit
the correct error for that case. Only the caller knows the current
protocol state and allowed message types, not the generic handshake
decoding logic.

With the above in mind, if we find that within the unmarshal logic for
a specific message type that the data we have in hand doesn't match the
protocol syntax we should emit a decode_error. An unexpected_message
error isn't appropriate because we don't yet know if the message is
unexpected or not, only that the message can't be decoded based on the
spec's syntax for the type the message claimed to be.

Notably one unit test, TestQUICPostHandshakeKeyUpdate, had to have its
test data adjusted because it was previously not testing the right
thing: it was double-encoding the type & length prefix data for a key
update message and expecting the QUIC logic to reject it as an
inappropriate post-handshake message. In reality it was being rejected
sooner as an invalid key update message from the double-encoding and
this was masked by the previous alert for this condition matching the
expected alert.

Finally, changing our alert allows enabling a handful of BoGo tests
related to duplicate extensions of the form
"DuplicateExtension[Server|Client]-TLS-[TLS1|TLS11|TLS12|TLS13]". One
test remains skipped (DuplicateExtensionClient-TLS-TLS13), as it
requires additional follow-up.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/673738
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
2025-05-26 20:01:05 -04:00
fips140tls crypto/tls: FIPS 140-3 mode 2025-05-04 23:10:11 -04:00
hpke Simplify with public modules 2025-05-05 11:40:53 -04:00
tls12 Simplify with public modules 2025-05-05 11:40:53 -04:00
tls13 Simplify with public modules 2025-05-05 11:40:53 -04:00
alert.go crypto/tls: add ech client support 2024-09-09 11:32:16 -04:00
auth.go crypto/tls: disable SHA-1 signature algorithms in TLS 1.2 2025-05-26 20:01:05 -04:00
cache.go crypto/tls: replace custom intern cache with weak cache 2025-05-26 20:01:05 -04:00
cipher_suites.go Use public module for AES GCM 2025-05-26 20:01:05 -04:00
common_string.go crypto/tls: implement X25519MLKEM768 2025-05-10 15:06:04 -04:00
common.go crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3 2025-05-26 20:01:05 -04:00
conn.go crypto/tls: use decode alert for handshake msg unmarshal err 2025-05-26 20:01:05 -04:00
defaults_boring.go crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3 2025-05-26 20:01:05 -04:00
defaults_fips140.go crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3 2025-05-26 20:01:05 -04:00
defaults.go crypto/tls: disable SHA-1 signature algorithms in TLS 1.2 2025-05-26 20:01:05 -04:00
ech.go crypto/tls: add GetEncryptedClientHelloKeys 2025-05-26 20:01:05 -04:00
generate_cert.go Sync upstream Go 1.20 2023-11-12 12:08:30 -05:00
go.mod crypto/tls: use crypto/hkdf 2025-05-10 23:30:06 -04:00
go.sum Update dependencies 2025-05-25 16:09:29 -04:00
handshake_client_tls13.go crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3 2025-05-26 20:01:05 -04:00
handshake_client.go crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3 2025-05-26 20:01:05 -04:00
handshake_messages.go crypto/tls: fix misspelling in comment 2025-05-10 15:14:04 -04:00
handshake_server_tls13.go crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3 2025-05-26 20:01:05 -04:00
handshake_server.go crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3 2025-05-26 20:01:05 -04:00
key_agreement.go crypto/tls: verify server chooses advertised curve 2025-05-26 20:01:05 -04:00
key_schedule.go crypto/tls: delete dead code curveIDForCurve 2025-05-26 20:01:05 -04:00
LICENSE Prepare for REALITY protocol 2023-01-29 14:32:27 +00:00
LICENSE-Go Package tls in Go 1.19.5 2023-01-29 14:31:01 +00:00
prf.go crypto/internal/fips/tls12: implement TLS 1.2 KDF 2025-05-04 22:15:27 -04:00
quic.go crypto/tls: fix typo in quicError 2024-09-09 11:32:16 -04:00
README.en.md Update dependencies and readme 2023-11-12 12:13:32 -05:00
README.md Add Star Chart 2024-04-29 18:49:17 -04:00
ticket.go crypto/tls: replace custom intern cache with weak cache 2025-05-26 20:01:05 -04:00
tls.go Use public module for AES GCM 2025-05-26 20:01:05 -04:00

REALITY

THE NEXT FUTURE

Server side implementation of REALITY protocol, a fork of package tls in latest Go. For client side, please follow https://github.com/XTLS/Xray-core/blob/main/transport/internet/reality/reality.go.

TODO List: TODO

VLESS-XTLS-uTLS-REALITY example for Xray-core

中文 | English

{
    "inbounds": [ // Server Inbound Configuration
        {
            "listen": "0.0.0.0",
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "", // Required, execute ./xray uuid to generate, or a string of 1-30 characters
                        "flow": "xtls-rprx-vision" // Optional, if any, client must enable XTLS
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "show": false, // Optional, if true, output debugging information
                    "dest": "example.com:443", // Required, the format is the same as the dest of VLESS fallbacks
                    "xver": 0, // Optional, the format is the same as xver of VLESS fallbacks
                    "serverNames": [ // Required, the acceptable serverName list, does not support * wildcards for now
                        "example.com",
                        "www.example.com"
                    ],
                    "privateKey": "", // Required, execute ./xray x25519 to generate
                    "minClientVer": "", // Optional, minimum client Xray version, format is x.y.z
                    "maxClientVer": "", // Optional, the highest version of client Xray, the format is x.y.z
                    "maxTimeDiff": 0, // Optional, the maximum time difference allowed, in milliseconds
                    "shortIds": [ // Required, the acceptable shortId list, which can be used to distinguish different clients
                        "", // If there is this item, the client shortId can be empty
                        "0123456789abcdef" // 0 to f, the length is a multiple of 2, the maximum length is 16
                    ]
                }
            }
        }
    ]
}

REALITY is intented to replace the use of TLS, it can eliminate the detectable TLS fingerprint on the server side, while still maintain the forward secrecy, etc. Guard against the certificate chain attack, thus its security exceeds conventional TLS REALITY can point to other people's websites, no need to buy domain names, configure TLS server, more convenient to deploy a proxy service. It achieves full real TLS that is undistingwishable with the specified SNI to the middleman

For general proxy purposes, the minimum standard of the target website: Websites out of China's GFW, support TLSv1.3 and H2, the domain name is not used for redirection (the main domain name may be used to redirect to www) Bonus points: target website IP reside closer to proxy IP (looks more reasonable, and lower latency), handshake messages after Server Hello are encrypted together (such as dl.google.com), OCSP Stapling Configuration bonus items: Block the proxy traffic back to China, TCP/80, UDP/443 are also forwarded to target (REALITY behaves like port forwarding to the observer, the target IP may be better if it is an uncommon choice among REALITY users)

REALITY can also be used with proxy protocols other than XTLS, but this is not recommended due to their obvious and already targeted TLS in TLS characteristics The next main goal of REALITY is "pre-built mode", that is, to collect and build the characteristics of the target website in advance, and the next main goal of XTLS is 0-RTT

{
    "outbounds": [ // Client outbound configuration
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "", // The domain name or IP of the server
                        "port": 443,
                        "users": [
                            {
                                "id": "", // consistent with the server
                                "flow": "xtls-rprx-vision", // consistent with the server
                                "encryption": "none"
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "reality",
                "realitySettings": {
                    "show": false, // Optional, if true, output debugging information
                    "fingerprint": "chrome", // Required, use uTLS library to emulate client TLS fingerprint
                    "serverName": "", // One of the server serverNames
                    "publicKey": "", // The public key corresponding to the private key of the server
                    "shortId": "", // One of the server shortIds
                    "spiderX": "" // The initial path and parameters of the crawler, recommended to be different for each client
                }
            }
        }
    ]
}

The REALITY client should receive the "Temporary Trusted Certificate" issued by "Temporary Authentication Key", but the real certificate of the target website will be received in the following three cases:

  1. The REALITY server rejects the Client Hello of the client, and the traffic is redirected to the target website
  2. The Client Hello of the client is redirected to the target website by the middleman
  3. Man-in-the-middle attack, it may be the help of the target website, or it may be a certificate chain attack

The REALITY client can perfectly distinguish temporary trusted certificates, real certificates, and invalid certificates, and decide the next action:

  1. When the temporary trusted certificate is received, the proxy connection is available and everything is business as usual
  2. When the real certificate is received, enter the crawler mode (spiderX)
  3. When an invalid certificate is received, TLS alert will be sent and the connection will be disconnected