Max/XTLS_REALITY
1
0
Fork 0
mirror of https://github.com/XTLS/REALITY.git synced 2026-09-28 09:58:03 +03:00
Code Issues Packages Projects Releases Wiki Activity
196 Commits 8 Branches 0 Tags
ed9b3f2b5071f38cd22c245ff85a276b1978c8af
Commit Graph
4 Commits
Author SHA1 Message Date
yuhan6665 72e1a2490a crypto/tls: implement MLKEM1024 key exchange 
Fixes #78543

Change-Id: I26a70a64665c75e5116b83f73a75093f6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/777221
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
 2026-09-10 22:11:48 -04:00
yuhan6665 5dabb073f8 Sync upstream Go 1.27 (#30) 
https://github.com/XTLS/REALITY/pull/30#issuecomment-5579024460
 2026-09-10 01:18:53 +00: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 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