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

[Ilari Liusvaara <[e-mail]>]

On Mon, Aug 08, 2022 at 08:15:41PM +0200, Kristijan Sedlak wrote:
> Hello everyone. 
> 
> I decided to get involved here since I hit a dead end when resolving
> an Alert(20) error that I get from almost all servers when using PSK
> with EarlyData.
> 
> Here's the initial issue I opened https://github.com/thekuwayama/tttls1.3/issues/48.
> It relates to a specific implementation but my questions are general.
> There's also a code snippet that you can run and see the issue
> yourself.
> 
> So it happens that when sending a GET request as EarlyData and then
> completing the handshake with EndOfEarlyData following the
> ClientFinished message, a server (e.g. ssltest.louis.info)
> successfully sends a complete response but finishes the request with
> Alert(20) message. It doesn't happen on 1-RTT nor 0-RTT(without early
> data). If I don't send ClientFinished in 0-RTT+EarlyData I don't get
> Alert(20) and everything works as expected.
> 
> I don't see anything in the spec that would describe something like
> this or would point to a different way for calculating the
> ClientFinished for 0-RTT+EarlyData case. Is maybe this sentence from
> the spec "PSK-based authentication happens as a side effect of key
> exchange." something that some of us miss interpreter and states
> that Finished message should be verified and sent only in 1-RTT? 
>
> What could be the case here?

Wild guess, the transcript is not computed over correct messages or in
correct order.


When server accepts early data, the sequence of messages client sends
is:

- ClientHello
- (0-RTT data)
- EndOfEarlyData
- client Finished

And the sequence of messages in transcript used to compute the client
finished is (note the EoED, RFC 8446 section 4.4.1 is very explicit
about it):

- ClientHello
- ServerHello
- EncryptedExtensions
- server Finished
- EndOfEarlyData


(This assumes there is no extension that would add new messages in
play. There can not be HelloRetryRequest because that implicitly
rejects early data.)



-Ilari