Do not TLS close_notify when resetting a TCP connection #1944
Conversation
reducing code duplication.
Neither is perfect, but I think the earlier version of this documentation gave the reader more/better information about this flag intent/purpose. Here, SO_LINGER is just an implementation detail that `.h` reader should not really care/know about.
| if (F->ssl && !F->flags.harshClosureRequested) { | ||
| const auto startCall = asyncCall(5, 4, "commStartTlsClose", | ||
| callDialer(commStartTlsClose, fd)); |
There was a problem hiding this comment.
To me, it seems fairly obvious that if we are going to send TCP RST to the client, then we do not want to nicely close TLS session either. Our harsh closure reasons that apply to TCP layer ought to apply to TLS layer as well. For example, if Squid is sending the client an unchunked HTTP response without Content-Length header, and Squid has to abort that transaction, then we do not want successful TLS closure to trick that client into thinking that it has gotten the entire response body.
If others disagree with this "fairly obvious" assertion, then we should add an explanation to PR description. That explanation may be similar to the above paragraph (sans the "obvious" claim itself, of course).
There was a problem hiding this comment.
While what you write seems reasonable, it is not clear that RST is the only result of this function being called. It can and is also called for the FIN cases where TLS should be completed cleanly.
There was a problem hiding this comment.
RST is the only result of this function being called
FWIW, the function (commStartTlsClose()) is not called for RST cases (F->flags.harshClosureRequested is false) but called for other (i.e., FIN) cases, as you noted.
| @@ -783,6 +783,8 @@ commConfigureLinger(const int fd, const OnOff enabled) | |||
| l.l_onoff = (enabled == OnOff::on ? 1 : 0); | |||
| l.l_linger = 0; // how long to linger for, in seconds | |||
|
|
|||
| fd_table[fd].flags.harshClosureRequested = (l.l_onoff && !l.l_linger); // close(2) sends TCP RST if true | |||
|
|
|||
| if (setsockopt(fd, SOL_SOCKET, SO_LINGER, reinterpret_cast<char*>(&l), sizeof(l)) < 0) { | |||
There was a problem hiding this comment.
It may be tempting to make new harshClosureRequested flag assignment conditional on this setsockopt() call success, but I do not think we should do that: The caller has requested harsh connection closing; setsockopt() success is pretty much irrelevant. Even if TCP layer closes nicely despite our attempt to close harshly, we still want to close TLS layer harshly...
| @@ -783,6 +783,8 @@ commConfigureLinger(const int fd, const OnOff enabled) | |||
| l.l_onoff = (enabled == OnOff::on ? 1 : 0); | |||
| l.l_linger = 0; // how long to linger for, in seconds | |||
|
|
|||
| fd_table[fd].flags.harshClosureRequested = (l.l_onoff && !l.l_linger); // close(2) sends TCP RST if true | |||
There was a problem hiding this comment.
This is a low-level private function with callers already checking fd, so I think it may be OK to avoid checking fd value before accessing fd_table here. If you disagree, consider applying this suggestion:
| fd_table[fd].flags.harshClosureRequested = (l.l_onoff && !l.l_linger); // close(2) sends TCP RST if true | |
| if (isOpen(fd)) | |
| fd_table[fd].flags.harshClosureRequested = (l.l_onoff && !l.l_linger); // close(2) sends TCP RST if true |
There was a problem hiding this comment.
We would need also to protect setsockopt() by the same check, i.e., basically this function should immediately return if isOpen() is false. I would just assert(isOpen(fd)) instead.
rousskov
added
the
S-waiting-for-more-reviewers
|
Please rebase for easier review. There are changes here from other PRs which were controversial. |
yadij
added
S-waiting-for-author
No description provided.