An error occurred fetching the project authors.
  1. 22 Sep, 2016 1 commit
    • Adam Langley's avatar
      crypto/tls: fix deadlock when racing to complete handshake. · 254169d7
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      254169d7
  2. 11 Sep, 2016 1 commit
  3. 01 Sep, 2016 1 commit
    • Brad Fitzpatrick's avatar
      crypto/tls: add Config.Clone · d24f446a
      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: default avatarAndrew Gerrand <adg@golang.org>
      d24f446a
  4. 27 Aug, 2016 1 commit
  5. 18 Aug, 2016 2 commits
  6. 27 Jun, 2016 1 commit
  7. 01 Jun, 2016 1 commit
    • Adam Langley's avatar
      crypto/tls: buffer handshake messages. · 2a8c81ff
      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: default avatarAndrew Gerrand <adg@golang.org>
      Run-TryBot: Andrew Gerrand <adg@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      2a8c81ff
  8. 28 Apr, 2016 1 commit
    • Adam Langley's avatar
      crypto/tls: allow renegotiation to be handled by a client. · af125a51
      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: default avatarRuss Cox <rsc@golang.org>
      af125a51
  9. 02 Mar, 2016 1 commit
  10. 27 Feb, 2016 1 commit
  11. 24 Feb, 2016 1 commit
  12. 26 Nov, 2015 1 commit
  13. 15 Nov, 2015 1 commit
  14. 10 Nov, 2015 1 commit
  15. 09 Nov, 2015 2 commits
  16. 05 Aug, 2015 1 commit
    • Russ Cox's avatar
      crypto/tls: fix ConnectionState().VerifiedChains for resumed connection · 46a29138
      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: default avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: default avatarAdam Langley <agl@golang.org>
      46a29138
  17. 26 Apr, 2015 2 commits
  18. 16 Mar, 2015 1 commit
    • Joël Stemmer's avatar
      crypto/tls: return correct hash function when using client certificates in handshake · ebe3d693
      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: default avatarAdam Langley <agl@golang.org>
      Run-TryBot: Adam Langley <agl@golang.org>
      ebe3d693
  19. 04 Feb, 2015 1 commit
  20. 08 Sep, 2014 1 commit
  21. 07 Sep, 2014 1 commit
  22. 05 Aug, 2014 1 commit
  23. 22 Jan, 2014 1 commit
    • Gautham Thambidorai's avatar
      crypto/tls: Client side support for TLS session resumption. · 988ffc0f
      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
      988ffc0f
  24. 20 Dec, 2013 1 commit
    • Adam Langley's avatar
      crypto/tls: rework reference tests. · 6f149492
      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
      6f149492
  25. 21 Oct, 2013 1 commit
    • Adam Langley's avatar
      crypto/tls: advertise support for RSA+SHA1 in TLS 1.2 handshake. · efed6f99
      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
      efed6f99
  26. 16 Sep, 2013 1 commit
  27. 17 Jul, 2013 1 commit
  28. 02 Jul, 2013 1 commit
  29. 05 Jun, 2013 1 commit
  30. 29 May, 2013 1 commit
    • John Shahid's avatar
      crypto/tls: Check all certificates in the path. · ca986a2c
      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
      ca986a2c
  31. 16 May, 2013 1 commit
  32. 15 May, 2013 1 commit
    • Adam Langley's avatar
      crypto/tls: ignore empty TLS records. · a1dbfee1
      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
      a1dbfee1
  33. 26 Nov, 2012 1 commit
  34. 16 Oct, 2012 1 commit
  35. 11 Apr, 2012 1 commit
    • Adam Langley's avatar
      crypto/tls: update how we create testing scripts. · 7247dcab
      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
      7247dcab
  36. 13 Feb, 2012 1 commit
  37. 14 Sep, 2011 1 commit
    • Adam Langley's avatar
      crypto/tls: support SSLv3 · a775fbf8
      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
      a775fbf8