Add missing function prototypes.
Fix function prototypes.
Use FP references instead of SP references.
Fix variable names.
Update comments.
Clean up whitespace. (Not for vet.)
All fairly minor fixes to make vet happy.
Updates #11041
Change-Id: Ifab2cdf235ff61cdc226ab1d84b8467b5ac9446c
Reviewed-on: https://go-review.googlesource.com/27713
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Found by vet.
Updates #11041
Change-Id: I5217b3e20c6af435d7500d6bb487b9895efe6605
Reviewed-on: https://go-review.googlesource.com/27493
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In other systems, putting a leaf certificate in the root store works to
express that exactly that certificate is acceptable. This change makes
that work in Go too.
Fixes#16763.
Change-Id: I5c0a8dbc47aa631b23dd49061fb217ed8b0c719c
Reviewed-on: https://go-review.googlesource.com/27393
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For some reason, ISO decided to duplicate the OID for RSA+SHA1. Most
pertinantly, the makecert.exe utility on Windows is known to have used
this OID.
This change makes the ISO OID an alias for the normal one.
Change-Id: I60b76265bf1721282bdb0d5c99c98d227c18a878
Reviewed-on: https://go-review.googlesource.com/27394
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If SetSessionTicketKeys was called on a fresh tls.Config, the configured
keys would be overridden with a random key by serverInit.
Fixes#15421.
Change-Id: I5d6cc81fc3e5de4dfa15eb614d102fb886150d1b
Reviewed-on: https://go-review.googlesource.com/27317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These were new with TLS 1.2 and, reportedly, some servers require it.
Since it's easy, this change adds suport for three flavours of
AES-128-CBC with SHA-256 MACs.
Other testdata/ files have to be updated because this changes the list
of cipher suites offered by default by the client.
Fixes#15487.
Change-Id: I1b14330c31eeda20185409a37072343552c3464f
Reviewed-on: https://go-review.googlesource.com/27315
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Although the term “RSA” is almost synonymous with PKCS#1 v1.5, that
standard is quite flawed, cryptographically speaking. Bellare and
Rogaway fixed PKCS#1 v1.5 with OAEP (for encryption) and PSS (for
signatures) but they only see a fraction of the use of v1.5.
This change adds support for creating and verifying X.509 certificates
that use PSS signatures. Sadly, every possible dimension of flexibility
seems to have been reflected in the integration of X.509 and PSS
resulting in a huge amount of excess complexity. This change only
supports one “sane” configuration for each of SHA-{256, 384, 512}.
Hopefully this is sufficient because it saves a lot of complexity in the
code.
Although X.509 certificates with PSS signatures are rare, I'm inclined
to look favourably on them because they are sufficiently superior.
Fixes#15958.
Change-Id: I7282e0b68ad0177209f8b2add473b94aa5224c07
Reviewed-on: https://go-review.googlesource.com/24743
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The RFC is clear that the Parameters in an AlgorithmIdentifer for an RSA
public key must be NULL. BoringSSL enforces this so we have strong
evidence that this is a widely compatible change.
Embarrassingly enough, the major source of violations of this is us. Go
used to get this correct in only one of two places. This was only fixed
in 2013 (with 4874bc9b). That's why lots of test certificates are
updated in this change.
Fixes#16166.
Change-Id: Ib9a4551349354c66e730d44eb8cee4ec402ea8ab
Reviewed-on: https://go-review.googlesource.com/27312
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
subtle.ConstantTimeCompare now tests the length of the inputs (although
it didn't when this code was written) so this test in crypto/hmac is now
superfluous.
Fixes#16336.
Change-Id: Ic02d8537e776fa1dd5694d3af07a28c4d840d14b
Reviewed-on: https://go-review.googlesource.com/27239
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the SerialNumber is nil in the template then the resulting panic is
rather deep in encoding/asn1 and it's not obvious what went wrong.
This change tests and returns a more helpful error in this case.
Fixes#16603.
Change-Id: Ib30d652555191eb78f705dff8d909e4b5808f9ca
Reviewed-on: https://go-review.googlesource.com/27238
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Moves the state.ServerName assignment to outside the if
statement that checks for handshakeComplete.
Fixes#15571
Change-Id: I6c4131ddb16389aed1c410a975f9aa3b52816965
Reviewed-on: https://go-review.googlesource.com/22862
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Give *recordingConn the correct WriteTo signature
to be an io.WriterTo. This makes vet happy.
It also means that it'll report errors,
which were previously being ignored.
Updates #11041
Change-Id: I13f171407d63f4b62427679bff362eb74faddca5
Reviewed-on: https://go-review.googlesource.com/27121
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
VPSHUFD should take an unsigned argument to be consistent with
PSHUFD. Also fix all usage.
Fixes#16499
Change-Id: Ie699c102afed0379445914a251710365b14d89b6
Reviewed-on: https://go-review.googlesource.com/25383
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
https://golang.org/cl/25233 was detecting the OS X release at compile
time, not run time. Detect it at run time instead.
Fixes#16473 (again)
Change-Id: I6bec4996e57aa50c52599c165aa6f1fae7423fa7
Reviewed-on: https://go-review.googlesource.com/25281
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Conservative fix for the OS X 10.8 crash. We can unify them back together
during the Go 1.8 dev cycle.
Fixes#16473
Change-Id: If07228deb2be36093dd324b3b3bcb31c23a95035
Reviewed-on: https://go-review.googlesource.com/25233
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
I believe it's necessary to use a buffer size smaller than 64KB because
(at least some versions of) Window using a TCP receive window less than
64KB. Currently the client and server use buffer sizes of 16KB and 32KB,
respectively (the server uses io.Copy, which defaults to 32KB internally).
Since the server has been using 32KB, it should be safe for the client to
do so as well.
Fixes#15899
Change-Id: I36d44b29f2a5022c03fc086213d3c1adf153e983
Reviewed-on: https://go-review.googlesource.com/24581
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This fixes some 40 warnings from go vet.
Fixes#16134.
Change-Id: Ib9fcba275fe692f027a2a07b581c8cf503b11087
Reviewed-on: https://go-review.googlesource.com/24287
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
I don't see how the call could fail, so, no test. Just a code cleanup in
case it can fail in the future.
Fixes#15987.
Change-Id: If4af0d5e7d19cc8b13fb6a4f7661c37fb0015e83
Reviewed-on: https://go-review.googlesource.com/23860
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Change-Id: I68d66fccf9cc8f7137c92b94820ce7d6f478a185
Reviewed-on: https://go-review.googlesource.com/23310
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change causes TLS handshake messages to be buffered and written in
a single Write to the underlying net.Conn.
There are two reasons to want to do this:
Firstly, it's slightly preferable to do this in order to save sending
several, small packets over the network where a single one will do.
Secondly, since 37c28759ca errors from
Write have been returned from a handshake. This means that, if a peer
closes the connection during a handshake, a “broken pipe” error may
result from tls.Conn.Handshake(). This can mask any, more detailed,
fatal alerts that the peer may have sent because a read will never
happen.
Buffering handshake messages means that the peer will not receive, and
possibly reject, any of a flow while it's still being written.
Fixes#15709
Change-Id: I38dcff1abecc06e52b2de647ea98713ce0fb9a21
Reviewed-on: https://go-review.googlesource.com/23609
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This fixes `go test go/types`.
https://golang.org/cl/23487/ introduced this code which contains
two unused variables (declared and assigned to, but never read).
cmd/compile doesn't report the error due open issue #8560 (the
variables are assigned to in a closure), but go/types does. The
build bot only runs go/types tests in -short mode (which doesn't
typecheck the std lib), hence this doesn't show up on the dashboard
either.
We cannot call b.Fatal and friends in the goroutine. Communicating
the error to the invoking function requires a channel or a mutex.
Unless the channel/sycnhronized variable is tested in each iteration
that follows, the iteration blocks if there's a failure. Testing in
each iteration may affect benchmark times.
One could use a time-out but that time depends on the underlying system.
Panicking seems good enough in this unlikely case; better than hanging
or affecting benchmark times.
Change-Id: Idce1172da8058e580fa3b3e398825b0eb4316325
Reviewed-on: https://go-review.googlesource.com/23528
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The Windows builders run the throughput benchmarks really slowly with a
64kb buffer. Lowering it to 16kb brings the performance back into line
with the other builders.
This is a work-around to get the build green until we can figure out why
the Windows builders are slow with the larger buffer size.
Update #15899
Change-Id: I215ebf115e8295295c87f3b3e22a4ef1f9e77f81
Reviewed-on: https://go-review.googlesource.com/23574
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current code, introduced after Go 1.6 to improve latency on
low-bandwidth connections, sends 1 kB packets until 1 MB has been sent,
and then sends 16 kB packets (the maximum record size).
Unfortunately this decreases throughput for 1-16 MB responses by 20% or so.
Following discussion on #15713, change cutoff to 128 kB sent
and also grow the size allowed for successive packets:
1 kB, 2 kB, 3 kB, ..., 15 kB, 16 kB.
This fixes the throughput problems: the overhead is now closer to 2%.
I hope this still helps with latency but I don't have a great way to test it.
At the least, it's not worse than Go 1.6.
Comparing MaxPacket vs DynamicPacket benchmarks:
name maxpkt time/op dyn. time/op delta
Throughput/1MB-8 5.07ms ± 7% 5.21ms ± 7% +2.73% (p=0.023 n=16+16)
Throughput/2MB-8 15.7ms ±201% 8.4ms ± 5% ~ (p=0.604 n=20+16)
Throughput/4MB-8 14.3ms ± 1% 14.5ms ± 1% +1.53% (p=0.000 n=16+16)
Throughput/8MB-8 26.6ms ± 1% 26.8ms ± 1% +0.47% (p=0.003 n=19+18)
Throughput/16MB-8 51.0ms ± 1% 51.3ms ± 1% +0.47% (p=0.000 n=20+20)
Throughput/32MB-8 100ms ± 1% 100ms ± 1% +0.24% (p=0.033 n=20+20)
Throughput/64MB-8 197ms ± 0% 198ms ± 0% +0.56% (p=0.000 n=18+7)
The small MB runs are bimodal in both cases, probably GC pauses.
But there's clearly no general slowdown anymore.
Fixes#15713.
Change-Id: I5fc44680ba71812d24baac142bceee0e23f2e382
Reviewed-on: https://go-review.googlesource.com/23487
Reviewed-by: Ian Lance Taylor <iant@golang.org>
AVX2 variant reads next blocks while calculating current block.
Avoid reading past the end of data, by switching back to original,
for last blocks.
Fixes#15617.
Change-Id: I04fa2d83f1b47995117c77b4a3d403a7dff594d4
Reviewed-on: https://go-review.googlesource.com/23138
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Instead, decline the session and do a full handshake. The semantics of
cross-version resume are unclear, and all major client implementations
treat this as a fatal error. (This doesn't come up very much, mostly if
the client does the browser version fallback without sharding the
session cache.)
See BoringSSL's bdf5e72f50e25f0e45e825c156168766d8442dde and OpenSSL's
9e189b9dc10786c755919e6792e923c584c918a1.
Change-Id: I51ca95ac1691870dd0c148fd967739e2d4f58824
Reviewed-on: https://go-review.googlesource.com/21152
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
in root_cgo_darwin.go only certificates from the System Domain
were being used in FetchPEMRoots. This patch adds support for
getting certificates from all three domains (System, Admin,
User). Also it will only read trusted certificates from those
Keychains. Because it is possible to trust a non Root certificate,
this patch also adds a checks to see if the Subject and Issuer
name are the same.
Fixes#14514
Change-Id: Ia03936d7a61d1e24e99f31c92f9927ae48b2b494
Reviewed-on: https://go-review.googlesource.com/20351
Reviewed-by: Russ Cox <rsc@golang.org>
The fact that crypto/ecdsa.Verify didn't reject negative inputs was a
mistake on my part: I had unsigned numbers on the brain. However, it
doesn't generally cause problems. (ModInverse results in zero, which
results in x being zero, which is rejected.)
The amd64 P-256 code will crash when given a large, negative input.
This fixes both crypto/ecdsa to reject these values and also the P-256
code to ignore the sign of inputs.
Change-Id: I6370ed7ca8125e53225866f55b616a4022b818f8
Reviewed-on: https://go-review.googlesource.com/22093
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Update the doc for CreateCertificateRequest
to state that it creates a
`new certificate request`
instead of just a
`new certificate`
Fixes#14649.
Change-Id: Ibbbcf91d74168998990990e78e5272a6cf294d51
Reviewed-on: https://go-review.googlesource.com/23204
Reviewed-by: Russ Cox <rsc@golang.org>
The decryption example for AES-GCM was not executed, hiding the fact
that the provided ciphertext could not be authenticated.
This commit adds the required output comment, replaces the ciphertext
with a working example, and removes an unnecessary string conversion
along the way.
Change-Id: Ie6729ca76cf4a56c48b33fb3b39872105faa604b
Reviewed-on: https://go-review.googlesource.com/22953
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit adds the new 'ctrAble' interface to the crypto/cipher
package. The role of ctrAble is the same as gcmAble but for CTR
instead of GCM. It allows block ciphers to provide optimized CTR
implementations.
The primary benefit of adding CTR support to the s390x AES
implementation is that it allows us to encrypt the counter values
in bulk, giving the cipher message instruction a larger chunk of
data to work on per invocation.
The xorBytes assembly is necessary because xorBytes becomes a
bottleneck when CTR is done in this way. Hopefully it will be
possible to remove this once s390x has migrated to the ssa
backend.
name old speed new speed delta
AESCTR1K 160MB/s ± 6% 867MB/s ± 0% +442.42% (p=0.000 n=9+10)
Change-Id: I1ae16b0ce0e2641d2bdc7d7eabc94dd35f6e9318
Reviewed-on: https://go-review.googlesource.com/22195
Reviewed-by: Adam Langley <agl@golang.org>
This commit adds the cbcEncAble and cbcDecAble interfaces that
can be implemented by block ciphers that support an optimized
implementation of CBC. This is similar to what is done for GCM
with the gcmAble interface.
The cbcEncAble, cbcDecAble and gcmAble interfaces all now have
tests to ensure they are detected correctly in the cipher
package.
name old speed new speed delta
AESCBCEncrypt1K 152MB/s ± 1% 1362MB/s ± 0% +795.59% (p=0.000 n=10+9)
AESCBCDecrypt1K 143MB/s ± 1% 1362MB/s ± 0% +853.00% (p=0.000 n=10+9)
Change-Id: I715f686ab3686b189a3dac02f86001178fa60580
Reviewed-on: https://go-review.googlesource.com/22523
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
This change adds Config.Renegotiation which controls whether a TLS
client will accept renegotiation requests from a server. This is used,
for example, by some web servers that wish to “add” a client certificate
to an HTTPS connection.
This is disabled by default because it significantly complicates the
state machine.
Originally, handshakeMutex was taken before locking either Conn.in or
Conn.out. However, if renegotiation is permitted then a handshake may
be triggered during a Read() call. If Conn.in were unlocked before
taking handshakeMutex then a concurrent Read() call could see an
intermediate state and trigger an error. Thus handshakeMutex is now
locked after Conn.in and the handshake functions assume that Conn.in is
locked for the duration of the handshake.
Additionally, handshakeMutex used to protect Conn.out also. With the
possibility of renegotiation that's no longer viable and so
writeRecordLocked has been split off.
Fixes#5742.
Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8
Reviewed-on: https://go-review.googlesource.com/22475
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Renames block to blockGeneric so that it can be called when the
assembly feature check fails. This means making block a var on
platforms without an assembly implementation (similar to the sha1
package).
Also adds a test to check that the fallback path works correctly
when the feature check fails.
name old speed new speed delta
Hash8Bytes 6.42MB/s ± 1% 27.14MB/s ± 0% +323.01% (p=0.000 n=10+10)
Hash1K 53.9MB/s ± 0% 511.1MB/s ± 0% +847.57% (p=0.000 n=10+9)
Hash8K 57.1MB/s ± 1% 609.7MB/s ± 0% +967.04% (p=0.000 n=10+10)
Change-Id: If962b2a5c9160b3a0b76ccee53b2fd809468ed3d
Reviewed-on: https://go-review.googlesource.com/22460
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bill O'Farrell <billotosyr@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Renames block to blockGeneric so that it can be called when the
assembly feature check fails. This means making block a var on
platforms without an assembly implementation (similar to the sha1
package).
Also adds a test to check that the fallback path works correctly
when the feature check fails.
name old speed new speed delta
Hash8Bytes 7.13MB/s ± 2% 19.89MB/s ± 1% +178.82% (p=0.000 n=9+10)
Hash1K 121MB/s ± 1% 661MB/s ± 1% +444.54% (p=0.000 n=10+9)
Hash8K 137MB/s ± 0% 918MB/s ± 1% +569.29% (p=0.000 n=10+10)
Change-Id: Id65dd6e943f14eeffe39a904dc88065fc6a60179
Reviewed-on: https://go-review.googlesource.com/22402
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverses the change to this benchmark made in 9b6bf20.
Change-Id: I79ab88286c3028d3be561957140375bbc413e7ab
Reviewed-on: https://go-review.googlesource.com/22340
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Use the compute intermediate message digest (KIMD) instruction
when possible. Adds test to check fallback code path in case
KIMD is not available.
Benchmark changes:
Hash8Bytes 3.4x
Hash1K 9.3x
Hash8K 10.9x
Change-Id: Ibcd71a886dfd7b3822042235b4f4eaa7a148036b
Reviewed-on: https://go-review.googlesource.com/22350
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change improves the performance of the block
function used within crypto/md5 on ppc64le. The following
improvement was seen:
BenchmarkHash8Bytes 8.39 26.04 3.10x
BenchmarkHash1K 99.41 407.84 4.10x
BenchmarkHash8K 108.87 460.00 4.23x
BenchmarkHash8BytesUnaligned 8.39 25.80 3.08x
BenchmarkHash1KUnaligned 89.94 407.81 4.53x
BenchmarkHash8KUnaligned 96.57 459.22 4.76x
Fixes#15385
Change-Id: I8af5af089cc3e3740c33c662003d104de5fe1d1b
Reviewed-on: https://go-review.googlesource.com/22294
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Adds support for single block encryption using the cipher message
(KM) instruction. KM handles key expansion internally and
therefore it is not done up front when using the assembly
implementation on s390x.
Change-Id: I69954b8ae36d549e1dc40d7acd5a10bedfaaef9c
Reviewed-on: https://go-review.googlesource.com/22194
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bill O'Farrell <billotosyr@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There is currently only one assembly implementation of AES
(amd64). While it is possible to fit other implementations to the
same pattern it complicates the code. For example s390x does not
use expanded keys, so having enc and dec in the aesCipher struct
is confusing.
By separating out the asm implementations we can more closely
match the data structures to the underlying implementation. This
also opens the door for AES implementations that support block
cipher modes other than GCM (e.g. CTR and CBC).
This commit changes BenchmarkExpandKey to test the go
implementation of key expansion. It might be better to have some
sort of 'initialisation' benchmark instead to cover the startup
costs of the assembly implementations (which might be doing
key expansion in a different way, or not at all).
Change-Id: I094a7176b5bbe2177df73163a9c0b711a61c12d6
Reviewed-on: https://go-review.googlesource.com/22193
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The encryptBlock and decryptBlock functions are already tested
(via the public API) by TestCipherEncrypt and TestCipherDecrypt
respectively. Both sets of tests check the output of the two
functions against the same set of FIPS 197 examples. I therefore
think it is safe to delete these two tests without losing any
coverage.
Deleting these two tests will make it easier to modify the
internal API, which I am hoping to do in future CLs.
Change-Id: I0dd568bc19f47b70ab09699b507833e527d39ba7
Reviewed-on: https://go-review.googlesource.com/22115
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
cmd and runtime were handled separately, and I'm intentionally skipped
syscall. This is the rest of the standard library.
CL generated mechanically with github.com/mdempsky/unconvert.
Change-Id: I9e0eff886974dedc37adb93f602064b83e469122
Reviewed-on: https://go-review.googlesource.com/22104
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The AuthorityKeyId is optional for self-signed certificates, generally
useless, and takes up space. This change causes an AuthorityKeyId not to
be added to self-signed certificates, although it can still be set in
the template if the caller really wants to include it.
Fixes#15194.
Change-Id: If5d3c3d9ca9ae5fe67458291510ec7140829756e
Reviewed-on: https://go-review.googlesource.com/21895
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Error strings in this package were all over the place: some were
prefixed with “tls:”, some with “crypto/tls:” and some didn't have a
prefix.
This change makes everything use the prefix “tls:”.
Change-Id: Ie8b073c897764b691140412ecd6613da8c4e33a2
Reviewed-on: https://go-review.googlesource.com/21893
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Standardize on space between "RFC" and number. Additionally change
the couple "a RFC" instances to "an RFC."
Fixes#15258
Change-Id: I2b17ecd06be07dfbb4207c690f52a59ea9b04808
Reviewed-on: https://go-review.googlesource.com/21902
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Per RFC 5246, 7.4.1.3:
cipher_suite
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
The specifications are not very clearly written about resuming sessions
at the wrong version (i.e. is the TLS 1.0 notion of "session" the same
type as the TLS 1.1 notion of "session"?). But every other
implementation enforces this check and not doing so has some odd
semantics.
Change-Id: I6234708bd02b636c25139d83b0d35381167e5cad
Reviewed-on: https://go-review.googlesource.com/21153
Reviewed-by: Adam Langley <agl@golang.org>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Change-Id: I91873aaebf79bdf1c00d38aacc1a1fb8d79656a7
Reviewed-on: https://go-review.googlesource.com/21433
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This exports the system cert pool.
The system cert loading was refactored to let it be run multiple times
(so callers get a copy, and can't mutate global state), and also to
not discard errors.
SystemCertPool returns an error on Windows. Maybe it's fixable later,
but so far we haven't used it, since the system verifies TLS.
Fixes#13335
Change-Id: I3dfb4656a373f241bae8529076d24c5f532f113c
Reviewed-on: https://go-review.googlesource.com/21293
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is a change improving consistency in the source tree.
The pattern foo &= ^bar, was only used six times in src/ directory.
The usage of the supported &^ (bit clear / AND NOT) operator is way more
common, about factor 10x.
Change-Id: If26a2994fd81d23d42189bee00245eb84e672cf3
Reviewed-on: https://go-review.googlesource.com/21224
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change removes a lot of dead code. Some of the code has never been
used, not even when it was first commited. The rest shouldn't have
survived refactors.
This change doesn't remove unused routines helpful for debugging, nor
does it remove code that's used in commented out blocks of code that are
only unused temporarily. Furthermore, unused constants weren't removed
when they were part of a set of constants from specifications.
One noteworthy omission from this CL are about 1000 lines of unused code
in cmd/fix, 700 lines of which are the typechecker, which hasn't been
used ever since the pre-Go 1 fixes have been removed. I wasn't sure if
this code should stick around for future uses of cmd/fix or be culled as
well.
Change-Id: Ib714bc7e487edc11ad23ba1c3222d1fd02e4a549
Reviewed-on: https://go-review.googlesource.com/20926
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Store already padded keys instead of storing key and padding it during
Reset and Sum. This simplifies code and makes Reset-Write-Sum sequences
faster, which helps /x/crypto/pbkdf2.
HMAC benchmark:
benchmark old ns/op new ns/op delta
BenchmarkHMACSHA256_1K-4 7669 7613 -0.73%
BenchmarkHMACSHA256_32-4 1880 1737 -7.61%
benchmark old MB/s new MB/s speedup
BenchmarkHMACSHA256_1K-4 133.52 134.50 1.01x
BenchmarkHMACSHA256_32-4 17.02 18.41 1.08x
PBKDF2 benchmark:
benchmark old ns/op new ns/op delta
BenchmarkPBKDF2HMACSHA256-4 1943196 1807699 -6.97%
Change-Id: I6697028370c226715ab477b0844951a83eb3488c
Reviewed-on: https://go-review.googlesource.com/21024
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Currently, if a client of crypto/tls (e.g., net/http, http2) calls
tls.Conn.Write with a 33KB buffer, that ends up writing three TLS
records: 16KB, 16KB, and 1KB. Slow clients (such as 2G phones) must
download the first 16KB record before they can decrypt the first byte.
To improve latency, it's better to send smaller TLS records. However,
sending smaller records adds overhead (more overhead bytes and more
crypto calls), which slightly hurts throughput.
A simple heuristic, implemented in this change, is to send small
records for new connections, then boost to large records after the
first 1MB has been written on the connection.
Fixes#14376
Change-Id: Ice0f6279325be6775aa55351809f88e07dd700cd
Reviewed-on: https://go-review.googlesource.com/19591
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
This change improves the error message when encountering a TLS handshake
message that is larger than our limit (64KB). Previously the error was
just “local error: internal error”.
Updates #13401.
Change-Id: I86127112045ae33e51079e3bc047dd7386ddc71a
Reviewed-on: https://go-review.googlesource.com/20547
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
PKIX versions are off-by-one, so v1 is actually a zero on the wire, v2
is a one, and so on.
The RFC says that the version in a CRL is optional, but doesn't say what
the default is. Since v2 is the only accepted version, I had made the
default v2. However, OpenSSL considers the default to be v1. Also, if
the default is v2 and the element is optional then we'll never actually
write v2 on the wire. That's contrary to the RFC which clearly assumes
that v2 will be expressed on the wire in some cases.
Therefore, this change aligns with OpenSSL and assumes that v1 is the
default CRL version.
Fixes#13931
[1] https://tools.ietf.org/html/rfc5280#section-5.1
Change-Id: Ic0f638ebdd21981d92a99a882affebf3a77ab71a
Reviewed-on: https://go-review.googlesource.com/20544
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The default version of an X.509 certificate is v1, which is encoded on
the wire as a zero.
Fixes#13382.
Change-Id: I5fd725c3fc8b08fd978ab694a3e2d6d2a495918b
Reviewed-on: https://go-review.googlesource.com/20548
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Don't do a substring search to test for a timeout error.
Fixes#14722 (maybe)
Change-Id: I4e18c749d6fd92c084a1b0b83a805119e1ae5ff2
Reviewed-on: https://go-review.googlesource.com/20403
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Update supportsUnaligned in xor.go to be true for
GOARCH values ppc64le and ppc64. This allows the
xor of long buffers to be done on double words
(8 bytes) instead of a single byte at a time, which
significantly improves performance.
Fixes#14350
Change-Id: Iccc6b9d3df2e604a55f4c1e4890bdd3bb0d77ab0
Reviewed-on: https://go-review.googlesource.com/19519
Reviewed-by: Minux Ma <minux@golang.org>
This promotes a connection hang during TLS handshake to a proper error.
This doesn't fully address #14539 because the error reported in that
case is a write-on-socket-not-connected error, which implies that an
earlier error during connection setup is not being checked, but it is
an improvement over the current behaviour.
Updates #14539.
Change-Id: I0571a752d32d5303db48149ab448226868b19495
Reviewed-on: https://go-review.googlesource.com/19990
Reviewed-by: Adam Langley <agl@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.
Go policy has been single space after periods in comments for some time.
The copyright header template at:
https://golang.org/doc/contribute.html#copyright
also uses a single space.
Make them all consistent.
Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Named returned values should only be used on public funcs and methods
when it contributes to the documentation.
Named return values should not be used if they're only saving the
programmer a few lines of code inside the body of the function,
especially if that means there's stutter in the documentation or it
was only there so the programmer could use a naked return
statement. (Naked returns should not be used except in very small
functions)
This change is a manual audit & cleanup of public func signatures.
Signatures were not changed if:
* the func was private (wouldn't be in public godoc)
* the documentation referenced it
* the named return value was an interesting name. (i.e. it wasn't
simply stutter, repeating the name of the type)
There should be no changes in behavior. (At least: none intended)
Change-Id: I3472ef49619678fe786e5e0994bdf2d9de76d109
Reviewed-on: https://go-review.googlesource.com/20024
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is minor cleanup that reduces test output noise.
Change-Id: Ib6db4daf8cb67b7784b2d5b222fa37c7f78a6a04
Reviewed-on: https://go-review.googlesource.com/19997
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is minor cleanup that makes the tests more readable.
Change-Id: I9f1f98f0f035096c284bdf3501e7520517a3e4d9
Reviewed-on: https://go-review.googlesource.com/19993
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a followup change to #13111 for filtering out IPv6 literals and
absolute FQDNs from being as the SNI values.
Updates #13111.
Fixes#14404.
Change-Id: I09ab8d2a9153d9a92147e57ca141f2e97ddcef6e
Reviewed-on: https://go-review.googlesource.com/19704
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go already supports Linux's getrandom, which is a slightly modified
version of getentropy.
getentropy was added in OpenBSD 5.6. All supported versions of OpenBSD
include it so, unlike with Linux and getrandom, we don't need to test
for its presence.
Fixes#13785.
Change-Id: Ib536b96675f257cd8c5de1e3a36165e15c9abac9
Reviewed-on: https://go-review.googlesource.com/18219
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing documentation for ParsePKIXPublicKey is difficult to understand
and the return type of the parsed public key are not mentioned explicitly.
Descriptions about types of public key supported, as well as an example on
how to use type assertions to determine return type of a parsed public key
has been added.
Fixes#14355
Change-Id: Ib9561efb34255292735742c0b3e835c4b97ac589
Reviewed-on: https://go-review.googlesource.com/19757
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Semi-regular merge from tip to dev.ssa.
Two fixes:
1) Mark selectgo as not returning. This caused problems
because there are no VARKILL ops on the selectgo path,
causing things to be marked live that shouldn't be.
2) Tell the amd64 assembler that addressing modes like
name(SP)(AX*4) are ok.
Change-Id: I9ca81c76391b1a65cc47edc8610c70ff1a621913
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>
The iOS simulator compiles with GOOS=darwin GOARCH=386, and x509
sets the inappropriate flag -mmacosx-version-min=10.6. Condition
its compilation on the absence of an "ios" build tag.
Fixes#11736.
Change-Id: I4aa230643347320c3cb9d03b972734b2e0db930e
Reviewed-on: https://go-review.googlesource.com/12301
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
Change 7c7126cfeb removed the primality
checking in Validate to save CPU time. That check happened to be
filtering out private keys with primes that were zero or one. Without
that filtering, such primes cause a panic when trying to use such a
private key.
This change specifically checks for and rejects primes ≤ 1 in Validate.
Fixes#11233.
Change-Id: Ie6537edb8250c07a45aaf50dab43227002ee7386
Reviewed-on: https://go-review.googlesource.com/11611
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If an encrypted PEM block contained ciphertext that was not a multiple
of the block size then the code would panic. This change tests for that
case and returns an error.
Fixes#11215.
Change-Id: I7b700f99e20810c4f545519b1e9d766b4640e8a7
Reviewed-on: https://go-review.googlesource.com/11097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The previous code had a brain fart: it took one of the length prefixes
as an element count, not a length. This didn't actually affect anything
because the loop stops as soon as it finds a hostname element, and the
hostname element is always the first and only element. (No other element
types have ever been defined.)
This change fixes the parsing in case SNI is ever changed in the future.
Fixes#10793.
Change-Id: Iafdf3381942bc22b1f33595315c53dc6cc2e9f0f
Reviewed-on: https://go-review.googlesource.com/11059
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These were found by grepping the comments from the go code and feeding
the output to aspell.
Change-Id: Id734d6c8d1938ec3c36bd94a4dbbad577e3ad395
Reviewed-on: https://go-review.googlesource.com/10941
Reviewed-by: Aamir Khan <syst3m.w0rm@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
GCM is traditionally used with a 96-bit nonce, but the standard allows
for nonces of any size. Non-standard nonce sizes are required in some
protocols, so add support for them in crypto/cipher's GCM
implementation.
Change-Id: I7feca7e903eeba557dcce370412b6ffabf1207ab
Reviewed-on: https://go-review.googlesource.com/8946
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Previously we enforced both that the extended key usages of a client
certificate chain allowed for client authentication, and that the
client-auth EKU was in the leaf certificate.
This change removes the latter requirement. It's still the case that the
chain must be compatible with the client-auth EKU (i.e. that a parent
certificate isn't limited to another usage, like S/MIME), but we'll now
accept a leaf certificate with no EKUs for client-auth.
While it would be nice if all client certificates were explicit in their
intended purpose, I no longer feel that this battle is worthwhile.
Fixes#11087.
Change-Id: I777e695101cbeba069b730163533e2977f4dc1fc
Reviewed-on: https://go-review.googlesource.com/10806
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
The X.509 parser was allowing trailing data after a number of structures
in certificates and public keys. There's no obvious security issue here,
esp in certificates which are signed anyway, but this change makes
trailing data an error just in case.
Fixes#10583
Change-Id: Idc289914899600697fc6d30482227ff4bf479241
Reviewed-on: https://go-review.googlesource.com/9473
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
This is the second in a two-part change. See https://golang.org/cl/9415
for details of the overall change.
This change updates the supported signature algorithms to include
SHA-384 and updates all the testdata/ files accordingly. Even some of
the testdata/ files named “TLS1.0” and “TLS1.1” have been updated
because they have TLS 1.2 ClientHello's even though the server picks a
lower version.
Fixes#9757.
Change-Id: Ia76de2b548d3b39cd4aa3f71132b0da7c917debd
Reviewed-on: https://go-review.googlesource.com/9472
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Previously, unknown critical extensions were a parse error. However, for
some cases one wishes to parse and use a certificate that may contain
these extensions. For example, when using a certificate in a TLS server:
it's the client's concern whether it understands the critical extensions
but the server still wishes to parse SNI values out of the certificate
etc.
This change moves the rejection of unknown critical extensions from
ParseCertificate to Certificate.Verify. The former will now record the
OIDs of unknown critical extensions in the Certificate and the latter
will fail to verify certificates with them. If a user of this package
wishes to handle any unknown critical extensions themselves, they can
extract the extensions from Certificate.Extensions, process them and
remove known OIDs from Certificate.UnknownCriticalExtensions.
See discussion at
https://groups.google.com/forum/#!msg/golang-nuts/IrzoZlwalTQ/qdK1k-ogeHIJ
and in the linked bug.
Fixes#10459
Change-Id: I762521a44c01160fa0901f990ba2f5d4977d7977
Reviewed-on: https://go-review.googlesource.com/9390
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change causes the GetCertificate callback to be called if
Certificates is empty. Previously this configuration would result in an
error.
This allows people to have servers that depend entirely on dynamic
certificate selection, even when the client doesn't send SNI.
Fixes#9208.
Change-Id: I2f5a5551215958b88b154c64a114590300dfc461
Reviewed-on: https://go-review.googlesource.com/8792
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
The OCSP response is currently only exposed via a method on Conn,
which makes it inaccessible when using wrappers like net/http. The
ConnectionState structure is typically available even when using
wrappers and contains many of the other handshake details, so this
change exposes the stapled OCSP response in that structure.
Change-Id: If8dab49292566912c615d816321b4353e711f71f
Reviewed-on: https://go-review.googlesource.com/9361
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
At present, Unmarshal does not check that the point it unmarshals
is actually *on* the curve. (It may be on the curve's twist.)
This can, as Daniel Bernstein has pointed out at great length,
lead to quite devastating attacks. And 3 out of the 4 curves
supported by crypto/elliptic have twists with cofactor != 1;
P-224, in particular, has a sufficiently large cofactor that it
is likely that conventional dlog attacks might be useful.
This closes#2445, filed by Watson Ladd.
To explain why this was (partially) rejected before being accepted:
In the general case, for curves with cofactor != 1, verifying subgroup
membership is required. (This is expensive and hard-to-implement.)
But, as recent discussion during the CFRG standardization process
has brought out, small-subgroup attacks are much less damaging than
a twist attack.
Change-Id: I284042eb9954ff9b7cde80b8b693b1d468c7e1e8
Reviewed-on: https://go-review.googlesource.com/2421
Reviewed-by: Adam Langley <agl@golang.org>
This implements a method for x509.CertificateRequest to prevent
certain attacks and to allow a CA/RA to properly check the validity
of the binding between an end entity and a key pair, to prove that
it has possession of (i.e., is able to use) the private key
corresponding to the public key for which a certificate is requested.
RFC 2986 section 3 states:
"A certification authority fulfills the request by authenticating the
requesting entity and verifying the entity's signature, and, if the
request is valid, constructing an X.509 certificate from the
distinguished name and public key, the issuer name, and the
certification authority's choice of serial number, validity period,
and signature algorithm."
Change-Id: I37795c3b1dfdfdd455d870e499b63885eb9bda4f
Reviewed-on: https://go-review.googlesource.com/7371
Reviewed-by: Adam Langley <agl@golang.org>
This change adds a new method to tls.Config, SetSessionTicketKeys, that
changes the key used to encrypt session tickets while the server is
running. Additional keys may be provided that will be used to maintain
continuity while rotating keys. If a ticket encrypted with an old key is
provided by the client, the server will resume the session and provide
the client with a ticket encrypted using the new key.
Fixes#9994
Change-Id: Idbc16b10ff39616109a51ed39a6fa208faad5b4e
Reviewed-on: https://go-review.googlesource.com/9072
Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com>
Reviewed-by: Adam Langley <agl@golang.org>
This change adds support for serving and receiving Signed Certificate
Timestamps as described in RFC 6962.
The server is now capable of serving SCTs listed in the Certificate
structure. The client now asks for SCTs and, if any are received,
they are exposed in the ConnectionState structure.
Fixes#10201
Change-Id: Ib3adae98cb4f173bc85cec04d2bdd3aa0fec70bb
Reviewed-on: https://go-review.googlesource.com/8988
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com>
- Multiple GetCertificate tests shared the same name and were
overwriting each other, each test now has a unique name.
- expectAlert was not implemented in the data updater, the single
test that used it has been replaced with a ClientHello failure
test.
Fixes#10470
Change-Id: I500738f6302ffa863d7ee45d85fa8773155e0614
Reviewed-on: https://go-review.googlesource.com/8959
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Move the single file from internal/syscall to internal/syscall/unix,
to match the golang.org/x/sys layout.
Change-Id: I2fb2832b4cb22efc7666bd276f5401ac3e73dc40
Reviewed-on: https://go-review.googlesource.com/8972
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Just like darwin/arm.
Change-Id: Ib0438021bfe9eb105222b93e5bb375c282cc7b8c
Reviewed-on: https://go-review.googlesource.com/8822
Reviewed-by: Minux Ma <minux@golang.org>
This is a follow on to 28f33b4a which removes one of the boolean flags
and adds a test for the key-driven cipher selection.
Change-Id: If2a400de807eb19110352912a9f467491cc8986c
Reviewed-on: https://go-review.googlesource.com/8428
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Jacob Haven <jacob@cloudflare.com>
A CSR containing challengePassword or unstructuredName Attributes
(included in default OpenSSL prompts) would break ASN.1 parsing.
This updates the parsing structures to allow but then ignore these
fields.
See this CFSSL issue: https://github.com/cloudflare/cfssl/issues/115
Change-Id: I26a3bf1794589d27e6e763da88ae32276f0170c7
Reviewed-on: https://go-review.googlesource.com/8160
Reviewed-by: Adam Langley <agl@golang.org>
This change replaces all direct ECDSA/RSA sign and decrypt operations
with calls through the crypto.Signer and crypto.Decrypter interfaces.
This is a follow-up to https://go-review.googlesource.com/#/c/3900/
which added crypto.Decrypter and implemented it for RSA.
Change-Id: Ie0f3928448b285f329efcd3a93ca3fd5e3b3e42d
Reviewed-on: https://go-review.googlesource.com/7804
Reviewed-by: Adam Langley <agl@golang.org>
cl8167 introduced internal/syscall/windows.GetVersion, but we already
have that function in syscall.GetVersion. Use that instead.
Also revert all internal/syscall/windows cl8167 changes.
Change-Id: I512a5bf4b3b696e93aaf69e9e8b7df7022670ec0
Reviewed-on: https://go-review.googlesource.com/8302
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
Windows XP SP2 and Windows 2003 do not support SHA2.
Change-Id: Ica5faed040e9ced8b79fe78d512586e0e8788b3f
Reviewed-on: https://go-review.googlesource.com/8167
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Commit 604fa4d5 made TLS 1.0 the default minimum version. This commit
amends a comment to reflect that.
This is where the default is used in the absence of an explicit version
being set:
edadffa2f3/src/crypto/tls/common.go (L391-L393)
Change-Id: I8f1117ecdddc85bb1cc76a6834026505a380b793
Reviewed-on: https://go-review.googlesource.com/5525
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Just so that we notice in the future if another hash function is added
without updating this utility function, make it panic when passed an
unknown handshake hash function. (Which should never happen.)
Change-Id: I60a6fc01669441523d8c44e8fbe7ed435e7f04c8
Reviewed-on: https://go-review.googlesource.com/7646
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Joël Stemmer <stemmertech@gmail.com>
crypto/rand.Reader doesn't ensure that short reads don't happen. This
change contains a couple of fixups where io.ReadFull wasn't being used
with it.
Change-Id: I3855b81f5890f2e703112eeea804aeba07b6a6b8
Reviewed-on: https://go-review.googlesource.com/7645
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Commit f1d669aee9 added support for
AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it
did not take the arbitrary hash function into account in the TLS client
handshake when using client certificates.
The hashForClientCertificate method always returned SHA256 as its
hashing function, even if it actually used a different one to calculate
its digest. Setting up the connection would eventually fail with the
error "tls: failed to sign handshake with client certificate:
crypto/rsa: input must be hashed message".
Included is an additional test for this specific situation that uses the
SHA384 hash.
Fixes#9808
Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3
Reviewed-on: https://go-review.googlesource.com/7040
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Decrypter is an interface to support opaque private keys that perform
decryption operations. This interface is analogous to the crypto.Signer
interface.
This change introduces the crypto.Decrypter interface and implements
the crypto.Decrypter interface for rsa.PrivateKey with both OAEP and
PKCS#1 v1.5 padding modes.
Change-Id: I433f649f84ed3c2148337d735cafd75f1d94a904
Reviewed-on: https://go-review.googlesource.com/3900
Reviewed-by: Adam Langley <agl@golang.org>
Change-Id: I8b18dc840425b72d7172a35cb0ba004bd156492d
Reviewed-on: https://go-review.googlesource.com/6252
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Previously, we didn't handle absolute DNS names in certificates the same
way as Chromium, and we probably shouldn't diverge from major browsers.
Change-Id: I56a3962ad1002f68b5dbd65ae90991b82c2f5629
Reviewed-on: https://go-review.googlesource.com/5692
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
RFC 6125 now specifies that wildcards are only allowed for the leftmost
label in a pattern: https://tools.ietf.org/html/rfc6125#section-6.4.3.
This change updates Go to match the behaviour of major browsers in this
respect.
Fixes#9834.
Change-Id: I37c10a35177133624568f2e0cf2767533926b04a
Reviewed-on: https://go-review.googlesource.com/5691
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some servers which misunderstood the point of the CertificateRequest
message send huge reply records. These records are large enough that
they were considered “insane” by the TLS code and rejected.
This change removes the sanity test for record lengths. Although the
maxCiphertext test still remains, just above, which (roughly) enforces
the 16KB protocol limit on record sizes:
https://tools.ietf.org/html/rfc5246#section-6.2.1Fixes#8928.
Change-Id: Idf89a2561b1947325b7ddc2613dc2da638d7d1c9
Reviewed-on: https://go-review.googlesource.com/5690
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There was a missing continue that caused certificates with critical
certificate-policy extensions to be rejected. Additionally, that code
structure in general was prone to exactly that bug so I changed it
around to hopefully be more robust in the future.
Fixes#9964.
Change-Id: I58fc6ef3a84c1bd292a35b8b700f44ef312ec1c1
Reviewed-on: https://go-review.googlesource.com/5670
Reviewed-by: Andrew Gerrand <adg@golang.org>
This check is expensive and adversely impacts startup times for some
servers with several, large RSA keys.
It was nice to have, but it's not really going to stop a targetted
attack and was never designed to – hopefully people's private keys
aren't attacker controlled!
Overall I think the feeling is that people would rather have the CPU
time back.
Fixes#6626.
Change-Id: I0143a58c9f22381116d4ca2a3bbba0d28575f3e5
Reviewed-on: https://go-review.googlesource.com/5641
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
Applying my post-submit comments from CL 5120.
The rewrite there changed the code from writing to the stack
frame to writing below the stack frame.
Change-Id: Ie7e0563c0c1731fede2bcefeaf3c9d88a0cf4063
Reviewed-on: https://go-review.googlesource.com/5470
Reviewed-by: David Crawshaw <crawshaw@golang.org>
