TLS connections that timeout during handshake will leak

[jsha]

In the VA, we create our own TCP connection, then ask the crypto/tls package to do a handshake over it:

boulder/va/va.go

Lines 659 to 663 in 3bb0657

	conn := tls.Client(netConn, config)
	errChan := make(chan error)
	go func() {
	errChan <- conn.Handshake()
	}()

The conn.Handshake() method doesn't take any contexts or timeouts, so if the TLS server fails to respond to any handshake messages (as we often see), this goroutine will block forever. We'll also leak a TCP connection that will never be cleaned up.

One possible workaround: after successfully dialing the TCP connection, call conn.SetReadDeadline(...) to set a read deadline that matches the context deadline.

[jsha]

Note: It's also appealing to put a select inside the goroutine like so:

go func() {
  select {
    case <-ctx.Done():
      return
    case errChan <- conn.Handshake():
      return
  }
}

However, this only allows us to reap this one goroutine early in the case of a timeout; there will still be goroutines in crypto/tls trying to read from the connection, and the TCP connection will still be alive.

By setting a deadline on the TCP connection, we ensure that conn.Handshake() will return in a finite amount of time, so we don't really need the select inside the goroutine.

We could even consider getting rid of the goroutine, and just putting the conn.Handshake() call in the main select.