With TLS 1.2, when sending client certificates the code was omitting
the new (in TLS 1.2) signature and hash fields.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/13413050
AES-GCM is the only current TLS ciphersuite that doesn't have
cryptographic weaknesses (RC4), nor major construction issues (CBC mode
ciphers) and has some deployment (i.e. not-CCM).
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13249044
Add support for ECDHE-ECDSA (RFC4492), which uses an ephemeral server
key pair to perform ECDH with ECDSA signatures. Like ECDHE-RSA,
ECDHE-ECDSA also provides PFS.
R=agl
CC=golang-dev
https://golang.org/cl/7006047
This does not include AES-GCM yet. Also, it assumes that the handshake and
certificate signature hash are always SHA-256, which is true of the ciphersuites
that we currently support.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10762044
Also use 2048-bit RSA keys as default in generate_cert.go,
as recommended by the NIST.
R=golang-dev, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/10676043
TLS clients send ciphersuites in preference order (most prefereable
first). This change alters the order so that ECDHE comes before plain
RSA, and RC4 comes before AES (because of the Lucky13 attack).
This is unlikely to have much effect: as a server, the code uses the
client's ciphersuite order by default and, as a client, the non-Go
server probably imposes its order.
R=golang-dev, r, raggi, jsing
CC=golang-dev
https://golang.org/cl/10372045
The significant change between TLS 1.0 and 1.1 is the addition of an explicit IV in the case of CBC encrypted records. Support for TLS 1.1 is needed in order to support TLS 1.2.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7880043
Currently we only check the leaf node's issuer against the list of
distinguished names in the server's CertificateRequest message. This
will fail if the client certiciate has more than one certificate in
the path and the leaf node issuer isn't in the list of distinguished
names, but the issuer's issuer was in the distinguished names.
R=agl, agl
CC=gobot, golang-dev
https://golang.org/cl/9795043
This isn't clearly a bug on Go's part, but it triggers a bug in Firefox
which means that crypto/tls and net/http cannot be wired up together
unless NextProtos includes "http/1.1". When net/http sets up the
tls.Config, it does this and so works fine. But anyone setting up the
tls.Config themselves will hit the Firefox bug.
Fixes#5445.
R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/9539045
A test added in b37d2fdcc4d9 didn't work with some values of GOMAXPROCS
because the defer statements were in the wrong order: the Pipe could be
closed before the TLS Client was.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/9187047
OpenSSL can be configured to send empty records in order to randomise
the CBC IV. This is an early version of 1/n-1 record splitting (that Go
does) and is quite reasonable, but it results in tls.Conn.Read
returning (0, nil).
This change ignores up to 100 consecutive, empty records to avoid
returning (0, nil) to callers.
Fixes 5309.
R=golang-dev, r, minux.ma
CC=golang-dev
https://golang.org/cl/8852044
Subject Alternative Names in X.509 certificates may include IP
addresses. This change adds support for marshaling, unmarshaling and
verifying this form of SAN.
It also causes IP addresses to only be checked against IP SANs,
rather than against hostnames as was previously the case. This
reflects RFC 6125.
Fixes#4658.
R=golang-dev, mikioh.mikioh, bradfitz
CC=golang-dev
https://golang.org/cl/7336046
Previously, Go TLS servers always took the client's preferences into
account when selecting a ciphersuite. This change adds the option of
using the server's preferences, which can be expressed by setting
tls.Config.CipherSuites.
This mirrors Apache's SSLHonorCipherOrder directive.
R=golang-dev, nightlyone, bradfitz, ality
CC=golang-dev
https://golang.org/cl/7163043
Add support for loading X.509 key pairs that consist of a certificate
with an EC public key and its corresponding EC private key.
R=agl
CC=golang-dev
https://golang.org/cl/6776043
The RFC doesn't actually have an opinion on whether this is a fatal or
warning level alert, but common practice suggests that it should be a
warning.
This involves rebasing most of the tests.
Fixes#3413.
R=golang-dev, shanemhansen, rsc
CC=golang-dev
https://golang.org/cl/6654050
I typoed the code and tried to parse all the way to the end of the
message. Therefore it fails when NPN is not the last extension in the
ServerHello.
Fixes#4088.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6637052
Session resumption saves a round trip and removes the need to perform
the public-key operations of a TLS handshake when both the client and
server support it (which is true of Firefox and Chrome, at least).
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6555051
X509KeyPair wasn't really supposed to allow the certificate and
key to be in the same file, but it did work if you put the key
first. Since some HTTPS servers support loading keys and certs
like this, this change makes it work in either order.
Fixes#3986.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6499103
Fixes#3862.
There were many areas where conn.err was being accessed
outside the mutex. This proposal moves the err value to
an embedded struct to make it more obvious when the error
value is being accessed.
As there are no Benchmark tests in this package I cannot
feel confident of the impact of this additional locking,
although most will be uncontended.
R=dvyukov, agl
CC=golang-dev
https://golang.org/cl/6497070
If we aren't explicit about the KeyUsages, the verifier
will treat the certificate as a server certificate and require
it to have a ExtKeyUsageServerAuth key usage.
R=golang-dev
CC=golang-dev
https://golang.org/cl/6453148
This removes some (non-short only) tests that involved connections to
the outside world and thus were flakey. This does remove some test
coverage of the root fetchers on non-Windows platforms, but the right
place for that is crypto/x509.
R=golang-dev, krautz, rsc
CC=golang-dev
https://golang.org/cl/6455085
When SNI based certificate selection is enabled, we previously used
the default private key even if we selected a non-default certificate.
Fixes#3367.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5987058
crypto/tls is tested, in part, by replaying recorded TLS connections
and checking that the bytes sent by the Go code haven't changed.
Previously we used GnuTLS's debug output and extracted the bytes of
the TLS connection using a Python script. That wasn't great, and I
think GnuTLS removed that level of debugging in a more current
release.
This change records the connection with Go code and adds a test for
ECDHE-AES clients generating using this method.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5988048
The existing code that tried to prevent ECC ciphersuites from being
selected when there were no mutual curves still left |suite| set.
This lead to a panic on a nil pointer when there were no acceptable
ciphersuites at all.
Thanks to George Kadianakis for pointing it out.
R=golang-dev, r, bradfitz
CC=golang-dev
https://golang.org/cl/5857043
If a CertificateRequest is received we have to reply with a
Certificate message, even if we don't have a certificate to offer.
Fixes#3339.
R=golang-dev, r, ality
CC=golang-dev
https://golang.org/cl/5845067
This moves the various CA root fetchers from crypto/tls into crypto/x509.
The move was brought about by issue 2997. Windows doesn't ship with all
its root certificates, but will instead download them as-needed when using
CryptoAPI for certificate verification.
This CL changes crypto/x509 to verify a certificate using the system root
CAs when VerifyOptions.RootCAs == nil. On Windows, this verification is
now implemented using Windows's CryptoAPI. All other root fetchers are
unchanged, and still use Go's own verification code.
The CL also fixes the hostname matching logic in crypto/tls/tls.go, in
order to be able to test whether hostname mismatches are honored by the
Windows verification code.
The move to crypto/x509 also allows other packages to use the OS-provided
root certificates, instead of hiding them inside the crypto/tls package.
Fixes#2997.
R=agl, golang-dev, alex.brainman, rsc, mikkel
CC=golang-dev
https://golang.org/cl/5700087
Not a Go 1 issue, but appeared to be fairly easy to fix.
- Note that a few existing test cases look slightly worse but
those cases were not representative for real code. All real
code looks better now.
- Manual move of the comment in go/scanner/example_test.go
before applying gofmt.
- gofmt -w $GOROOT/src $GOROOT/misc
Fixes#3062.
R=rsc
CC=golang-dev
https://golang.org/cl/5674093
* add -work option to save temporary files (Fixes issue 2980)
* fix go test -i to work with cgo packages (Fixes issue 2936)
* do not overwrite/remove empty directories or non-object
files during build (Fixes issue 2829)
* remove package main vs package non-main heuristic:
a directory must contain only one package (Fixes issue 2864)
* to make last item workable, ignore +build tags for files
named on command line: go build x.go builds x.go even
if it says // +build ignore.
* add // +build ignore tags to helper programs
R=golang-dev, r, r
CC=golang-dev
https://golang.org/cl/5674043
1) Remove the Reset() member in crypto/aes and crypto/des (and
document the change).
2) Turn several empty error structures into vars. Any remaining error
structures are either non-empty, or will probably become so in the
future.
3) Implement SetWriteDeadline for TLS sockets. At the moment, the TLS
status cannot be reused after a Write error, which is probably fine
for most uses.
4) Make crypto/aes and crypto/des return a cipher.Block.
R=rsc, r
CC=golang-dev
https://golang.org/cl/5625045
We support SSLv3 as a server but not as a client (and we don't want to
support it as a client). This change fixes the error message when
connecting to an SSLv3 server since SSLv3 support on the server side
made mutualVersion accept SSLv3.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5545073
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
This lets the client of go/build specify additional tags that
can be recognized in a // +build directive. For example,
a build for a custom environment like App Engine might
include "appengine" in the BuildTags list, so that packages
can be written with some files saying
// +build appengine (build only on app engine)
or
// +build !appengine (build only when NOT on app engine)
App Engine here is just a hypothetical context. I plan to use
this in the cmd/go sources to distinguish the bootstrap version
of cmd/go (which will not use networking) from the full version
using a custom tag. It might also be useful in App Engine.
Also, delete Build and Script, which we did not end up using for
cmd/go and which never got turned on for real in goinstall.
R=r, adg
CC=golang-dev
https://golang.org/cl/5554079
Remove NewMD5, NewSHA1 and NewSHA256 in favor of using New and
explicitly importing the used hash-function. This way when using, for
example, HMAC with RIPEMD there's no md5, sha1 and sha256 linked in
through the hmac package.
A gofix rule is included, and applied to the standard library (3 files
altered).
This change is the result of a discussion at
https://golang.org/cl/5550043/ to pull the discussion about
deprecating these functions out of that issue.
R=golang-dev, agl
CC=golang-dev, r, rsc
https://golang.org/cl/5556058
(Sending to r because of the API change.)
This change alters the API for crypto/elliptic to permit different
implementations in the future. This will allow us to add faster,
constant-time implementations of the standard curves without any more
API changes.
As a demonstration, it also adds a constant-time implementation of
P224. Since it's only 32-bit, it's actually only about 40% the speed
of the generic code on a 64-bit system.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5528088
Previously, a timeout (in int64 nanoseconds) applied to a granularity
even smaller than one operation: a 100 byte read with a 1 second timeout
could take 100 seconds, if the bytes all arrived on the network 1 second
apart. This was confusing.
Rather than making the timeout granularity be per-Read/Write,
this CL makes callers set an absolute deadline (in time.Time)
after which operations will fail. This makes it possible to
set deadlines at higher levels, without knowing exactly how
many read/write operations will happen in e.g. reading an HTTP
request.
Fixes#2723
R=r, rsc, dave
CC=golang-dev
https://golang.org/cl/5555048
