That is not the expected behavior. Likely what is happening is the server (at the http layer) sees the Connection: close header, and goes to close the socket for the underlying transport (in this case, the tls stack). The server’s tls stack, when getting that signal, closes the tls connection, and since it does that before receiving the erroneous client Finished, it sends Alert(0) and closes the connection on its end.
On Tue, Aug 9, 2022 at 00:55 Kristijan Sedlak <xpeperm...@gmail.com> wrote: > After some sleep, I went playing with the content of the EarlyData sent to > the server and it turned out that the "Connection: close" header must be > present in the HTTP1.1 request. After adding it, the error was gone and the > connection closed with Alert(0). > > Is this the expected behavior and Keep-Alieve is not allowed when > EarlyData is used or it's just the remote server implementation specific? > If I understand the spec correctly, the behavior of the EarlyData part is > mostly up to the implementor, and you must know the rules up front, right? > > Best, > Kristijan > > On 9 Aug 2022, at 09:05, Kristijan Sedlak <xpeperm...@gmail.com> wrote: > > Hey Ilari, > > thank’s for replying. I did verify the transcript as well. Everything > seems to be correct. I bet if it wasn't the 1-RTT and 0-RTT(no-early-data) > would fail too. Something weird is going on only in 0-RTT(early-data) case. > > Can you maybe point me to an URL with the correct TLS1.3 implementation > where I could safely test the client? > > Best, > Kristijan > > > On 9 Aug 2022, at 08:51, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > Ilari > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
