On 3/1/21 4:26 PM, Alex // nytpu wrote: > 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 > Hi Alex. I would like to follow the RFC too. After writing C and Python client and server implementations last fall, and examing packet traces, my conclusion was that this does not work with most TLS libraries. Mostly, they will close the connection in both directions if they receive a close_notify. Some of this is documented here [1]. This in turn causes problems for programming languages which expect a given library to behave in a certain way. For example, Python still does not allow sending a close_notify from the client after the request has been delivered and before receiving the response [2]. So, in my opinion, the simplest thing would be to utilize the <CR><LF> of the Gemini request to indicate that the client is finished sending its request. Three benefits of this approach would be: 1. All Gemini clients will keep working right now without changes 2. Because the <CR><LF> can be explicitely sent by a client application and explicetely examined by the server application, without broken TLS libraries intervening, it is easy to correctly implement 3. Gemini client authors will not experience intense frustration at the sad state of TLS library support for half-open close_notify (this is the voice of experience speaking...) > 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). > Yes I agree. It doesn't matter to me how it is worded, as long as its clear that a close_notify doesn't need to be sent from the server to the client unless the server application has been able to send all data that it wants to send first. So in the case of streaming, since the server didn't reach the end of the unending data stream, it would not send close_notify, it would just immediately close the TCP connection. [1] https://github.com/openssl/openssl/issues/11378 [2] https://bugs.python.org/issue39951
---
Previous in thread (11 of 28): 🗣️ Petite Abeille (petite.abeille (a) gmail.com)
Next in thread (13 of 28): 🗣️ Sean Conner (sean (a) conman.org)