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
The unexported version returns a sensible default when the user hasn't
set a value. The exported version crashes in that case.
R=bradfitzgo, rsc1
CC=golang-dev
https://golang.org/cl/4435070
People have a need to verify certificates in situations other than TLS
client handshaking. Thus this CL moves certificate verification into
x509 and expands its abilities.
R=bradfitzgo
CC=golang-dev
https://golang.org/cl/4407046
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
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
Previously we checked the certificate chain from the leaf
upwards and expected to jump from the last cert in the chain to
a root certificate.
Although technically correct, there are a number of sites with
problems including out-of-order certs, superfluous certs and
missing certs.
The last of these requires AIA chasing, which is a lot of
complexity. However, we can address the more common cases by
using a pool building algorithm, as browsers do.
We build a pool of root certificates and a pool from the
server's chain. We then try to build a path to a root
certificate, using either of these pools.
This differs from the behaviour of, say, Firefox in that Firefox
will accumulate intermedite certificate in a persistent pool in
the hope that it can use them to fill in gaps in future chains.
We don't do that because it leads to confusing errors which only
occur based on the order to sites visited.
This change also enabled SNI for tls.Dial so that sites will return
the correct certificate chain.
R=rsc
CC=golang-dev
https://golang.org/cl/2916041
The key/value format of X.500 names means that it's possible to encode
a name with multiple values for, say, organisation. RFC5280
doesn't seem to consider this, but there are Verisign root
certificates which do this and, in order to find the correct
root certificate in some cases, we need to handle it.
Also, CA certificates should set the CA flag and we now check
this. After looking at the other X.509 extensions it appears
that they are universally ignored/bit rotted away so we ignore
them.
R=rsc
CC=golang-dev
https://golang.org/cl/2249042
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
SNI (Server Name Indication) is a way for a TLS client to
indicate to the server which name it knows the server by. This
allows the server to have several names and return the correct
certificate for each (virtual hosting).
PeerCertificates returns the list of certificates presented by
server.
R=r
CC=golang-dev
https://golang.org/cl/1741053
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
