Commit f0348c842e introduced a problem with session resumption. The
version for the session is fixed when the session is created. By moving
the creation of the session earlier in the process the version is fixed
*before* version negotiation has completed when processing the ServerHello
on the client side. This fix updates the session version after version neg
has completed.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit dc0c888811)
The function SSL_set_session_ticket_ext can be used to set custom session
ticket data passed in the initial ClientHello. This can be particularly
useful for EAP-FAST. However, when using SSLv23_method, the session does
not get created until the ServerHello has been received. The extension code
will only add the SessionTicket data to the ClientHello if a session already
exists. Therefore SSL_set_session_ticket_ext has no impact when used in
conjunction with SSLv23_method. The solution is to simply create the session
during creation of the ClientHello instead of waiting for the ServerHello.
This commit fixes the test failure introduced by the previous commit.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(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.
If OPENSSL_MAX_TLS1_2_CIPHER_LENGTH is set then limit the size of client
ciphersuites to this value. A value of 50 should be sufficient.
Document workarounds in CHANGES.
Some servers hang when presented with a client hello record length exceeding
255 bytes but will work with longer client hellos if the TLS record version
in client hello does not exceed TLS v1.0. Unfortunately this doesn't fix all
cases...
Submitted by: Tomas Mraz <tmraz@redhat.com>
Since SSLv2 doesn't support renegotiation at all don't reject it if
legacy renegotiation isn't enabled.
Also can now use SSL2 compatible client hello because RFC5746 supports it.
(draft-rescorla-tls-opaque-prf-input-00.txt), and do some cleanups and
bugfixes on the way. In particular, this fixes the buffer bounds
checks in ssl_add_clienthello_tlsext() and in ssl_add_serverhello_tlsext().
Note that the opaque PRF Input TLS extension is not compiled by default;
see CHANGES.
des_old.h redefines crypt:
#define crypt(b,s)\
DES_crypt((b),(s))
This scheme leads to failure, if header files with the OS's true definition
of crypt() are processed _after_ des_old.h was processed. This is e.g. the
case on HP-UX with unistd.h.
As evp.h now again includes des.h (which includes des_old.h), this problem
only came up after this modification.
Solution: move header files (indirectly) including e_os.h before the header
files (indirectly) including evp.h.
Submitted by:
Reviewed by:
PR:
