Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData

[Ilari Liusvaara <[e-mail]>]

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