On Tue, Aug 09, 2022 at 09:05:31AM +0200, Kristijan Sedlak wrote: > > 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.
Well, if an implmentation incorrectly omitted EOED from transcript, that would only fail in accepted early-data case, not in other cases. However, looking at the library source, it seems to properly include EOED in the transcript (however, I am not a Ruby programmer). Wild thing to try, and extremely unlikely to work, but does removing the EOED from the transcript (but still sending the message!) make the server accept the client finished? If yes, the server is buggy: TLS 1.3 is very clear that EOED is part of the transcript. > Can you maybe point me to an URL with the correct TLS1.3 > implementation where I could safely test the client? Well, I would try testing against some major CDN that accepts early data, as they likely have the most debugged server implementations. As for safety, if you don't have automated repeats, I would think that would be unlikely to trip any sort of attack detection with the CDN. I have written a TLS implementation, but it will not support early data. On Tue, Aug 09, 2022 at 09:55:37AM +0200, Kristijan Sedlak 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). Well, what I think is happening here is that the server can only ever send one alert per connection. The Connection: close then causes it to send close_notify from early data, and so when the finished MAC is bad, it can not send alert for it. Or else that the close from early data causes it to get confused and silently abort the handshake. > 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? Keep-Alive is definitely supposed to work with early data. The behavior specified is that if early data is accepted, the client data consists of concatenation of the early data and the application data the client sends. If early data is not proposed, or it gets rejected, then client data consists of application data the client sends. Note that for HTTP, only GET and HEAD (and in future, QUERY) are allowed in early data. And the requests might get 425 error, which MUST be retried. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
