Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/tls: set timeout so that Close does not block indefinitely #31224
What did you do?
Reading the documentation for
This last one is the worst. It would be very easy to have a defer'ed call to Close, and assume that it will always return promptly, when in fact it may be possible for a malicious client to fill up the socket buffers with handshaking data, so that writing the close alert blocks (on an OS with tiny socket buffers?).
I have (or had) some code that does the following:
I have now carefully gone and wrapped all calls to Close with a safeClose wrapper method that calls SetWriteDeadline first!
Perhaps Close should actually call SetWriteDeadline on the underlying connection with a sane value (eg
Thankfully, http.conn.serve does call SetWriteDeadline as soon as possible for TLS connections, and never sets a zero write deadline, so that code at least is safe, and can't call Close with a zero deadline.
What did you expect to see?
More mention of what deadlines need to set, to prevent each method blocking.
Assuming the above points are all correct, a lot of folks use the tls API incorrectly. I have a TLS+TCP server that calls SetReadDeadline() and Close(). I don't recall mention of SetWriteDeadline() in any example code I read.
Maybe this calls for additional APIs, e.g. SetTLSReadDeadline() & CloseTLS()? Or a go vet item?
A new timer in tls.Close sounds good. If crypto/tls doesn't and net/http doesn't already(?), then it seems that net/http should work around any such blocking and close the underlying net.Conn directly. But it might be already. I'd have to go refresh my memory of the code.
In any case, crypto/tls doing it (regardless of whether a higher layer is also doing it) sounds good.