We have to use EVP in FIPS mode so we can only partially mitigate
timing differences.
Make an extra call to HMAC_Update to hash additonal blocks
to cover any timing differences caused by removal of padding.
This change updates the DTLS code to match the constant-time CBC
behaviour in the TLS.
(cherry picked from commit 9f27de170d)
(cherry picked from commit 5e4ca556e970edb8a7f364fcb6ee6818a965a60b)
Conflicts:
ssl/d1_enc.c
ssl/d1_pkt.c
ssl/s3_pkt.c
The previous CBC patch was bugged in that there was a path through enc()
in s3_pkt.c/d1_pkt.c which didn't set orig_len. orig_len would be left
at the previous value which could suggest that the packet was a
sufficient length when it wasn't.
(cherry picked from commit 6cb19b7681)
(cherry picked from commit 2c948c1bb218f4ae126e14fd3453d42c62b93235)
Conflicts:
ssl/s3_enc.c
This patch makes the decoding of SSLv3 and TLS CBC records constant
time. Without this, a timing side-channel can be used to build a padding
oracle and mount Vaudenay's attack.
This patch also disables the stitched AESNI+SHA mode pending a similar
fix to that code.
In order to be easy to backport, this change is implemented in ssl/,
rather than as a generic AEAD mode. In the future this should be changed
around so that HMAC isn't in ssl/, but crypto/ as FIPS expects.
(cherry picked from commit e130841bcc)
Conflicts:
crypto/evp/c_allc.c
ssl/ssl_algs.c
ssl/ssl_locl.h
ssl/t1_enc.c
(cherry picked from commit 3622239826698a0e534dcf0473204c724bb9b4b4)
Conflicts:
ssl/d1_enc.c
ssl/s3_enc.c
ssl/s3_pkt.c
ssl/ssl3.h
ssl/ssl_algs.c
ssl/t1_enc.c
This change adds CRYPTO_memcmp, which compares two vectors of bytes in
an amount of time that's independent of their contents. It also changes
several MAC compares in the code to use this over the standard memcmp,
which may leak information about the size of a matching prefix.
(cherry picked from commit 2ee798880a)
Conflicts:
crypto/crypto.h
ssl/t1_lib.c
(cherry picked from commit dc406b59f3169fe191e58906df08dce97edb727c)
Conflicts:
crypto/crypto.h
ssl/d1_pkt.c
ssl/s3_pkt.c
'len' argument to BUF_MEM_grow and BUF_MEM_grow_clean is an
int in OpenSSL 0.9.8, making it still vulnerable. Fix by
rejecting negative len parameter.
Thanks to the many people who reported this bug and to Tomas Hoger
<thoger@redhat.com> for supplying the fix.
