AES-GCM cipher suites are only defined for TLS 1.2, although there's
nothing really version specific about them. However, development
versions of NSS (meaning Firefox and Chrome) have an issue where
they'll advertise TLS 1.2-only cipher suites in a TLS 1.1 ClientHello
but then balk when the server selects one.
This change causes Go clients not to advertise TLS 1.2 cipher suites
unless TLS 1.2 is being used, and prevents servers from selecting them
unless TLS 1.2 has been negotiated.
https://code.google.com/p/chromium/issues/detail?id=297151https://bugzilla.mozilla.org/show_bug.cgi?id=919677
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/13573047
47ec7a68b1a2 added support for ECDSA ciphersuites but didn't alter the
cipher suite selection to take that into account. Thus Go servers could
try and select an ECDSA cipher suite while only having an RSA
certificate, leading to connection failures.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/13239053
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
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
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
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
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
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
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
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
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
Fix incorrect marshal/unmarshal of certificateRequest.
Add support for configuring client-auth on the server side.
Fix the certificate selection in the client side.
Update generate_cert.go to new time package
Fixes#2521.
R=krautz, agl, bradfitz
CC=golang-dev, mikkel
https://golang.org/cl/5448093
The code in hash functions themselves could write directly into the
output buffer for a savings of about 50ns. But it's a little ugly so I
wasted a copy.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5440111
This is the result of running `gofix -r hashsum` over the tree, changing
the hash function implementations by hand and then fixing a couple of
instances where gofix didn't catch something.
The changed implementations are as simple as possible while still
working: I'm not trying to optimise in this CL.
R=rsc, cw, rogpeppe
CC=golang-dev
https://golang.org/cl/5448065
Previously we were using the map iteration order to set the order of
the cipher suites in the ClientHello.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5440048
With this in place, a TLS server is capable of selecting the correct
certificate based on the client's ServerNameIndication extension.
The need to call Config.BuildNameToCertificate is unfortunate, but
adding a sync.Once to the Config structure made it uncopyable and I
felt that was too high a price to pay. Parsing the leaf certificates
in each handshake was too inefficient to consider.
R=bradfitz, rsc
CC=golang-dev
https://golang.org/cl/5151048
It would be nice not to have to support this since all the clients
that we care about support TLSv1 by now. However, due to buggy
implementations of SSLv3 on the Internet which can't do version
negotiation correctly, browsers will sometimes switch to SSLv3. Since
there's no good way for a browser tell a network problem from a buggy
server, this downgrade can occur even if the server in question is
actually working correctly.
So we need to support SSLv3 for robustness :(
Fixes#1703.
R=bradfitz
CC=golang-dev
https://golang.org/cl/5018045
This is a core API change.
1) gofix misc src
2) Manual adjustments to the following files under src/pkg:
gob/decode.go
rpc/client.go
os/error.go
io/io.go
bufio/bufio.go
http/request.go
websocket/client.go
as well as:
src/cmd/gofix/testdata/*.go.in (reverted)
test/fixedbugs/bug243.go
3) Implemented gofix patch (oserrorstring.go) and test case (oserrorstring_test.go)
Compiles and runs all tests.
R=r, rsc, gri
CC=golang-dev
https://golang.org/cl/4607052
We already had support on the client side. I also changed the name of
the flag in the ServerHello structure to match the name of the same
flag in the ClientHello (ocspStapling).
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4408044
Previously, the outer loop would continue until we selected the
client's least preferable ciphersuite.
R=golang-dev, r2
CC=golang-dev
https://golang.org/cl/4029056
The crypto package is added as a common place to store identifiers for
hash functions. At the moment, the rsa package has an enumeration of
hash functions and knowledge of their digest lengths. This is an
unfortunate coupling and other high level crypto packages tend to need
to duplicate this enumeration and knowledge (i.e. openpgp).
crypto pulls this code out into a common location.
It would also make sense to add similar support for ciphers to crypto,
but the problem there isn't as acute that isn't done in this change.
R=bradfitzgo, r, rsc
CC=golang-dev
https://golang.org/cl/4080046
This is largely based on ality's CL 2747042.
crypto/rc4: API break in order to conform to crypto/cipher's
Stream interface
cipher/cipher: promote to the default build
Since CBC differs between TLS 1.0 and 1.1, we downgrade and
support only 1.0 at the current time. 1.0 is what most of the
world uses.
Given this CL, it would be trival to add support for AES 256,
SHA 256 etc, but I haven't in order to keep the change smaller.
R=rsc
CC=ality, golang-dev
https://golang.org/cl/3659041
This changeset implements client certificate support in crypto/tls
for both handshake_server.go and handshake_client.go
The updated server implementation sends an empty CertificateAuthorities
field in the CertificateRequest, thus allowing clients to send any
certificates they wish. Likewise, the client code will only respond
with its certificate when the server requests a certificate with this
field empty.
R=agl, rsc, agl1
CC=golang-dev
https://golang.org/cl/1975042
parsing and printing to new syntax.
Use -oldparser to parse the old syntax,
use -oldprinter to print the old syntax.
2) Change default gofmt formatting settings
to use tabs for indentation only and to use
spaces for alignment. This will make the code
alignment insensitive to an editor's tabwidth.
Use -spaces=false to use tabs for alignment.
3) Manually changed src/exp/parser/parser_test.go
so that it doesn't try to parse the parser's
source files using the old syntax (they have
new syntax now).
4) gofmt -w src misc test/bench
1st set of files.
R=rsc
CC=agl, golang-dev, iant, ken2, r
https://golang.org/cl/180047
(With hindsight, record_process might have been designed wrong, but it
works for now. It'll get redrawn when client support is added.)
R=rsc
CC=r
http://go/go-review/1018032