@FiloSottile

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?

Ping @FiloSottile

@andybons, could this be milestoned for 1.13 and made release-blocker?

Correct use of TLS is a security concern, and one of the suggested fixes is to change .Close() behavior.

I agree this needs addressing, but it does not warrant changing subtle behavior while in deep feature freeze. The only fix for Go 1.13 will be probably in documentation, and we can discuss in 1.14 with more flexibility.

Thanks, happy to give feedback on the CL when ready...

@FiloSottile, you tagged this for 1.13. It's now been re-tagged for 1.14; was that a mistake?

@FiloSottile we might want to tackle this one early in 1.14 cycle...

@gopherbot add release-blocker

I'm thinking of introducing a default deadline on the close notify send, and document in Read and Write, where they say they call Handshake, that that means they need both read and write deadlines.

Re setting a default deadline, is there any conflict with http.Server/Client? See #21133 (comment)

Reusing a net.Conn after a tls.Close is weird but I suppose not impossible? Sure, we can just reset it before leaving Close.

Just wondering whether the implicit deadlines that http uses might conflict with an implicit deadline in tls.Close?

Ah, well by the time tls.Close is called it doesn't really matter, does it? We are tearing down, so we can just override them.

@bradfitz any thoughts?

I haven't looked into this issue, but from a quick skim of this thread, it does indeed seem like things are too complicated/surprising for users.

@bradfitz any comment re a new implicit timer in tls.Close? Could that conflict with implicit timers in http?

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.

Looks like no change was made for 1.14, so retargeting for 1.15. Also looks like the current thinking is to change the code, so dropping the documentation label.

Could we target this for 1.16?

cc @odeke-em in case it's of interest...

The changes here are

• set a Deadline in Close of 5s before sending and trying to read the closeNotify
• call attention to the fact that Read?Write call Handshake so need both deadlines in their docs

Change https://golang.org/cl/266037 mentions this issue: crypto/tls: set Deadline before sending close notify alert

Could the docs also give guidance on the deadline durations for Read & Write?

I think that can be in a separate issue/CL. If we were to provide guidance about an appropriate deadline, then that would be more appropriate in the godoc for SetDeadline, SetReadDeadline, and/or SetWriteDeadline, not in Read or Write.
We would also need to determine what a sensible deadline would be, or how to provide guidance for that.

Since you have to set a write deadline on Read, and a read deadline on Write, it would be helpful to know if there's a minimum value necessary in TLS.

Sure. Feel free to file another issue. That is out of scope for this one.

@katiehockman @FiloSottile This is a bit unfortunate. I knew it could block, so I was setting my own deadline of 100ms (did not really care if the alert is sent or not, but I did not want it to block). With this change, my code now will block up to 5 seconds. Anything I can do to close the low level connection without blocking (up to 5sec) here?

Can I ask what services or clients are stalling on close often enough to cause problems?

@networkimprov This is in context of NATS Server. When a client is closed, I try to flush and close the connection. Because of TLS, I was setting a low deadline. I have a test that produced the condition that may cause the TLS close to stall and they started to fail, and I realize that this is because of Go overriding my own deadline: https://github.com/nats-io/nats-server/blob/f82ba22be252755aefbf33af8d66db8cf7421b53/server/client.go#L4352
Here is one of the test that checks for that: https://github.com/nats-io/nats-server/blob/f82ba22be252755aefbf33af8d66db8cf7421b53/server/routes_test.go#L1185

Could you open a new issue to suggest that TLS close not override an existing deadline, or that a tls.Config field be added to let you specify the close deadline? And then mention that issue here. Thanks!

Ping @kozlovic re new issue...

@networkimprov Sorry for delay, took some time off. I created the issue #45162.