A similar fix should be also implemented for 1.1.1

I'm surprised that this problem hasn't been identified before. Surely ETM will be negotiated by default for all modern OpenSSL versions? How is that we've never noticed this?

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually.

I'm surprised that this problem hasn't been identified before. Surely ETM will be negotiated by default for all modern OpenSSL versions? How is that we've never noticed this?

It's on a client side. Server side has this code for a long time, and, if no EtM extension is sent by server, client should have use_etm=0. This case as far as I understand it really covers the case of incorrect server implementation.

It's on a client side. Server side has this code for a long time, and, if no EtM extension is sent by server, client should have use_etm=0. This case as far as I understand it really covers the case of incorrect server implementation.

Ah! Right - interesting. I missed that. Hmm...I wondering whether in this case we should actually abort the connection? If the server indicates it wants to use ETM for a ciphersuite that it isn't appropriate for we probably shouldn't just continue regardless?

Current behavior is silently ignore this extension and I think it's reasonable

Current behavior is silently ignore this extension and I think it's reasonable

Yeah, I get that. I'm just questioning whether the current behaviour really is reasonable. I won't block this PR - it doesn't make the situation worse. But I wonder whether we should be stricter.

Merged. Thanks for the approval!

I wondering whether in this case we should actually abort the connection? If the server indicates it wants to use ETM for a ciphersuite that it isn't appropriate for we probably shouldn't just continue regardless?

I think most of the relevant RFCs have language like "server MUST NOT negotiatie the EtM extension when using this cipher", so having the client abort would be appropriate.

I'm surprised that this problem hasn't been identified before. Surely ETM will be negotiated by default for all modern OpenSSL versions? How is that we've never noticed this?

This problem was detected as a result of adversarial testing. I think the client should definitely abort the connection. Otherwise every fuzzer will be bumping into this.