💾 Archived View for rawtext.club › ~sloum › geminilist › 005833.gmi captured on 2023-11-04 at 13:42:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Scot gmi1 at scotdoyle.com
Tue Mar 2 00:23:09 GMT 2021
- - - - - - - - - - - - - - - - - - -
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 implementationslast fall, and examing packet traces, my conclusion was thatthis does not work with most TLS libraries. Mostly, they willclose the connection in both directions if they receive aclose_notify. Some of this is documented here [1]. This inturn causes problems for programming languages whichexpect a given library to behave in a certain way. For example,Python still does not allow sending a close_notify from theclient after the request has been delivered and beforereceiving 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 clientis 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 clientapplication and explicetely examined by the server application,without broken TLS libraries intervening, it is easy to correctlyimplement
3. Gemini client authors will not experience intense frustrationat 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, aslong as its clear that a close_notify doesn't need to be sentfrom the server to the client unless the server applicationhas been able to send all data that it wants to send first. Soin the case of streaming, since the server didn't reach the endof the unending data stream, it would not send close_notify, itwould just immediately close the TCP connection.
[1] https://github.com/openssl/openssl/issues/11378[2] https://bugs.python.org/issue39951