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
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
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
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
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
The following ciphersuites are added:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
This change helps conform to the TLS1.1 standard because
the first ciphersuite is "mandatory" in RFC4346
R=golang-dev, agl, rsc
CC=golang-dev
https://golang.org/cl/5164042
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 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
