Add the following cases:
- Maximal padding
- Maximal padding with each possible byte position wrong.
- When the input is not publicly too short to find a MAC, but the
unpadded value is too short. (This tests that
EVP_tls_cbc_remove_padding and EVP_tls_cbc_copy_mac coordinate
correctly. EVP_tls_cbc_remove_padding promises to also consider it
invalid padding if there is no room for a MAC.)
Change-Id: I8fe18121afb915e579a8236d0e3ef354f1f835bc
Reviewed-on: https://boringssl-review.googlesource.com/10182
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Test that SSLv3 accepts arbitrary padding bytes (hello, POODLE) and rejects
non-minimal padding, while TLS accepts non-minimal padding but rejects
arbitrary padding bytes.
Also test what happens when the MAC is correct, but there is no padding. This
is the case that triggers a failing padding_ok check after the MAC check
on padding_len = 0 passes.
Change-Id: Ia1444c526437899fc57ceafcbcef9c8f5cb9a6c5
Reviewed-on: https://boringssl-review.googlesource.com/2702
Reviewed-by: Adam Langley <agl@google.com>
The EVP_CIPHER codepath should no longer be used with TLS. It still exists for
DTLS and SSLv3. The AEAD construction in TLS does not allow for
variable-overhead AEADs, so stateful AEADs do not include the length in the ad
parameter. Rather the AEADs internally append the unpadded length once it is
known. EVP_aead_rc4_md5_tls is modified to account for this.
Tests are added (and RC4-MD5's regenerated) for each of the new AEADs. The
cipher tests are all moved into crypto/cipher/test because there's now a lot of
them and they clutter the directory listing.
In ssl/, the stateful AEAD logic is also modified to account for stateful AEADs
with a fixed IV component, and for AEADs which use a random nonce (for the
explicit-IV CBC mode ciphers).
The new implementation fixes a bug/quirk in stateless CBC mode ciphers where
the fixed IV portion of the keyblock was generated regardless. This is at the
end, so it's only relevant for EAP-TLS which generates a MSK from the end of
the key block.
Change-Id: I2d8b8aa11deb43bde2fd733f4f90b5d5b8cb1334
Reviewed-on: https://boringssl-review.googlesource.com/2692
Reviewed-by: Adam Langley <agl@google.com>
