0
0
mirror of https://github.com/XTLS/REALITY.git synced 2025-08-22 06:28:35 +00:00
Commit Graph

169 Commits

Author SHA1 Message Date
yuhan6665
de3bb4d08f Update readme 2025-07-27 19:10:20 -04:00
RPRX
5b52a03d4f
Fix sending Server Hello in an unexpected way for fixing edge cases
https://t.me/projectXray/4377580
2025-07-25 14:20:56 +00:00
RPRX
c6320729d9
README.md: Add REALITY NFT's image & link
https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
2025-07-23 12:10:14 +00:00
RPRX
00881f6740
README.md: Add "mldsa65Seed" and "mldsa65Verify" to example
https://github.com/XTLS/Xray-core/pull/4915
2025-07-23 02:23:38 +00:00
RPRX
4eaf7927f3
REALITY protocol: Add optional Post-Quantum ML-DSA-65 signature to cert's ExtraExtensions 2025-07-22 04:56:54 +00:00
RPRX
ebbbf46ec3
REALITY protocol: Use X25519MLKEM768's data if X25519 doesn't exist in Client Hello 2025-07-22 04:56:14 +00:00
RPRX
05a351a645
Three types of ALPN for post-handshake records detection & imitation
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-3072047745
2025-07-15 05:57:25 +00:00
RPRX
e62c4aed0d
Refactor post-handshake records detection & imitation again
https://github.com/XTLS/Xray-core/issues/4843#issuecomment-3013196642
2025-06-27 14:14:58 +00:00
wyx2685
dc28cce21c
Fix missing config.Show check before printing len(postHandshakeRecord) (#18) 2025-06-27 11:39:29 +00:00
RPRX
50752aec6b
Some small changes
https://github.com/XTLS/REALITY/pull/10
https://github.com/XTLS/REALITY/pull/11

---------

Co-authored-by: Jes Cok <xigua67damn@gmail.com>
Co-authored-by: caikun233 <69567735+caikun233@users.noreply.github.com>
2025-06-08 13:21:14 +00:00
Meow
4fd34dd4eb
feat: Add rate limiting to fallback handling via token bucket (#12)
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
2025-06-08 13:11:45 +00:00
RPRX
90e738a94c
Refine GlobalPostHandshakeRecordsLens' locker
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-2952303176
2025-06-07 10:56:25 +00:00
RPRX
88910695ec
Use Chrome's fingerprint to trigger target's post-handshake records
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-2952140234
2025-06-07 08:21:47 +00:00
RPRX
21af070492
Refactor post-handshake records detection & imitation
https://github.com/XTLS/Xray-core/issues/4778#issuecomment-2948185205
2025-06-06 06:46:02 +00:00
风扇滑翔翼
967adadcc7
Add post-handshake records detection (#17) 2025-06-06 01:44:11 +00:00
yuhan6665
e679ef7bb1 crypto/tls: signature_algorithms in CertificateRequest can't be empty
Change-Id: I6a6a4656ab97e1f247df35b2589cd73461b4ac76
Reviewed-on: https://go-review.googlesource.com/c/go/+/675917
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-26 20:01:05 -04:00
yuhan6665
c169f1395b crypto/tls: reject duplicate TLS 1.3 EncryptedExtensions
When a TLS 1.3 client processes the server's encryptedExtensionsMsg it
should reject instances that contain duplicate extension types.

RFC 8446 §4.2 says:
  There MUST NOT be more than one extension of the same type in a given
  extension block.

This update matches enforcement done in the client hello unmarshalling,
but applied to the TLS 1.3 encrypted extensions message unmarshalling.

Making this change also allows enabling the
DuplicateExtensionClient-TLS-TLS13 BoGo test.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/673757
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-26 20:01:05 -04:00
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
yuhan6665
5a0e0628ae crypto/tls: disable SHA-1 signature algorithms in TLS 1.2
This implements RFC 9155 by removing support for SHA-1 algorithms:

  - we don't advertise them in ClientHello and CertificateRequest
    (where supportedSignatureAlgorithms is used directly)

  - we don't select them in our ServerKeyExchange and CertificateVerify
    (where supportedSignatureAlgorithms filters signatureSchemesForCertificate)

  - we reject them in the peer's ServerKeyExchange and CertificateVerify
    (where we check against the algorithms we advertised in ClientHello
    and CertificateRequest)

Fixes #72883

Change-Id: I6a6a4656e2aafd2c38cdd32090d3d8a9a8047818
Reviewed-on: https://go-review.googlesource.com/c/go/+/658216
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-26 20:01:05 -04:00
yuhan6665
5938152cb0 crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3
If a ClientHello only supports TLS 1.3, or if a CertificateRequest is
sent after selecting TLS 1.3, we should not advertise TLS 1.2-only
signature_algorithms like PKCS#1 v1.5 or SHA-1.

However, since crypto/x509 still supports PKCS#1 v1.5, and a direct
CertPool match might not care about the signature in the certificate at
all, start sending a separate signature_algorithms_cert extension to
indicate support for PKCS#1 v1.5 and SHA-1 in certificates.

We were already correctly rejecting these algorithms if the peer
selected them in a TLS 1.3 connection.

Updates #72883

Change-Id: I6a6a4656ab60e1b7fb20fdedc32604dc156953ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/658215
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-26 20:01:05 -04:00
yuhan6665
a74700bdda crypto/tls: match compression method alert across versions
When a pre-TLS 1.3 server processes a client hello message that
indicates compression methods that don't include the null compression
method, send an illegal parameter alert.

Previously we did this for TLS 1.3 server handshakes only, and the
legacy TLS versions used alertHandshakeFailure for this circumstance. By
switching this to alertIllegalParameter we use a consistent alert across
all TLS versions, and can also enable the NoNullCompression-TLS12 BoGo
test we were skipping.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/673736
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2025-05-26 20:01:05 -04:00
yuhan6665
84df3a70da crypto/tls: delete dead code curveIDForCurve
This unexported function has no call-sites.

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/673755
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
2025-05-26 20:01:05 -04:00
yuhan6665
792d6c1166 crypto/tls: verify server chooses advertised curve
When a crypto/tls client using TLS < 1.3 sends supported elliptic_curves
in a client hello message the server must limit itself to choosing one
of the supported options from our message. If we process a server key
exchange message that chooses an unadvertised curve, abort the
handshake w/ an error.

Previously we would not note that the server chose a curve we didn't
include in the client hello message, and would proceed with the
handshake as long as the chosen curve was one that we've implemented.
However, RFC 8422 5.1 makes it clear this is a server acting
out-of-spec, as it says:

  If a server does not understand the Supported Elliptic Curves
  Extension, does not understand the Supported Point Formats Extension,
  or is unable to complete the ECC handshake while restricting itself
  to the enumerated curves and point formats, it MUST NOT negotiate the
  use of an ECC cipher suite.

Changing our behaviour to enforce this also allows enabling the
UnsupportedCurve BoGo test.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/673735
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-26 20:01:05 -04:00
yuhan6665
6648c3b5a7 crypto/tls: have servers prefer TLS 1.3 when supported
Previously the common Config.mutualVersion() code prioritized the
selected version based on the provided peerVersions being sent in peer
preference order.

Instead we would prefer to see TLS 1.3 used whenever it is
supported, even if the peer would prefer an older protocol version.
This commit updates mutualVersions() to implement this policy change.

Our new behaviour matches the behaviour of other TLS stacks, notably
BoringSSL, and so also allows enabling the IgnoreClientVersionOrder BoGo
test that we otherwise must skip.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/673236
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-26 20:01:05 -04:00
yuhan6665
8ef3e8ca6d crypto/tls: add GetEncryptedClientHelloKeys
This allows servers to rotate their ECH keys without needing to restart
the server.

Fixes #71920

Change-Id: I55591ab3303d5fde639038541c50edcf1fafc9aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/670655
TryBot-Bypass: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-26 20:01:05 -04:00
yuhan6665
176e7bdccb crypto/tls: replace custom intern cache with weak cache
Uses the new weak package to replace the existing custom intern cache
with a map of weak.Pointers instead. This simplifies the cache, and
means we don't need to store a slice of handles on the Conn anymore.

Change-Id: I5c2bf6ef35fac4255e140e184f4e48574b34174c
Reviewed-on: https://go-review.googlesource.com/c/go/+/644176
TryBot-Bypass: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
2025-05-26 20:01:05 -04:00
yuhan6665
28a42c2be7 Use public module for AES GCM
I thought Golang will enforce fips140, but it seems not the intended.
Besides, hpke also is using cipher.NewGCM so we should be ok with it at the moment
2025-05-26 20:01:05 -04:00
yuhan6665
a66a2f0ccf Expose EchConfig for xray core client config 2025-05-26 20:01:05 -04:00
Pk-web6936
1292b8ce43 Update dependencies 2025-05-25 16:09:29 -04:00
RPRX
4df2ec9a5b
REALITY protocol: Remove ChaCha20-Poly1305 support for REALITY's session id auth
https://github.com/XTLS/Xray-core/pull/3813#issuecomment-2885686468

https://github.com/XTLS/REALITY/pull/4#issuecomment-2885815235

Reverts e07c3b04b9
2025-05-16 07:07:13 +00:00
yuhan6665
514f8647ea More fixes for AES block 2025-05-13 08:52:09 -04:00
RPRX
2ea7e5619e
Fix https://github.com/XTLS/Xray-core/pull/3813#issuecomment-2874943277 2025-05-13 04:53:25 +00:00
RPRX
f07c896f71
REALITY practice: Support X25519MLKEM768 for TLS' communication
Thank https://github.com/XTLS/REALITY/pull/14 @yuhan6665
2025-05-12 20:18:51 +00:00
RPRX
ce2747b9b0
Merge pull request #14 from XTLS/go124
Update to latest Go
2025-05-12 17:55:31 +00:00
yuhan6665
20f151b00a crypto/tls: handle client hello version too high
If the client hello legacy version is >= TLS 1.3, and no
supported_versions extension is sent, negotiate TLS 1.2 or lower when
supported.

On the topic of supported version negotiation RFC 8446 4.2.1 indicates
TLS 1.3 implementations MUST send a supported_versions extension with
a list of their supported protocol versions. The crypto/tls package
enforces this when the client hello legacy version indicates TLS 1.3
(0x0304), aborting the handshake with an alertMissingExtension alert if
no supported_versions were received.

However, section 4.2.1 indicates different behaviour should be used when
the extension is not present and TLS 1.2 or prior are supported:

  If this extension is not present, servers which are compliant with
  this specification and which also support TLS 1.2 MUST negotiate
  TLS 1.2 or prior as specified in [RFC5246], even if
  ClientHello.legacy_version is 0x0304 or later.

This commit updates the client hello processing logic to allow this
behaviour. If no supported_versions extension was received we ignore the
legacy version being >= TLS 1.3 and instead negotiate a lower supported
version if the server configuration allows.

This fix in turn allows enabling the BoGo ClientHelloVersionTooHigh,
MinorVersionTolerance, and MajorVersionTolerance tests.

Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/671235
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-10 23:50:17 -04:00
yuhan6665
db7cbf40cc crypto/tls: fix TLS <1.3 client cert required alert
Previously for protocol versions older than TLS 1.3 our server handshake
implementation sent an alertBadCertificate alert in the case where the
server TLS config indicates a client cert is required and none was
received.

This commit updates the relevant logic to instead send
alertHandshakeFailure in these circumstances.

For TLS 1.2, RFC 5246 §7.4.6 unambiguously describes this as the correct
alert:
  If the client does not send any certificates, the
  server MAY at its discretion either continue the handshake without
  client authentication, or respond with a fatal handshake_failure
  alert.

The TLS 1.1 and 1.0 specs also describe using this alert (RFC 4346 §7.4.6
and RFC 2246 §7.4.6) both say:
  If client authentication is required by the server for the handshake
  to continue, it may respond with a fatal handshake failure alert.

Making this correction also allows enabling the
RequireAnyClientCertificate-TLS1* bogo tests.

Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/671195
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-10 23:49:02 -04:00
yuhan6665
b5e214e5fe crypto/tls: err for unsupported point format configs
If a client or server explicitly offers point formats, and the point
formats don't include the uncompressed format, then error. This matches
BoringSSL and Rustls behaviour and allows enabling the
PointFormat-Client-MissingUncompressed bogo test.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/669157
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-10 23:46:21 -04:00
yuhan6665
eef41364b3 crypto/tls: update TLS 1.3 client compression validation
Unlike in earlier TLS versions, in TLS 1.3 when processing a server
hello the legacy_compression_method MUST have the value 0. It is no
longer a parameter that offers a choice of compression method.

With this in mind, it seems more appropriate to return a decode error
when we encounter a non-zero compression method in a server hello
message. We haven't found a parameter value we reject, we've found
a message that doesn't decode according to its specification.

Making this change also aligns with BoringSSL and allows enabling the
TLS13-HRR-InvalidCompressionMethod bogo test.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/669156
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-05-10 23:41:59 -04:00
yuhan6665
ce70d0748e crypto/tls: use illegal param alert for bad compression
Previously if the clientHandshakeState for the TLS 1.2 client code
encountered a server helo message that contained a compression method
other than compressionNone, we would emit an unexpected message alert.

Instead, it seems more appropriate to return an illegal parameter alert.
The server hello message _was_ expected, it just contained a bad
parameter option.

Making this change also allows enabling the InvalidCompressionMethod
bogo test.

Updates #72006

Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/669155
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-05-10 23:39:22 -04:00
yuhan6665
69ea598173 crypto/tls: use runtime.AddCleanup instead of runtime.SetFinalizer
Replace the usage of runtime.SetFinalizer with runtime.AddCleanup in
the certificate cache.

Updates #70907

Change-Id: Ieab6ff88dbc4083f11c1b475f11bd61521dbc638
Reviewed-on: https://go-review.googlesource.com/c/go/+/664275
Auto-Submit: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-05-10 23:37:34 -04:00
yuhan6665
5b2edd4705 crypto/tls: add offered cipher suites to the handshake error
This change makes debugging easier if the server handshake fails because
the client only offers unsupported algorithms.

Change-Id: I7daac173a16af2e073aec3d9b59709560f540c6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/631555
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Nicola Murino <nicola.murino@gmail.com>
2025-05-10 23:33:34 -04:00
yuhan6665
5052e9a93c crypto/tls: use crypto/hkdf
For consistency, prefer crypto/hkdf over crypto/internal/fips140/hkdf.
Both should have the same behavior given the constrained use of HKDF
in TLS.

Change-Id: Ia982b9f7a6ea66537d748eb5ecae1ac1eade68a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/658217
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-10 23:30:06 -04:00
yuhan6665
989cf77b4e crypto/tls: add missing RUnlock in ticketKeys
If GetConfigForClient returns a tls.Config that has
SessionTicketsDisabled set, the TLS server handshake currently leaves
the Config's internal RWMutex read locked after calculating the
ticketKeys to use for the handshake.

Change-Id: I07e450a0d2edda9e80f51fc2c20af633aa271684
GitHub-Last-Rev: 693d7ac
GitHub-Pull-Request: #68607
Reviewed-on: https://go-review.googlesource.com/c/go/+/601335
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-10 23:12:35 -04:00
yuhan6665
fd9059aef1 crypto/tls: fix ECH compatibility
Previously, the code only checked supportedVersions[0] for TLS 1.3
However, Chromium-based
browsers may list TLS 1.3 at different positions, causing ECH failures.
This fix:
    Iterates through supportedVersions to accept connections as long as TLS 1.3 is present.
    Improves ECH compatibility, ensuring Chrome, Edge, and other browsers work properly.

Fixes #71642

Change-Id: I32f4219fb6654d5cc22c7f33497c6142c0acb4f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/648015
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-05-10 23:11:32 -04:00
yuhan6665
a2893060d9 crypto/tls: relax native FIPS 140-3 mode
We are going to stick to BoringSSL's policy for Go+BoringCrypto, but
when using the native FIPS 140-3 module we can allow Ed25519, ML-KEM,
and P-521.

NIST SP 800-52r2 is stricter, but it only applies to some entities, so
they can restrict the profile with Config.

Fixes #71757

Change-Id: I6a6a4656eb02e56d079f0a22f98212275a40a679
Reviewed-on: https://go-review.googlesource.com/c/go/+/650576
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
2025-05-10 23:09:16 -04:00
yuhan6665
45b1647aeb crypto/tls: clean up supported/default/allowed parameters
Cleaned up a lot of the plumbing to make it consistently follow this
logic: clone the preference order; filter by user preference; filter by
FIPS policy. There should be no behavior changes.

Updates #71757

Change-Id: I6a6a4656eb02e56d079f0a22f98212275a400000
Reviewed-on: https://go-review.googlesource.com/c/go/+/657096
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
2025-05-10 17:13:05 -04:00
yuhan6665
12fa20f9e0 crypto/tls: add ConnectionState.CurveID
This required adding a new field to SessionState for TLS 1.0–1.2, since
the key exchange is not repeated on resumption. The additional field is
unfortunately not backwards compatible because current Go versions check
that the encoding has no extra data at the end, but will cause
cross-version tickets to be ignored. Relaxed that so we can add fields
in a backwards compatible way the next time.

For the cipher suite, we check that the session's is still acceptable
per the Config. That would arguably make sense here, too: if a Config
for example requires PQ, we should reject resumptions of connections
that didn't use PQ. However, that only applies to pre-TLS 1.3
connections, since in TLS 1.3 we always do a fresh key exchange on
resumption. Since PQ is the only main differentiator between key
exchanges (aside from off-by-default non-PFS RSA, which are controlled
by the cipher suite in TLS 1.0–1.2) and it's PQ-only, we can skip that
check.

Fixes #67516

Change-Id: I6a6a465681a6292edf66c7b8df8f4aba4171a76b
Reviewed-on: https://go-review.googlesource.com/c/go/+/653315
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-10 16:53:52 -04:00
yuhan6665
cffe49f981 crypto/tls: allow P-521 in FIPS 140-3 mode and Go+BoringCrypto
Partially reverts CL 587296, restoring the Go+BoringCrypto 1.23 behavior
in terms of supported curves.

Updates #71757

Change-Id: I6a6a465651a8407056fd0fae091d10a945b37997
Reviewed-on: https://go-review.googlesource.com/c/go/+/657095
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-05-10 15:48:12 -04:00
yuhan6665
dce8d41932 crypto/tls: reject TLS 1.3 compat session ID in TLS 1.2
If we weren't resuming an existing session, and we constructed a TLS 1.3
compatible client hello, ensure the server doesn't echo back the
made up compatibility session ID if we end up handshaking for TLS 1.2.

As part of an effort to make the initial stages of a TLS 1.3 handshake
compatible with TLS 1.2 middleboxes, TLS 1.3 requires that the client
hello contain a non-empty legacy_session_id value. For anti-ossification
purposes it's recommended this ID be randomly generated. This is the
strategy the crypto/tls package takes.

When we follow this approach, but then end up negotiating TLS 1.2, the
server should not have echoed back that random ID to us. It's impossible
for the server to have had a session with a matching ID and so it is
misbehaving and it's prudent for our side to abort the handshake.

See RFC 8446 Section 4.1.2 for more detail:
  https://www.rfc-editor.org/rfc/rfc8446#section-4.1.2

Adopting this behaviour allows un-ignoring the BoGo
EchoTLS13CompatibilitySessionID testcase.

Updates #72006

Change-Id: I1e52075177a13a7aa103b45498eae38d8a4c34b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/652997
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
2025-05-10 15:44:05 -04:00
yuhan6665
b0d0891092 crypto/tls: align cert decode alert w/ BSSL
For malformed client/server certificates in a TLS handshake send
a decode_error alert, matching BoringSSL behaviour.

Previously crypto/tls used a bad_certificate alert for this purpose.
The TLS specification is imprecise enough to allow this to be considered
a spec. justified choice, but since all other places in the protocol
encourage using decode_error for structurally malformed messages we may
as well do the same here and get some extra cross-impl consistency for
free.

This also allows un-ignoring the BoGo
GarbageCertificate-[Client|Server]-[TLS12|TLS13] tests.

Updates #72006

Change-Id: Ide45ba1602816e71c3289a60e77587266c3b9036
Reviewed-on: https://go-review.googlesource.com/c/go/+/652995
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
2025-05-10 15:42:49 -04:00