Matt Caswell

Is this still relevant? If so there are conflicts - it needs a rebase.

> It needs updating in light of the new fixes I've now updated this PR. Please take a look. > What are the steps to test this in 1.1.1? Is...

> would look more conservative and more correct to me. I don't think that is the correct fix. We must be careful to only reserve the right amount. If we...

> Yes, but the the limit (mac_size == 0 && !clear ? SHA384_DIGEST_LENGTH : 0) + SSL_RT_MAX_CIPHER_BLOCK_SIZE is lower than SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD - mac_size in all cases, and still the assertion...

> I have only a problem with the assertion, because an engine-based aes-cbc-sha-x cipher might have a good reason to not use the minimal padding, for instance as a counter...

> and ssl_get_max_send_fragment() is always greater than 512. So? This is the memory allocated for the plaintext record. If the length of the plaintext record is equal to `ssl_get_max_send_fragment()` (which...

> But hiding the exact size of the plain text record is a pretty cool feature IMHO. There is a supported way to do this with TLSv1.3 (i.e. via SSL_CTX_set_record_padding_callback()...

We could potentially do that, but there is no access to the WPACKET at that point in the code. It would require refactoring for that to happen. That's probably not...

You'd need to do that for *all* enc functions and modify the `SSL_ENC_METHOD` structure definition accordingly. IMO that is not appropriate for 1.1.1 and certainly isn't with the scope of...

> As I see it, it is possible to exceed the padding limit either on purpose and get away with it, because the engine knows or at least correctly guessed...