After golang.org/cl/210124, I wondered if the same error had gone
unnoticed elsewhere. I quickly spotted another dozen mistakes after
reading through the output of:
git grep '\<[Aa]n [bcdfgjklmnpqrtvwyz][a-z]'
Many results are false positives for acronyms like "an mtime", since
it's pronounced "an em-time". However, the total amount of output isn't
that large given how simple the grep pattern is.
Change-Id: Iaa2ca69e42f4587a9e3137d6c5ed758887906ca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/210678
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Zach Jones <zachj1@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The cipher suites were apparently renamed late in the standardization
process, and we picked up the legacy name. We can't remove the old
constants, but add correctly named ones.
Fixes#32061
Change-Id: I65ee25c12c10934391af88b76b18565da67453fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/205068
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TLS 1.3, which requires RSA-PSS, is now enabled without a GODEBUG
opt-out, and with the introduction of
Certificate.SupportedSignatureAlgorithms (#28660) there is a
programmatic way to avoid RSA-PSS (disable TLS 1.3 with MaxVersion and
use that field to specify only PKCS#1 v1.5 SignatureSchemes).
This effectively reverts 0b3a57b537,
although following CL 205061 all of the signing-side logic is
conveniently centralized in signatureSchemesForCertificate.
Fixes#32425
Change-Id: I7c9a8893bb5d518d86eae7db82612b9b2cd257d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/205063
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
This will let applications stop crypto/tls from using a certificate key
with an algorithm that is not supported by its crypto.Signer, like
hardware backed keys that can't do RSA-PSS.
Fixes#28660
Change-Id: I294cc06bddf813fff35c5107540c4a1788e1dace
Reviewed-on: https://go-review.googlesource.com/c/go/+/205062
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Now that we have a full implementation of the logic to check certificate
compatibility, we can let applications just list multiple chains in
Certificates (for example, an RSA and an ECDSA one) and choose the most
appropriate automatically.
NameToCertificate only maps each name to one chain, so simply deprecate
it, and while at it simplify its implementation by not stripping
trailing dots from the SNI (which is specified not to have any, see RFC
6066, Section 3) and by not supporting multi-level wildcards, which are
not a thing in the WebPKI (and in crypto/x509).
The performance of SupportsCertificate without Leaf is poor, but doesn't
affect current users. For now document that, and address it properly in
the next cycle. See #35504.
While cleaning up the Certificates/GetCertificate/GetConfigForClient
behavior, also support leaving Certificates/GetCertificate nil if
GetConfigForClient is set, and send unrecognized_name when there are no
available certificates.
Fixes#29139Fixes#18377
Change-Id: I26604db48806fe4d608388e55da52f34b7ca4566
Reviewed-on: https://go-review.googlesource.com/c/go/+/205059
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Also, add Version to CertificateRequestInfo, as the semantics of
SignatureSchemes change based on version: the ECDSA SignatureSchemes are
only constrained to a specific curve in TLS 1.3.
Fixes#32426
Change-Id: I7a551bea864799e98118349ac2476162893d1ffd
Reviewed-on: https://go-review.googlesource.com/c/go/+/205058
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
We'll also use this function for a better selection logic from
Config.Certificates in a later CL.
Updates #32426
Change-Id: Ie239574d02eb7fd2cf025ec36721c8c7e082d0bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/205057
Reviewed-by: Katie Hockman <katie@golang.org>
This refactors a lot of the certificate support logic to make it cleaner
and reusable where possible. These changes will make the following CLs
much simpler.
In particular, the heavily overloaded pickSignatureAlgorithm is gone.
That function used to cover both signing and verifying side, would work
both for pre-signature_algorithms TLS 1.0/1.1 and TLS 1.2, and returned
sigalg, type and hash.
Now, TLS 1.0/1.1 and 1.2 are differentiated at the caller, as they have
effectively completely different logic. TLS 1.0/1.1 simply use
legacyTypeAndHashFromPublicKey as they employ a fixed hash function and
signature algorithm for each public key type. TLS 1.2 is instead routed
through selectSignatureScheme (on the signing side) or
isSupportedSignatureAlgorithm (on the verifying side) and
typeAndHashFromSignatureScheme, like TLS 1.3.
On the signing side, signatureSchemesForCertificate was already version
aware (for PKCS#1 v1.5 vs PSS support), so selectSignatureScheme just
had to learn the Section 7.4.1.4.1 defaults for a missing
signature_algorithms to replace pickSignatureAlgorithm.
On the verifying side, pickSignatureAlgorithm was also checking the
public key type, while isSupportedSignatureAlgorithm +
typeAndHashFromSignatureScheme are not, but that check was redundant
with the one in verifyHandshakeSignature.
There should be no major change in behavior so far. A few minor changes
came from the refactor: we now correctly require signature_algorithms in
TLS 1.3 when using a certificate; we won't use Ed25519 in TLS 1.2 if the
client didn't send signature_algorithms; and we don't send
ec_points_format in the ServerHello (a compatibility measure) if we are
not doing ECDHE anyway because there are no mutually supported curves.
The tests also got simpler because they test simpler functions. The
caller logic switching between TLS 1.0/1.1 and 1.2 is tested by the
transcript tests.
Updates #32426
Change-Id: Ice9dcaea78d204718f661f8d60efdb408ba41577
Reviewed-on: https://go-review.googlesource.com/c/go/+/205061
Reviewed-by: Katie Hockman <katie@golang.org>
This makes Ed25519 certificates work for CreateCRL(). This previously
failed (panic: crypto: requested hash function #0 is unavailable) because
the hash could not be skipped, but Ed25519 uses no hash.
A similar fix has been applied in a few other places when Ed25519 was added
when Ed25519 certificates were originally introduced, but was missed
here.
Change-Id: I16fcfcd53ba3bb8f773e5de972b8fedde1f6350e
Change-Id: I16fcfcd53ba3bb8f773e5de972b8fedde1f6350e
GitHub-Last-Rev: bf7f1458f8
GitHub-Pull-Request: golang/go#35241
Reviewed-on: https://go-review.googlesource.com/c/go/+/204046
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Setting InsecureSkipVerify and VerifyPeerCertificate is the recommended
way to customize and override certificate validation.
However, there is boilerplate involved and it usually requires first
reimplementing the default validation strategy to then customize it.
Provide an example that does the same thing as the default as a starting
point.
Examples of where we directed users to do something similar are in
issues #35467, #31791, #28754, #21971, and #24151.
Fixes#31792
Change-Id: Id033e9fa3cac9dff1f7be05c72dfb34b4f973fd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/193620
Reviewed-by: Adam Langley <agl@golang.org>
dsa.Verify might currently use a nil s inverse in a
multiplication if the public key contains a non-prime Q,
causing a panic. Change this to check that the mod
inverse exists before using it.
Fixes CVE-2019-17596
Fixes#34960
Change-Id: I94d5f3cc38f1b5d52d38dcb1d253c71b7fd1cae7
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/572809
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/205441
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Replace
buf := [HUGE_CONST]*T)(unsafe.Pointer(p))[:]
with
buf := [HUGE_CONST]*T)(unsafe.Pointer(p))[:n:n]
Pointer p points to n of T elements. New unsafe pointer conversion
logic verifies that both first and last elements point into the
same Go variable. And this change adjusts all code to comply with
this rule.
Verified by running
go test -a -short -gcflags=all=-d=checkptr crypto/x509
The test does not fail even with original version of this code. I
suspect it is because all variables I changed live outside of Go
memory. But I am just guessing, I don't really know how pointer
checker works.
Updates golang/go#34972
Change-Id: Ibc33fdc9e2023d9b14905c9badf2f0b683999ab8
Reviewed-on: https://go-review.googlesource.com/c/go/+/204621
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Even though bitwise operations may be slightly more
performant, the readability improvement of a mod
operation is worth the tradeoff.
Change-Id: I352c92ad355c6eb6ef99e3da00e1eff2d2ea5812
Reviewed-on: https://go-review.googlesource.com/c/go/+/204739
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Follow the recommandation from RFC 8422, section 5.1.2 of sending back the
ec_points_format extension when requested by the client. This is to fix
some clients declining the handshake if omitted.
Fixes#31943
Change-Id: I7b04dbac6f9af75cda094073defe081e1e9a295d
Reviewed-on: https://go-review.googlesource.com/c/go/+/176418
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Olivier Poitrey <rs@rhapsodyk.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also, fix the alert value sent when a signature by a client certificate
is invalid in TLS 1.0-1.2.
Fixes#35190
Change-Id: I2ae1d5593dfd5ee2b4d979664aec74aab4a8a704
Reviewed-on: https://go-review.googlesource.com/c/go/+/204157
Reviewed-by: Katie Hockman <katie@golang.org>
As suggested by comments from the review of CL 168478, this adds
Go code to do reverse bytes and removes the asm code, as well
as making a few cosmetic changes.
Change-Id: I08276a11222e03c3b42f4c9dc0d10a371a418be7
Reviewed-on: https://go-review.googlesource.com/c/go/+/203937
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
This adds an asm implementation of the p256 functions used
in crypto/elliptic, utilizing VMX, VSX to improve performance.
On a power9 the improvement is:
elliptic benchmarks:
name old time/op new time/op delta
BaseMult 1.40ms ± 0% 1.44ms ± 0% +2.66% (p=0.029 n=4+4)
BaseMultP256 317µs ± 0% 50µs ± 0% -84.14% (p=0.029 n=4+4)
ScalarMultP256 854µs ± 2% 214µs ± 0% -74.91% (p=0.029 n=4+4)
ecdsa benchmarks:
name old time/op new time/op delta
SignP256 377µs ± 0% 111µs ± 0% -70.57% (p=0.029 n=4+4)
SignP384 6.55ms ± 0% 6.48ms ± 0% -1.03% (p=0.029 n=4+4)
VerifyP256 1.19ms ± 0% 0.26ms ± 0% -78.54% (p=0.029 n=4+4)
KeyGeneration 319µs ± 0% 52µs ± 0% -83.56% (p=0.029 n=4+4)
This implemenation is based on the s390x implementation, using
comparable instructions for most with some minor changes where the
instructions are not quite the same.
Some changes were also needed since s390x is big endian and ppc64le
is little endian.
This also enables the fuzz_test for ppc64le.
Change-Id: I59a69515703b82ad2929f68ba2f11208fa833181
Reviewed-on: https://go-review.googlesource.com/c/go/+/168478
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
localPipe currently flakes in various crypto/tls tests. Since that
function doesn't seem to flake anywhere else, I suspect a kernel bug.
To make the test less flaky, retry the Dial if we suspect that it is
affected. (Worst case, we delay the test by a few seconds before
erroring out as usual.)
Fixes#29583
Change-Id: I357990ffa316edb471bd7d46d6404fa0884da646
Reviewed-on: https://go-review.googlesource.com/c/go/+/202557
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This a revert of CL 174437 and follow up fix CL 201317.
The s390x assembly in this package makes use of an instruction
(specifically KDSA) which is not supported by the current build
machine. Remove this assembly for now, we can revisit this
functionality once we have a newer build machine and can ensure
that this assembly is well tested.
Updates #34927.
Change-Id: I779286fa7d9530a254b53a515ee76b1218821f2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/201360
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I used too small a size for buffers, which can cause a panic in some testing.
The new buffer size is generous and sufficient for all purposes.
Fixes#34927Fixes#34928
Change-Id: Icdbbfed5da87fe3757be40dfd23182b37ec62d58
Reviewed-on: https://go-review.googlesource.com/c/go/+/201317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We should keep a consistent way of formatting errors
in this file.
Fixes#34848
Change-Id: Ibb75908504f381fccab0281a42e788ef8c716b6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/200679
Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Part 1: CL 199499 (GOOS nacl)
Part 2: CL 200077 (amd64p32 files, toolchain)
Part 3: stuff that arguably should've been part of Part 2, but I forgot
one of my grep patterns when splitting the original CL up into
two parts.
This one might also have interesting stuff to resurrect for any future
x32 ABI support.
Updates #30439
Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/200318
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is part two if the nacl removal. Part 1 was CL 199499.
This CL removes amd64p32 support, which might be useful in the future
if we implement the x32 ABI. It also removes the nacl bits in the
toolchain, and some remaining nacl bits.
Updates #30439
Change-Id: I2475d5bb066d1b474e00e40d95b520e7c2e286e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/200077
Reviewed-by: Ian Lance Taylor <iant@golang.org>
You were a useful port and you've served your purpose.
Thanks for all the play.
A subsequent CL will remove amd64p32 (including assembly files and
toolchain bits) and remaining bits. The amd64p32 removal will be
separated into its own CL in case we want to support the Linux x32 ABI
in the future and want our old amd64p32 support as a starting point.
Updates #30439
Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/199499
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
According to spec, the hash must be truncated, but crypto/dsa
does not do it. We can't fix it in crypto/dsa, because it would break
verification of previously generated signatures.
In crypto/x509 however, go can't generate DSA certs, only verify them,
so the fix here should be safe.
Fixes#22017
Change-Id: Iee7e20a5d76f45da8901a7ca686063639092949f
GitHub-Last-Rev: 8041cde8d2
GitHub-Pull-Request: golang/go#34630
Reviewed-on: https://go-review.googlesource.com/c/go/+/198138
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Because errors like:
certificate has expired or is not yet valid
make it difficult to distinguish between "certificate has expired" and
"my local clock is skewed". Including our idea of the local time
makes it easier to identify the clock-skew case, and including the
violated certificate constraint saves folks the trouble of looking it
up in the target certificate.
Change-Id: I52e0e71705ee36f6afde1bb5a47b9b42ed5ead5b
GitHub-Last-Rev: db2ca4029c
GitHub-Pull-Request: golang/go#34646
Reviewed-on: https://go-review.googlesource.com/c/go/+/198046
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently if type of public key is unsupported, error message is "only
RSA and ECDSA public keys supported". After adding Ed25519 this message
is no longer correct.
Moreover, it is superfluous because documentation for
MarshalPKIXPublicKey, CreateCertificateRequest and CreateCertificate
already lists supported public key types.
This CL removes unnecessary details from error message.
It also adds reporting the type of unsupported key, which helps
debugging cases when struct (instead of a pointer) to otherwise correct
public key is given.
Fixes#32640
Change-Id: I45e6e3d756b543688d850009b4da8a4023c05027
Reviewed-on: https://go-review.googlesource.com/c/go/+/196777
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Use the following (suboptimal) script to obtain a list of possible
typos:
#!/usr/bin/env sh
set -x
git ls-files |\
grep -e '\.\(c\|cc\|go\)$' |\
xargs -n 1\
awk\
'/\/\// { gsub(/.*\/\//, ""); print; } /\/\*/, /\*\// { gsub(/.*\/\*/, ""); gsub(/\*\/.*/, ""); }' |\
hunspell -d en_US -l |\
grep '^[[:upper:]]\{0,1\}[[:lower:]]\{1,\}$' |\
grep -v -e '^.\{1,4\}$' -e '^.\{16,\}$' |\
sort -f |\
uniq -c |\
awk '$1 == 1 { print $2; }'
Then, go through the results manually and fix the most obvious typos in
the non-vendored code.
Change-Id: I3cb5830a176850e1a0584b8a40b47bde7b260eae
Reviewed-on: https://go-review.googlesource.com/c/go/+/193848
Reviewed-by: Robert Griesemer <gri@golang.org>
The exception allowed a specific intermediate [1] to chain up to a
broken root that lacked the CA:TRUE X509v3 Basic Constraint.
The broken root [2] is expiring at the end of 2019, so we can remove the
exception in Go 1.14.
Moreover, there is a reissued version of that root [3] (same Subject and
SPKI, valid CA) which expires in 2029, so root stores should have
migrated to it already, making the exception unnecessary.
[1]: https://crt.sh/?caid=57
[2]: https://crt.sh/?id=1616049
[3]: https://crt.sh/?id=55
Change-Id: I43f51100982791b0e8bac90d143b60851cd46dfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/193038
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current implementation panics on nil certificates,
so introduce a nil check and early return true if both
are nil, false if only one is.
Fixes#28743
Change-Id: I71b0dee3e505d3ad562a4470ccc22c3a2579bc52
Reviewed-on: https://go-review.googlesource.com/c/go/+/167118
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Include references in the package-level comment block, expand
the obscure IRO acronym, and add a reference for "the standard
(cryptographic) assumptions".
Fixes#33589
Change-Id: I76c3b0a2f7258b3ab4bf1c8e7681c5d159720a20
GitHub-Last-Rev: 30d5a1e2fb
GitHub-Pull-Request: golang/go#33723
Reviewed-on: https://go-review.googlesource.com/c/go/+/190840
Reviewed-by: Filippo Valsorda <filippo@golang.org>
SSLv3 has been irreparably broken since the POODLE attack 5 years ago
and RFC 7568 (f.k.a. draft-ietf-tls-sslv3-diediedie) prohibits its use
in no uncertain terms.
As announced in the Go 1.13 release notes, remove support for it
entirely in Go 1.14.
Updates #32716
Change-Id: Id653557961d8f75f484a01e6afd2e104a4ccceaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/191976
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>