An error occurred fetching the project authors.
- 22 Sep, 2016 1 commit
-
-
Adam Langley authored
After renegotiation support was added (af125a51) it's possible for a Write to block on a Read when racing to complete the handshake: 1. The Write determines that a handshake is needed and tries to take the neccesary locks in the correct order. 2. The Read also determines that a handshake is needed and wins the race to take the locks. 3. The Read goroutine completes the handshake and wins a race to unlock and relock c.in, which it'll hold when waiting for more network data. If the application-level protocol requires the Write to complete before data can be read then the system as a whole will deadlock. Unfortunately it doesn't appear possible to reverse the locking order of c.in and handshakeMutex because we might read a renegotiation request at any point and need to be able to do a handshake without unlocking. So this change adds a sync.Cond that indicates that a goroutine has committed to doing a handshake. Other interested goroutines can wait on that Cond when needed. The test for this isn't great. I was able to reproduce the deadlock with it only when building with -race. (Because -race happened to alter the timing just enough.) Fixes #17101. Change-Id: I4e8757f7b82a84e46c9963a977d089f0fb675495 Reviewed-on: https://go-review.googlesource.com/29164Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 11 Sep, 2016 1 commit
-
-
Filippo Valsorda authored
Since 2a8c81ff handshake messages are not written directly to wire but buffered. If an error happens at the wrong time the alert will be written to the buffer but never flushed, causing an EOF on the client instead of a more descriptive alert. Thanks to Brendan McMillion for reporting this. Fixes #17037 Change-Id: Ie093648aa3f754f4bc61c2e98c79962005dd6aa2 Reviewed-on: https://go-review.googlesource.com/28818Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 01 Sep, 2016 1 commit
-
-
Brad Fitzpatrick authored
In Go 1.0, the Config struct consisted only of exported fields. In Go 1.1, it started to grow private, uncopyable fields (sync.Once, sync.Mutex, etc). Ever since, people have been writing their own private Config.Clone methods, or risking it and doing a language-level shallow copy and copying the unexported sync variables. Clean this up and export the Config.clone method as Config.Clone. This matches the convention of Template.Clone from text/template and html/template at least. Fixes #15771 Updates #16228 (needs update in x/net/http2 before fixed) Updates #16492 (not sure whether @agl wants to do more) Change-Id: I48c2825d4fef55a75d2f99640a7079c56fce39ca Reviewed-on: https://go-review.googlesource.com/28075 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 27 Aug, 2016 1 commit
-
-
Joonas Kuorilehto authored
Add support for writing TLS client random and master secret in NSS key log format. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format Normally this is enabled by a developer debugging TLS based applications, especially HTTP/2, by setting the KeyLogWriter to an open file. The keys negotiated in handshake are then logged and can be used to decrypt TLS sessions e.g. in Wireshark. Applications may choose to add support similar to NSS where this is enabled by environment variable, but no such mechanism is built in to Go. Instead each application must explicitly enable. Fixes #13057. Change-Id: If6edd2d58999903e8390b1674ba4257ecc747ae1 Reviewed-on: https://go-review.googlesource.com/27434 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 18 Aug, 2016 2 commits
-
-
Adam Langley authored
If SetSessionTicketKeys was called on a fresh tls.Config, the configured keys would be overridden with a random key by serverInit. Fixes #15421. Change-Id: I5d6cc81fc3e5de4dfa15eb614d102fb886150d1b Reviewed-on: https://go-review.googlesource.com/27317Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Adam Langley authored
These were new with TLS 1.2 and, reportedly, some servers require it. Since it's easy, this change adds suport for three flavours of AES-128-CBC with SHA-256 MACs. Other testdata/ files have to be updated because this changes the list of cipher suites offered by default by the client. Fixes #15487. Change-Id: I1b14330c31eeda20185409a37072343552c3464f Reviewed-on: https://go-review.googlesource.com/27315 Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 27 Jun, 2016 1 commit
-
-
Ian Lance Taylor authored
This fixes some 40 warnings from go vet. Fixes #16134. Change-Id: Ib9fcba275fe692f027a2a07b581c8cf503b11087 Reviewed-on: https://go-review.googlesource.com/24287Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
- 01 Jun, 2016 1 commit
-
-
Adam Langley authored
This change causes TLS handshake messages to be buffered and written in a single Write to the underlying net.Conn. There are two reasons to want to do this: Firstly, it's slightly preferable to do this in order to save sending several, small packets over the network where a single one will do. Secondly, since 37c28759 errors from Write have been returned from a handshake. This means that, if a peer closes the connection during a handshake, a “broken pipe” error may result from tls.Conn.Handshake(). This can mask any, more detailed, fatal alerts that the peer may have sent because a read will never happen. Buffering handshake messages means that the peer will not receive, and possibly reject, any of a flow while it's still being written. Fixes #15709 Change-Id: I38dcff1abecc06e52b2de647ea98713ce0fb9a21 Reviewed-on: https://go-review.googlesource.com/23609Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Andrew Gerrand <adg@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 28 Apr, 2016 1 commit
-
-
Adam Langley authored
This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes #5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
- 02 Mar, 2016 1 commit
-
-
Tamir Duberstein authored
This promotes a connection hang during TLS handshake to a proper error. This doesn't fully address #14539 because the error reported in that case is a write-on-socket-not-connected error, which implies that an earlier error during connection setup is not being checked, but it is an improvement over the current behaviour. Updates #14539. Change-Id: I0571a752d32d5303db48149ab448226868b19495 Reviewed-on: https://go-review.googlesource.com/19990Reviewed-by: Adam Langley <agl@golang.org>
-
- 27 Feb, 2016 1 commit
-
-
Mikio Hara authored
This is a followup change to #13111 for filtering out IPv6 literals and absolute FQDNs from being as the SNI values. Updates #13111. Fixes #14404. Change-Id: I09ab8d2a9153d9a92147e57ca141f2e97ddcef6e Reviewed-on: https://go-review.googlesource.com/19704Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 24 Feb, 2016 1 commit
-
-
Martin Möhrmann authored
Change-Id: Icd06d99c42b8299fd931c7da821e1f418684d913 Reviewed-on: https://go-review.googlesource.com/19829Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 26 Nov, 2015 1 commit
-
-
Ralph Corderoy authored
During the TLS handshake, check the cipher suite the server selects is one of those offered in the ClientHello. The code was checking it was in the larger list that was sometimes whittled down for the ClientHello. Fixes #13174 Change-Id: Iad8eebbcfa5027f30403b9700c43cfa949e135bb Reviewed-on: https://go-review.googlesource.com/16698Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
- 15 Nov, 2015 1 commit
-
-
Shenghou Ma authored
Fixes #9894. Change-Id: I9c7ce771df2e2d1c99a06f800dce63c4e1875993 Reviewed-on: https://go-review.googlesource.com/16924 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
- 10 Nov, 2015 1 commit
-
-
Adam Langley authored
(This relands commit a4dcc692.) https://tools.ietf.org/html/rfc6066#section-3 states: “Literal IPv4 and IPv6 addresses are not permitted in "HostName".” However, if an IP literal was set as Config.ServerName (which could happen as easily as calling Dial with an IP address) then the code would send the IP literal as the SNI value. This change filters out IP literals, as recognised by net.ParseIP, from being sent as the SNI value. Fixes #13111. Change-Id: I6e544a78a01388f8fe98150589d073b917087f75 Reviewed-on: https://go-review.googlesource.com/16776 Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 09 Nov, 2015 2 commits
-
-
Adam Langley authored
This reverts commit a4dcc692. Change-Id: Ib55fd349a604d6b5220dac20327501e1ce46b962 Reviewed-on: https://go-review.googlesource.com/16770Reviewed-by: Adam Langley <agl@golang.org>
-
Adam Langley authored
https://tools.ietf.org/html/rfc6066#section-3 states: “Literal IPv4 and IPv6 addresses are not permitted in "HostName".” However, if an IP literal was set as Config.ServerName (which could happen as easily as calling Dial with an IP address) then the code would send the IP literal as the SNI value. This change filters out IP literals, as recognised by net.ParseIP, from being sent as the SNI value. Fixes #13111. Change-Id: Ie9ec7acc767ae172b48c9c6dd8d84fa27b1cf0de Reviewed-on: https://go-review.googlesource.com/16742Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
-
- 05 Aug, 2015 1 commit
-
-
Russ Cox authored
Strengthening VerifyHostname exposed the fact that for resumed connections, ConnectionState().VerifiedChains was not being saved and restored during the ClientSessionCache operations. Do that. This change just saves the verified chains in the client's session cache. It does not re-verify the certificates when resuming a connection. There are arguments both ways about this: we want fast, light-weight resumption connections (thus suggesting that we shouldn't verify) but it could also be a little surprising that, if the verification config is changed, that would be ignored if the same session cache is used. On the server side we do re-verify client-auth certificates, but the situation is a little different there. The client session cache is an object in memory that's reset each time the process restarts. But the server's session cache is a conceptual object, held by the clients, so can persist across server restarts. Thus the chance of a change in verification config being surprisingly ignored is much higher in the server case. Fixes #12024. Change-Id: I3081029623322ce3d9f4f3819659fdd9a381db16 Reviewed-on: https://go-review.googlesource.com/13164Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
- 26 Apr, 2015 2 commits
-
-
Jonathan Rudenberg authored
This change adds a new method to tls.Config, SetSessionTicketKeys, that changes the key used to encrypt session tickets while the server is running. Additional keys may be provided that will be used to maintain continuity while rotating keys. If a ticket encrypted with an old key is provided by the client, the server will resume the session and provide the client with a ticket encrypted using the new key. Fixes #9994 Change-Id: Idbc16b10ff39616109a51ed39a6fa208faad5b4e Reviewed-on: https://go-review.googlesource.com/9072Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com> Reviewed-by: Adam Langley <agl@golang.org>
-
Jonathan Rudenberg authored
This change adds support for serving and receiving Signed Certificate Timestamps as described in RFC 6962. The server is now capable of serving SCTs listed in the Certificate structure. The client now asks for SCTs and, if any are received, they are exposed in the ConnectionState structure. Fixes #10201 Change-Id: Ib3adae98cb4f173bc85cec04d2bdd3aa0fec70bb Reviewed-on: https://go-review.googlesource.com/8988Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com>
-
- 16 Mar, 2015 1 commit
-
-
Joël Stemmer authored
Commit f1d669ae added support for AES_256_GCM_SHA384 cipher suites as specified in RFC5289. However, it did not take the arbitrary hash function into account in the TLS client handshake when using client certificates. The hashForClientCertificate method always returned SHA256 as its hashing function, even if it actually used a different one to calculate its digest. Setting up the connection would eventually fail with the error "tls: failed to sign handshake with client certificate: crypto/rsa: input must be hashed message". Included is an additional test for this specific situation that uses the SHA384 hash. Fixes #9808 Change-Id: Iccbf4ab225633471ef897907c208ad31f92855a3 Reviewed-on: https://go-review.googlesource.com/7040Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org>
-
- 04 Feb, 2015 1 commit
-
-
Jacob H. Haven authored
Generalizes PRF calculation for TLS 1.2 to support arbitrary hashes (SHA-384 instead of SHA-256). Testdata were all updated to correspond with the new cipher suites in the handshake. Change-Id: I3d9fc48c19d1043899e38255a53c80dc952ee08f Reviewed-on: https://go-review.googlesource.com/3265Reviewed-by: Adam Langley <agl@golang.org>
-
- 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.
-
- 07 Sep, 2014 1 commit
-
-
Russ Cox authored
Maybe will help us understand Solaris build failure. TBR=aram CC=golang-codereviews https://golang.org/cl/139290043
-
- 05 Aug, 2014 1 commit
-
-
Adam Langley authored
Fixes #6736. LGTM=mikioh.mikioh R=bradfitz, mikioh.mikioh CC=golang-codereviews https://golang.org/cl/108710046
-
- 22 Jan, 2014 1 commit
-
-
Gautham Thambidorai authored
Adam (agl@) had already done an initial review of this CL in a branch. Added ClientSessionState to Config which now allows clients to keep state required to resume a TLS session with a server. A client handshake will try and use the SessionTicket/MasterSecret in this cached state if the server acknowledged resumption. We also added support to cache ClientSessionState object in Config that will be looked up by server remote address during the handshake. R=golang-codereviews, agl, rsc, agl, agl, bradfitz, mikioh.mikioh CC=golang-codereviews https://golang.org/cl/15680043
-
- 20 Dec, 2013 1 commit
-
-
Adam Langley authored
The practice of storing reference connections for testing has worked reasonably well, but the large blocks of literal data in the .go files is ugly and updating the tests is a real problem because their number has grown. This CL changes the way that reference tests work. It's now possible to automatically update the tests and the test data is now stored in testdata/. This should make it easier to implement changes that affect all connections, like implementing the renegotiation extension. R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/42060044
-
- 21 Oct, 2013 1 commit
-
-
Adam Langley authored
Despite SHA256 support being required for TLS 1.2 handshakes, some servers are aborting handshakes that don't offer SHA1 support. This change adds support for signing TLS 1.2 ServerKeyExchange messages with SHA1. It does not add support for signing TLS 1.2 client certificates with SHA1 as that would require the handshake to be buffered. Fixes #6618. R=golang-dev, r CC=golang-dev https://golang.org/cl/15650043
-
- 16 Sep, 2013 1 commit
-
-
Adam Langley authored
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
-
- 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
-
- 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
-
- 29 May, 2013 1 commit
-
-
John Shahid authored
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
-
- 16 May, 2013 1 commit
-
-
Adam Langley authored
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
-
- 15 May, 2013 1 commit
-
-
Adam Langley authored
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
-
- 26 Nov, 2012 1 commit
-
-
Anthony Martin authored
This requires rebasing the block-mode test scripts. I used GnuTLS version 3.1.4. R=agl CC=golang-dev https://golang.org/cl/6844073
-
- 16 Oct, 2012 1 commit
-
-
Adam Langley authored
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
-
- 11 Apr, 2012 1 commit
-
-
Adam Langley authored
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
-
- 13 Feb, 2012 1 commit
-
-
Shenghou Ma authored
R=golang-dev, rsc CC=golang-dev https://golang.org/cl/5645099
-
- 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
-