An error occurred fetching the project authors.
- 08 Sep, 2014 1 commit
-
-
Russ Cox authored
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg.
-
- 26 Sep, 2013 1 commit
-
-
Adam Langley authored
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=297151 https://bugzilla.mozilla.org/show_bug.cgi?id=919677 R=golang-dev, rsc CC=golang-dev https://golang.org/cl/13573047
-
- 17 Sep, 2013 1 commit
-
-
Adam Langley authored
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
-
- 29 Aug, 2013 1 commit
-
-
Adam Langley authored
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
-
- 17 Jul, 2013 1 commit
-
-
Joel Sing authored
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
-
- 02 Jul, 2013 1 commit
-
-
Adam Langley authored
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
-
- 19 Jun, 2013 1 commit
-
-
Adam Langley authored
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
-
- 05 Jun, 2013 1 commit
-
-
Adam Langley authored
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
-
- 18 May, 2012 1 commit
-
-
Benjamin Black authored
R=golang-dev, rsc, agl CC=golang-dev https://golang.org/cl/6188061
-
- 12 Apr, 2012 1 commit
-
-
Adam Langley authored
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
-
- 19 Jan, 2012 1 commit
-
-
Luit van Drongelen authored
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
-
- 06 Dec, 2011 1 commit
-
-
Adam Langley authored
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
-
- 02 Dec, 2011 1 commit
-
-
Russ Cox authored
R=golang-dev, bradfitz, gri CC=golang-dev https://golang.org/cl/5451079
-
- 01 Dec, 2011 1 commit
-
-
Adam Langley authored
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
-
- 28 Nov, 2011 1 commit
-
-
Adam Langley authored
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
-
- 02 Nov, 2011 1 commit
-
-
Russ Cox authored
R=golang-dev, iant CC=golang-dev https://golang.org/cl/5322051
-
- 11 Oct, 2011 1 commit
-
-
Louis Kruger authored
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
-
- 14 Sep, 2011 1 commit
-
-
Adam Langley authored
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
-
- 16 Dec, 2010 1 commit
-
-
Adam Langley authored
(ECDHE is "Elliptic Curve Diffie Hellman Ephemeral") R=rsc CC=golang-dev https://golang.org/cl/3668042
-
- 15 Dec, 2010 2 commits
-
-
Adam Langley authored
R=rsc CC=golang-dev https://golang.org/cl/3685041
-
Adam Langley authored
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
-