A comment existed referencing RC4 coming before AES because of it's
vulnerability to the Lucky 13 attack. This clarifies that the Lucky 13 attack
only effects AES-CBC, and not AES-GCM.
Fixes#14474
Change-Id: Idcb07b5e0cdb0f9257cf75abea60129ba495b5f5
Reviewed-on: https://go-review.googlesource.com/19845
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In some cases the documentation for functions in this package was
lacking from the beginning and, in order cases, the documentation didn't
keep pace as the package grew.
This change somewhat addresses that.
Updates #13711.
Change-Id: I25b2bb1fcd4658c5417671e23cf8e644d08cb9ab
Reviewed-on: https://go-review.googlesource.com/18486
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Add example of how to use the aes package to
implement AES encryption and decryption
within an application.
Per feedback, use more secure AES-GCM implementation as an
example in crypto/cipher instead of AES directly.
Change-Id: I84453ebb18e0bc79344a24171a031ec0d7ccec2e
Reviewed-on: https://go-review.googlesource.com/18803
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Add several instructions that were used via BYTE and use them.
Instructions added: PEXTRB, PEXTRD, PEXTRQ, PINSRB, XGETBV, POPCNT.
Change-Id: I5a80cd390dc01f3555dbbe856a475f74b5e6df65
Reviewed-on: https://go-review.googlesource.com/18593
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Conn.Close sends an encrypted "close notify" to signal secure EOF.
But writing that involves acquiring mutexes (handshake mutex + the
c.out mutex) and writing to the network. But if the reason we're
calling Conn.Close is because the network is already being
problematic, then Close might block, waiting for one of those mutexes.
Instead of blocking, and instead of introducing new API (at least for
now), distinguish between a normal Close (one that sends a secure EOF)
and a resource-releasing destructor-style Close based on whether there
are existing Write calls in-flight.
Because io.Writer and io.Closer aren't defined with respect to
concurrent usage, a Close with active Writes is already undefined, and
should only be used during teardown after failures (e.g. deadlines or
cancelations by HTTP users). A normal user will do a Write then
serially do a Close, and things are unchanged for that case.
This should fix the leaked goroutines and hung net/http.Transport
requests when there are network errors while making TLS requests.
Change-Id: If3f8c69d6fdcebf8c70227f41ad042ccc3f20ac9
Reviewed-on: https://go-review.googlesource.com/18572
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The AESNI GCM code decrypts and authenticates concurrently and so
overwrites the destination buffer even in the case of an authentication
failure.
This change updates the documentation to make that clear and also
mimics that behaviour in the generic code so that different platforms
act identically.
Fixes#13886
Change-Id: Idc54e51f01e27b0fc60c1745d50bb4c099d37e94
Reviewed-on: https://go-review.googlesource.com/18480
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Thanks to Kevin Kirsche (github kkirsche).
Change-Id: Ia0017371f56065a5e88d1ebb800a6489136ee9b1
Reviewed-on: https://go-review.googlesource.com/18280
Reviewed-by: Andrew Gerrand <adg@golang.org>
SEC-1 says: “The component privateKey is the private key defined to be
the octet string of length ⌊log₂(n)/8⌋ (where n is the order of the
curve)”.
Previously the code for parsing ECC private keys would panic (on
non-amd64) when the private was too long. It would also pass a too-short
private key to crypto/elliptic, possibly resulting in undesirable
behaviour.
This change makes the parsing function handle both too much and too
little padding because GnuTLS does the former and OpenSSL did the latter
until 30cd4ff294252c4b6a4b69cbef6a5b4117705d22. It also causes
serialisation to pad private keys correctly.
Fixes#13699
Change-Id: If9c2faeaeb45af8a4d7770d784f3d2633e7f8290
Reviewed-on: https://go-review.googlesource.com/18094
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
s/encrypt/decrypt/
The text is unsafe to cut and paste...
Change-Id: Iab19ddf8182d087e9a4b4d34a9eeabd1d2aa02d6
Reviewed-on: https://go-review.googlesource.com/18104
Reviewed-by: Rob Pike <r@golang.org>
Give a link to the wikipedia page describing the mechanism and
explain better how to use the same buffer for input and output.
Change-Id: If6dfd6cf9c6dff0517cb715f60a11349dbdd91e0
Reviewed-on: https://go-review.googlesource.com/18103
Reviewed-by: Russ Cox <rsc@golang.org>
This change adds a check after computing an RSA signature that the
signature is correct. This prevents an error in the CRT computation from
leaking the private key. See references in the linked bug.
benchmark old ns/op new ns/op delta
BenchmarkRSA2048Sign-3 5713305 6225215 +8.96%
Fixes#12453
Change-Id: I1f24e0b542f7c9a3f7e7ad4e971db3dc440ed3c1
Reviewed-on: https://go-review.googlesource.com/17862
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The orders of the curves in crypto/elliptic are all very close to a
power of two. None the less, there is a tiny bias in the private key
selection.
This change makes the distribution uniform by resampling in the case
that a private key is >= to the order of the curve. (It also switches
from using BitSize to Params().N.BitLen() because, although they're the
same value here, the latter is technically the correct thing to do.)
The private key sampling and nonce sampling in crypto/ecdsa don't have
this issue.
Fixes#11082.
Change-Id: Ie2aad563209a529fa1cab522abaf5fd505c7269a
Reviewed-on: https://go-review.googlesource.com/17460
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Until now we've used ErrUnknownAlgorithm but that's a bit confusing
when it is returned for obviously-known things like MD5.
Fixes#10431.
Change-Id: Ief8a8ef46e5b99bd4fd18e1acd7ae398a484bac3
Reviewed-on: https://go-review.googlesource.com/17380
Reviewed-by: Adam Langley <agl@golang.org>
Some software that produces certificates doesn't encode integers
correctly and, about half the time, ends up producing certificates with
serial numbers that are actually negative.
This buggy software, sadly, appears to be common enough that we should
let these errors pass. This change allows a Certificate.SerialNumber to
be negative.
Fixes#8265.
Change-Id: Ief35dae23988fb6d5e2873e3c521366fb03c6af4
Reviewed-on: https://go-review.googlesource.com/17247
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
During the TLS handshake, check the cipher suite the server selects is
one of those offered in the ClientHello. The code was checking it was
in the larger list that was sometimes whittled down for the ClientHello.
Fixes#13174
Change-Id: Iad8eebbcfa5027f30403b9700c43cfa949e135bb
Reviewed-on: https://go-review.googlesource.com/16698
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The user can inspect the record data to detect that the other side is
not using the TLS protocol.
This will be used by the net/http client (in a follow-on CL) to detect
when an HTTPS client is speaking to an HTTP server.
Updates #11111.
Change-Id: I872f78717aa8e8e98cebd8075436209a52039a73
Reviewed-on: https://go-review.googlesource.com/16078
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In keysFromMasterSecret(), don't copy from serverRandom into
seed[:len(clientRandom)]. Actually, switch from an array to a slice in
keysFromMasterSecret() and masterFromPreMasterSecret() so the length
need not be given; that's how it's done elsewhere in the file.
Fixes#13181
Change-Id: I92abaa892d1bba80c2d4f12776341cda7d538837
Reviewed-on: https://go-review.googlesource.com/16697
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
(This relands commit a4dcc692011bf1ceca9b1a363fd83f3e59e399ee.)
https://tools.ietf.org/html/rfc6066#section-3 states:
“Literal IPv4 and IPv6 addresses are not permitted in "HostName".”
However, if an IP literal was set as Config.ServerName (which could
happen as easily as calling Dial with an IP address) then the code would
send the IP literal as the SNI value.
This change filters out IP literals, as recognised by net.ParseIP, from
being sent as the SNI value.
Fixes#13111.
Change-Id: I6e544a78a01388f8fe98150589d073b917087f75
Reviewed-on: https://go-review.googlesource.com/16776
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is based on the implementation used in OpenSSL, from a
submission by Shay Gueron and myself. Besides using assembly,
this implementation employs several optimizations described in:
S.Gueron and V.Krasnov, "Fast prime field elliptic-curve
cryptography with 256-bit primes"
In addition a new and improved modular inverse modulo N is
implemented here.
The performance measured on a Haswell based Macbook Pro shows 21X
speedup for the sign and 9X for the verify operations.
The operation BaseMult is 30X faster (and the Diffie-Hellman/ECDSA
key generation that use it are sped up as well).
The adaptation to Go with the help of Filippo Valsorda
Updated the submission for faster verify/ecdh, fixed some asm syntax
and API problems and added benchmarks.
Change-Id: I86a33636747d5c92f15e0c8344caa2e7e07e0028
Reviewed-on: https://go-review.googlesource.com/8968
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
https://tools.ietf.org/html/rfc6066#section-3 states:
“Literal IPv4 and IPv6 addresses are not permitted in "HostName".”
However, if an IP literal was set as Config.ServerName (which could
happen as easily as calling Dial with an IP address) then the code would
send the IP literal as the SNI value.
This change filters out IP literals, as recognised by net.ParseIP, from
being sent as the SNI value.
Fixes#13111.
Change-Id: Ie9ec7acc767ae172b48c9c6dd8d84fa27b1cf0de
Reviewed-on: https://go-review.googlesource.com/16742
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Unification of implementation of existing md5.Write function
with other implementations (sha1, sha256, sha512).
Change-Id: I58ae02d165b17fc221953a5b4b986048b46c0508
Reviewed-on: https://go-review.googlesource.com/16621
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Additionally, add a test for CTR mode to cover a range of block sizes.
Fixes#12975
Change-Id: I458aac1616228747e62f92f823768d55e874877a
Reviewed-on: https://go-review.googlesource.com/16050
Reviewed-by: Adam Langley <agl@golang.org>
The format for a CSR is horribly underspecified and we had a mistake.
The code was parsing the attributes from the CSR as a
pkix.AttributeTypeAndValueSET, which is only almost correct: it works so
long as the requested extensions don't contain the optional “critical”
flag.
Unfortunately this mistake is exported somewhat in the API and the
Attributes field of a CSR actually has the wrong type. I've moved this
field to the bottom of the structure and updated the comment to reflect
this.
The Extensions and other fields of the CSR structure can be saved
however and this change does that.
Fixes#11897.
Change-Id: If8e2f5c21934800b72b041e38691efc3e897ecf1
Reviewed-on: https://go-review.googlesource.com/12717
Reviewed-by: Rob Pike <r@golang.org>
Platform-specific verification needs the ASN.1 contents of a certificate
but that might not be provided if the Certificate was not created by
ParseCertificate. In order to avoid a panic on Windows, and to make
behaviour consistent across platforms, this change causes verification
to fail when the ASN.1 contents of a certificate are not available.
Fixes#12184
Change-Id: I4395d74934e675c179eaf4cded1094a756e478bb
Reviewed-on: https://go-review.googlesource.com/14053
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change causes the types of skipped PEM blocks to be recorded when
no certificate or private-key data is found in a PEM input. This allows
for better error messages to be return in the case of common errors like
switching the certifiate and key inputs to X509KeyPair.
Fixes#11092
Change-Id: Ifc155a811cdcddd93b5787fe16a84c972011f2f7
Reviewed-on: https://go-review.googlesource.com/14054
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
https://tools.ietf.org/html/rfc7301#section-3.1 specifies that a
ProtocolName may not be empty. This change enforces this for ServerHello
messages—it's already enforced for ClientHello messages.
Change-Id: Ic5a5be6bebf07fba90a3cabd10b07ab7b4337f53
Reviewed-on: https://go-review.googlesource.com/12003
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In Go 1.5, Config.Certificates is no longer required if
Config.GetCertificate has been set. This change updated four comments to
reflect that.
Change-Id: Id72cc22fc79e931b2d645a7c3960c3241042762c
Reviewed-on: https://go-review.googlesource.com/13800
Reviewed-by: Adam Langley <agl@golang.org>
The existing implementation didn't use the CLMUL instructions for fast
and constant time binary-field multiplication. With this change, amd64
CPUs that support both AES and CLMUL instructions will use an optimised
asm implementation.
benchmark old ns/op new ns/op delta
BenchmarkAESGCMSeal8K 91723 3200 -96.51%
BenchmarkAESGCMOpen8K 91487 3324 -96.37%
BenchmarkAESGCMSeal1K 11873 546 -95.40%
BenchmarkAESGCMOpen1K 11833 594 -94.98%
benchmark old MB/s new MB/s speedup
BenchmarkAESGCMSeal8K 89.31 2559.62 28.66x
BenchmarkAESGCMOpen8K 89.54 2463.78 27.52x
BenchmarkAESGCMSeal1K 86.24 1872.49 21.71x
BenchmarkAESGCMOpen1K 86.53 1721.78 19.90x
Change-Id: Idd63233098356d8b353d16624747b74d0c3f193e
Reviewed-on: https://go-review.googlesource.com/10484
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Go 1.5 allowed TLS connections where Config.Certificates was nil as long
as the GetCertificate callback was given. However, tls.Listen wasn't
updated accordingly until this change.
Change-Id: I5f67f323f63c988ff79642f3daf8a6b2a153e6b2
Reviewed-on: https://go-review.googlesource.com/13801
Reviewed-by: Adam Langley <agl@golang.org>
Could go in 1.5, although not critical.
See also #12107
Change-Id: I7f1608b58581d21df4db58f0db654fef79e33a90
Reviewed-on: https://go-review.googlesource.com/13481
Reviewed-by: Dave Cheney <dave@cheney.net>
Strengthening VerifyHostname exposed the fact that for resumed
connections, ConnectionState().VerifiedChains was not being saved
and restored during the ClientSessionCache operations.
Do that.
This change just saves the verified chains in the client's session
cache. It does not re-verify the certificates when resuming a
connection.
There are arguments both ways about this: we want fast, light-weight
resumption connections (thus suggesting that we shouldn't verify) but
it could also be a little surprising that, if the verification config
is changed, that would be ignored if the same session cache is used.
On the server side we do re-verify client-auth certificates, but the
situation is a little different there. The client session cache is an
object in memory that's reset each time the process restarts. But the
server's session cache is a conceptual object, held by the clients, so
can persist across server restarts. Thus the chance of a change in
verification config being surprisingly ignored is much higher in the
server case.
Fixes#12024.
Change-Id: I3081029623322ce3d9f4f3819659fdd9a381db16
Reviewed-on: https://go-review.googlesource.com/13164
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
This change alters the certificate used in many tests so that it's no
longer self-signed. This allows some tests to exercise the standard
certificate verification paths in the future.
Change-Id: I9c3fcd6847eed8269ff3b86d9b6966406bf0642d
Reviewed-on: https://go-review.googlesource.com/13244
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
This allows running a cross-compile like
GOOS=darwin GOARCH=arm go build std
to check that everything builds.
Otherwise there is a redefinition error because both
root_nocgo_darwin.go and root_darwin_armx.go
supply initSystemRoots.
Change-Id: Ic95976b2b698d28c629bfc93d8dac0048b023578
Reviewed-on: https://go-review.googlesource.com/12897
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Update the docs to explain the code added in
commit 67e1d400.
Fixes#11831.
Change-Id: I8fe72e449507847c4bd9d77de40947ded7f2ff9d
Reviewed-on: https://go-review.googlesource.com/12515
Reviewed-by: Dave Cheney <dave@cheney.net>
