Because tls.Config now requires more fields to be set
in order for tls-alpn to work, Manager provides a new
TLSConfig method for easier setup.
This CL also adds a new internal package for end-to-end tests.
The package implements a simple ACME CA server.
Fixesgolang/go#25013Fixesgolang/go#25901
Updates golang/go#17251
Change-Id: I2687ea8d5c445ddafad5ea2cdd36cd4e7d10bc86
Reviewed-on: https://go-review.googlesource.com/125495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ACME draft specifies the CA servers should respond
with 201 Created status code but Let's Encrypt
responds with 202 Accepted when creating a new account.
This change adds 202 Accepted as a valid response.
Otherwise, the Client hangs while doing retries,
discarding 202 responses as invalid.
Tests are not updated intentionally
due to this being non-conformant with the spec.
Fixesgolang/go#26251
Change-Id: I2918fce3873592c02e96f4118c4d1ecb42da3c4f
Reviewed-on: https://go-review.googlesource.com/125415
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is neither a '--clearsign' nor a '--detach-sign' which are already
supported. Verification of these signatures is already supported by
ReadMessage.
The code shares a lot with standard encrypt/sign, so mostly a
refactoring of 'Encrypt' to allow use of the code path without
actually doing a signing.
Change-Id: I5bb7487134ffcf1189ed74e28dbbbe1c01b356d1
GitHub-Last-Rev: 01162222600a4a2a230a444387b33883faf596ec
GitHub-Pull-Request: golang/crypto#50
Reviewed-on: https://go-review.googlesource.com/116017
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The retry logic returns an "acme: no more retries for ..." error
in some cases, while *Error type in others.
This change makes retries always return the last error as received
from the CA server, if available. No change in returned values
of successful requests.
Change-Id: I3df2cb332a3e2739bba457c0ee50d7ca5bd836d9
Reviewed-on: https://go-review.googlesource.com/119975
Reviewed-by: Maciej Dębski <maciejd@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Alex Vaghin <ddos@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The new package subtle added in golang.org/cl/112236 breaks
compatibility with App Engine due to the import of unsafe.
This changes adds an App Engine alternative without using unsafe.
Tested with:
$ go test -test.tags=appengine -v
=== RUN TestAliasing
--- PASS: TestAliasing (0.00s)
PASS
ok golang.org/x/crypto/internal/subtle 0.009s
Change-Id: I2fc6b02a860b3ee11fa31652ba302fc7db9df153
Reviewed-on: https://go-review.googlesource.com/119095
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Just ran
gofmt -w .
on the project root. That's all.
Change-Id: Ia90223dda399c1df67e7bcf75c6773de63902cc8
GitHub-Last-Rev: 8ba80b96761b077a4e084a93d5f18e6b2f7375ad
GitHub-Pull-Request: golang/crypto#52
Reviewed-on: https://go-review.googlesource.com/119375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Signing was moved in NewEntity as it makes more sense there, but there
might be code that relies on SerializePrivate to make signatures with
parameters that were modified after NewEntity.
As it used to always sign in SerializePrivate, it shouldn't break
anything to sign in both places.
Fixesgolang/go#25463
Change-Id: Ia7f509daf31ac05fedc441225d554f333b288d70
Reviewed-on: https://go-review.googlesource.com/118015
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Yaron de Leeuw <jarondl@google.com>
Reviewed-by: Alexandre Viau <viau.alexandre@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
When failing, TestKeyExpiry would output the wrong expected key id. It
would output "Expected key 1ABB25A0" instead of "Expected key 96A672F5".
Avoid this mistake by declaring the variable only once and using it in
the error format.
Change-Id: I860d82bf2c7fa80558051cdb21a41d506e95c25f
Reviewed-on: https://go-review.googlesource.com/118958
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing code was wrongly assuming that UserID packets must be
immediately followed by a Signature packet. However, this is not true.
See RFC4880 11.1:
> Immediately following each User ID packet, there are zero or more
> Signature packets.
This change will ensure that Entities that are not immediately followed
by a Signature packet are read without raising a StructuralError.
Instead, UserID packets that are not immediately followed by a self
signature will be ignored.
Maximum backwards compatibility is retained because revoked UserIDs are
not added to the Entity's identities.
In a follow-up patch, we should probably add these UserIDs to the
Entity's identities too, but not without making sure that the revocation
is also available in the Entity's (or the Identity's) Revocations slice.
This would require adding support for a new Signature Type,
"Certification revocation signature", as defined in RFC 48880 5.2.1.
Fixesgolang/go#25850
Change-Id: Idde34b97429998f28e0c687171024e51ed959bf0
Reviewed-on: https://go-review.googlesource.com/118376
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
AnyOverlap and InexactOverlap implement checks for the aliasing
requirements defined by the crypto/cipher interfaces. Apply them to all
implementations as the actual requirement could be architecture-dependent
and user code should not rely on undefined behavior.
Updates golang/go#21624
Change-Id: I465de02fb3fec4e0c6f1fdee1ef6ae7ed5abff10
Reviewed-on: https://go-review.googlesource.com/112236
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
To comply with the specification the value of the extension should be a ASN.1
OCTET STRING rather than a raw SHA 256 hash. This change uses asn1.Marshal to
wrap the hash before putting it in the extension.
Change-Id: I4ebe88a00238c6f928555d605e4b5dd98aad8128
Reviewed-on: https://go-review.googlesource.com/118696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
A var isn't needed and a const is what the upstream (Go 1.10+) version
it's copying is.
Change-Id: I335270be3b3d09ac3c22cf6fb889a74ac39b8f1d
Reviewed-on: https://go-review.googlesource.com/116379
Reviewed-by: Filippo Valsorda <filippo@golang.org>
GetCertificate has all the information it needs to know if a client
supports ECDSA in ClientHelloInfo. Deprecate and ignore ForceRSA, and
just obtain a RSA certificate on the fly when a client that doesn't
support ECDSA connects.
This changes the cache key format to have a "+rsa" suffix for RSA
certificates. The default (ForceRSA = false) cache key is unchanged,
so most DirCache instances will still be valid. Caches created with
ForceRSA set will be silently ignored and certificates reissued.
The cache keys for HTTP tokens and the account key are changed to be
guaranteed not to overlap with valid domain names as well.
Note that ECDSA support detection is more strict in following RFC 5246
than crypto/tls, which ignores signature_algorithms.
Fixesgolang/go#22066
Change-Id: I70227747b563d6849cb693f83a950d57040b3f39
Reviewed-on: https://go-review.googlesource.com/114501
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There's been some confusion about failed request retries.
Rightfully so: some requests are retried, others are not.
This change attempts to clarify the issue and unify backoff
usage in all Client's methods by introducing a new exported
optional field RetryBackoff and adding retry logic where missing.
Also, updates golang/go#22457.
Change-Id: Ied434edf998d52925a48b6b3b2407d45a6e9d2ee
Reviewed-on: https://go-review.googlesource.com/109615
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Most implementations, including this one, consider the private key to be
the concatenation of the initial 32-byte seed and the public key.
However the RFC 8032 formulation considers the "private key" to just be
the seed, which, in turn, means the upcoming draft-ietf-curdle-pkix
specification for embedding Ed25519 into PKCS#8 only stores the seed.
Exporting ed25519.PrivateKey to the seed is easy: key[:32]. Importing
the seed to ed25519.PrivateKey is not currently possible because the
logic is tied up in ed25519.GenerateKey. Split out
ed25519.NewKeyFromSeed for this, as well as an ed25519.PrivateKey.Seed
accessor to keep the abstraction consistent.
Change-Id: I4068eaf2073009dff3d84224aa145b56b59a5854
Reviewed-on: https://go-review.googlesource.com/115297
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes a bug introduced in golang.org/cl/100078 where incorrect
ACME client was used, causing nil pointer dereference.
The change also improves related tests,
removing code paths diverging in testing.
Fixesgolang/go#25581
Change-Id: I8c5531fcc5814a5a64f14911c0ad86c476a76d2f
Reviewed-on: https://go-review.googlesource.com/114817
Reviewed-by: Filippo Valsorda <filippo@golang.org>
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.
Fixesgolang/go#23426
Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Previously if you created a new Entity then ran `Serialize` _before_ running `SerializePrivate`, the resulting armored public key was corrupted, giving the error of `unexpected EOF`. This fix signs the public key with the private key upon creation of a NewEntity. Since SerializePrivate only is applicable to entities created with NewEntity per the docs we can also safely remove the signing portion from that function.
Fixes#25463
Change-Id: I58b808987ee173079f33bce3d6c3527f9233b2cd
GitHub-Last-Rev: 2c4b8e4d630a06d782816f8fbd3d59f01ece2565
GitHub-Pull-Request: golang/crypto#47
Reviewed-on: https://go-review.googlesource.com/114001
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Forgotten file from CL 112635.
The integration tests didn't catch this because the integration tests
never run (sshd isn't in $PATH usually), but even when $PATH is
modified, it seems to have been failing for ages on both Debian jessie
and stretch. I'll fix the tests and make them run in TryBots in later
changes.
Change-Id: I85fd3b6109a73990bc353a61da5f527b9a698501
Reviewed-on: https://go-review.googlesource.com/113056
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The extra goroutines were distracting while debugging something else,
especially as I wasn't using that feature. This also saves a bit of
memory.
Change-Id: Ia6489e64bbd3d5a6ff699a25018676d8ff8bd2e4
Reviewed-on: https://go-review.googlesource.com/112635
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
The tag matches the platforms defined in util*.go
where the most tested logic is defined.
Change-Id: I90f67d988c795738c3effbc8554a933a7cb355d2
Reviewed-on: https://go-review.googlesource.com/112555
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Changes function name from "testUnalignedWrites" to "TestUnalignedWrites"
which makes "go test" actually run this test.
Change-Id: Ie46f11ee1fd5c8780d5704d2fabe6ddb229262f9
Reviewed-on: https://go-review.googlesource.com/111282
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When c = ∞, z = 0 and 0 does not have a modular inverse, triggering
undefined behavior (recently changed to returning nil) in ModInverse.
Unclear how this used to work anyway. Looks like ModInverse was
leaving the receiver untouched, making zInv = 0 when pool = nil.
Fixesgolang/go#25199
Change-Id: Ib39abf59f0e71cf43cdb5836142ebdd3b206fb3f
Reviewed-on: https://go-review.googlesource.com/110695
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
CL 110355 switched out the adhoc cpu feature detection for x/sys/cpu, in
doing so the AVX2 check was broken. The assembly code uses MULX which is
part of BMI2.
Updates golang/go#24843
Change-Id: I4719b8ff3211eb1c823099512e593e540d6f3be8
GitHub-Last-Rev: 70542b53cd09fcae26c3579cd84bcee39a4b8a57
GitHub-Pull-Request: golang/crypto#44
Reviewed-on: https://go-review.googlesource.com/110796
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Doesn't matter because contentKey and lengthKey are the same length,
but we should really be looping over lengthKey here.
Change-Id: Ic7af3c553eb4382239bec1c030e77c7f5baa0662
Reviewed-on: https://go-review.googlesource.com/109735
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some OCSP responders contain more than one certificate, which can be
used to "help the OCSP client verify the responders signature" (RFC
6960 section 4.2.1). This client doesn't do verification of the chain
to the root, but it's not an error for a responder to send more than
one.
Fixesgolang/go#21527
Change-Id: Ie23cfcb347a4f7cdfb1a0cbad2aa03a1242553af
Reviewed-on: https://go-review.googlesource.com/57510
Reviewed-by: Adam Langley <agl@golang.org>
Unlock compares the length of the passphrase with the given one before
calling subtle.ConstantTimeCompare. This is redundant, since
ConstantTimeCompare already perform a lengths check before doing
anything. Remove the check from Unlock.
Updates golang/go#25173
Change-Id: Ib5fec3a94392bddf2996f5c6bf5a414529e86f2f
Reviewed-on: https://go-review.googlesource.com/110068
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
SIMD implementations of ChaCha20 (such as CL 35842) interleave block
computations in order to achieve high performance. This means that
they produce more than 64 bytes of output at a time. Unfortunately
when encrypting small amounts of data (such as Poly1305 keys) the
current interface to ChaCha20 forces the additional encrypted blocks
of output to be discarded and recomputed later since it does not
maintain any state. This additional overhead slows down the encryption
of small amounts of data when using such optimized code.
This CL makes the generic ChaCha20 implementation stateful, caching
key, nonce and counter values and buffering any unused key stream bytes.
ChaCha20 now also implements the high level cipher.Stream interface
which makes the API more consistent with other stream ciphers in the
standard library's crypto package. This will make it easier to add high
performance SIMD implementations in the future.
In addition to modifying the API I have also added some optimizations
to improve the performance of the generic implementation. Note that
the performance will improve further on amd64 with Go 1.11 due to
CL 95475 (binary.LittleEndian.PutUint32 optimization). These benchmarks
are based on Go 1.10.1.
name old speed new speed delta
ChaCha20/32 174MB/s ± 2% 174MB/s ± 1% ~ (p=0.796 n=10+10)
ChaCha20/63 309MB/s ± 1% 337MB/s ± 2% +9.32% (p=0.000 n=10+9)
ChaCha20/64 299MB/s ± 2% 350MB/s ± 1% +17.12% (p=0.000 n=9+8)
ChaCha20/256 297MB/s ± 2% 390MB/s ± 1% +31.40% (p=0.000 n=10+10)
ChaCha20/1024 300MB/s ± 0% 400MB/s ± 3% +33.38% (p=0.000 n=7+10)
ChaCha20/1350 290MB/s ± 1% 386MB/s ± 2% +33.10% (p=0.000 n=9+10)
ChaCha20/65536 301MB/s ± 1% 416MB/s ± 2% +38.25% (p=0.000 n=9+10)
ChaCha20-Poly1305 (AEAD optimizations manually disabled):
name old speed new speed delta
Chacha20Poly1305Open_64 122MB/s ± 7% 131MB/s ± 2% +7.23% (p=0.000 n=18+18)
Chacha20Poly1305Seal_64 125MB/s ± 4% 137MB/s ± 2% +9.88% (p=0.000 n=20+19)
Chacha20Poly1305Open_1350 244MB/s ± 4% 305MB/s ± 3% +25.04% (p=0.000 n=20+19)
Chacha20Poly1305Seal_1350 242MB/s ± 3% 309MB/s ± 2% +27.56% (p=0.000 n=20+19)
Chacha20Poly1305Open_8K 260MB/s ± 7% 338MB/s ± 3% +29.96% (p=0.000 n=20+19)
Chacha20Poly1305Seal_8K 262MB/s ± 5% 335MB/s ± 4% +27.80% (p=0.000 n=20+19)
No change in allocations for either set of benchmarks.
Change-Id: I28ca7947904e9d79debe2d5aac6623526fe5e595
Reviewed-on: https://go-review.googlesource.com/104856
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Filippo Valsorda
Alex Vaghin
Wilfried Teiken
ia
aviau
Roland Shoemaker
Maciej Dębski
Brad Fitzpatrick
David Benjamin
Tobias Klauser
Leo Antunes
Ryan Canty
Michael Munday
bill_ofarrell
Hana (Hyang-Ah) Kim
Leon Klingele
Filip Haglund
Kris Kwiatkowski
Tom Thorogood
Joe Shaw
Andreas Auernhammer
Alberto Donizetti