(I'd rather use an option, but it appears that the options field is
full.)
Now, we send the time in the gmt_unix_time field if the appropriate
one of these mode options is set, but randomize the field if the flag
is not set.
Instead, send random bytes.
While the gmt_unix_time record was added in an ostensible attempt to
mitigate the dangers of a bad RNG, its presence leaks the host's view
of the current time in the clear. This minor leak can help
fingerprint TLS instances across networks and protocols... and what's
worse, it's doubtful thet the gmt_unix_time record does any good at
all for its intended purpose, since:
* It's quite possible to open two TLS connections in one second.
* If the PRNG output is prone to repeat itself, ephemeral
* handshakes (and who knows what else besides) are broken.
- EC_GROUP_cmp shouldn't consider curves equal just because
the curve name is the same. (They really *should* be the same
in this case, but there's an EC_GROUP_set_curve_name API,
which could be misused.)
- EC_POINT_cmp shouldn't return 0 for ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED
or EC_R_INCOMPATIBLE_OBJECTS errors because in a cmp API, 0 indicates
equality (not an error).
Reported by: king cope
(cherry picked from commit 312a46791ab465cfa3bf26764361faed0e5df014)
This fix ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest "consumes" the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was received earlier.
This patch fixes the RFC violation.
(cherry picked from commit b62f4daac00303280361924b9cc19b3e27528b15)
Reported by: Prashant Jaikumar <rmstar@gmail.com>
Fix handling of application data received before a handshake.
(cherry picked from commit 0c75eeacd3285b395dc75b65c3e6fe6ffbef59f0)
PR #3090
Reported by: Franck Youssef <fry@open.ch>
If no new reason codes are obtained after checking a CRL exit with an
error to avoid repeatedly checking the same CRL.
This will only happen if verify errors such as invalid CRL scope are
overridden in a callback.
(cherry picked from commit 4b26645c1a71cf9ce489e4f79fc836760b670ffe)
PR: 3028
Fix bug introduced in PEM_X509_INFO_bio which wouldn't process RSA keys
correctly if they appeared first.
(cherry picked from commit 5ae8d6bcbaff99423a2608559d738a3fcf7ed6dc)
Bug would emerge when XTS is added to bsaes-armv7.pl. Pointed out by
Ard Biesheuvel of Linaro.
(cherry picked from commit 044f63086051d7542fa9485a1432498c39c4d8fa)
Fix PSS signature printing: consistently use 0x prefix for hex values for
padding length and trailer fields.
(cherry picked from commit deb24ad53147f5a8dd63416224a5edd7bbc0e74a)
Reencode certificates in X509_sign_ctx as well as X509_sign.
This was causing a problem in the x509 application when it modified an
existing certificate.
(cherry picked from commit c6d8adb8a45186617e0a8e2c09469bd164b92b31)
While ARMv7 in general is capable of unaligned access, not all instructions
actually are. And trouble is that compiler doesn't seem to differentiate
those capable and incapable of unaligned access. Side effect is that kernel
goes into endless loop retrying same instruction triggering unaligned trap.
Problem was observed in xts128.c and ccm128.c modules. It's possible to
resolve it by using (volatile u32*) casts, but letting STRICT_ALIGNMENT
be feels more appropriate.
(cherry picked from commit 3bdd80521a81d50ade4214053cd9b293f920a77b)
Don't check for binary curves by checking methods: the values will
be different in FIPS mode as they are redirected to the validated module
version.
(cherry picked from commit 94782e0e9c28bd872107b8f814f4db68c9fbf5ab)
If an ASN1_INTEGER structure is allocated but not explicitly set encode
it as zero: don't generate an invalid zero length INTEGER.
(cherry picked from commit 1643edc63c3e15b6db5a15a728bc288f2cc2bbc7)
