On 2021-03-01 03:18PM, Scot wrote: > 1. Not requiring client applications to send TLS close_notify, since > they indicate end-of-data via the request <CR><LF> ? See this quote from the TLS 1.3 spec: > Each party MUST send a "close_notify" alert before closing its write > side of the connection, unless it has already sent some error alert. > This does not have any effect on its read side of the connection. https://tools.ietf.org/html/rfc8446#section-6.1 - TLS 1.3 The effect of this is that clients MUST send close_notify after writing their a request in order to properly comply with TLS 1.3. I would operate under the assumption that a server would not send a response until a close_notify is received (or the request would be allowed to time out). Obviously a robust server would work without a close_notify, but you should still operate within the spec because I'm wouldn't be surprised if at least one or two TLS implementations require it. There's even stronger wording for TLS 1.2 which requires a close_notify after writing is completed and for /both/ the sending and receiving parties to send a close_notify after the transaction is completed, so the client would have to send a close_notify after the both request and the response, not just the request. See: https://tools.ietf.org/html/rfc5246#section-7.2.1 On 2021-03-01 03:18PM, Scot wrote: > 2. Only requiring server applications to send TLS close_notify if all > data has been sent? If the TCP or TLS connection is interrupted by the > client or by an intermediary before the server application has > transmitted all of its data, there doesn't seem to be a benefit to > sending a close_notify to the client and it could also cause various > delays which prohibit the server application from moving on to other > work. For example, an unending streaming response would be closed by > the client, in which case there is no need for a close_notify from the > server. The whole point of close_notify is to indicate that the write has successfully been completed. I may be misunderstanding your question, but if the connection is interrupted then a close_notify should not be sent, as that would erroneously report that the transaction was successfully completed. For streaming data I assume that it would be properly terminated by the client closing the connection since the data is never completely sent (it's unending). I'm no TLS expert, I'm just reporting what I found after skimming the TLS RFCs, feel free to correct me if I'm wrong here. ~nytpu -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210301/7c78 2861/attachment.sig>
---
Previous in thread (9 of 28): 🗣️ Scot (gmi1 (a) scotdoyle.com)
Next in thread (11 of 28): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)