that fixed PR#3450 where an existing cast masked an issue when i was changed
from int to long in that commit
Picked up on z/linux (s390) where sizeof(int)!=sizeof(long)
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit b5ff559ff9)
Fix a bug in handling of 128 byte long PSK identity in
psk_client_callback.
OpenSSL supports PSK identities of up to (and including) 128 bytes in
length. PSK identity is obtained via the psk_client_callback,
implementors of which are expected to provide a NULL-terminated
identity. However, the callback is invoked with only 128 bytes of
storage thus making it impossible to return a 128 byte long identity and
the required additional NULL byte.
This CL fixes the issue by passing in a 129 byte long buffer into the
psk_client_callback. As a safety precaution, this CL also zeroes out the
buffer before passing it into the callback, uses strnlen for obtaining
the length of the identity returned by the callback, and aborts the
handshake if the identity (without the NULL terminator) is longer than
128 bytes.
(Original patch amended to achieve strnlen in a different way.)
Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit be0d851732)
The addition of SRP authentication needs to be checked in various places
to work properly. Specifically:
A certificate is not sent.
A certificate request must not be sent.
Server key exchange message must not contain a signature.
If appropriate SRP authentication ciphersuites should be chosen.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 8f5a8805b82d1ae81168b11b7f1506db9e047dec)
Allow CCS after finished has been sent by client: at this point
keys have been correctly set up so it is OK to accept CCS from
server. Without this renegotiation can sometimes fail.
PR#3400
(cherry picked from commit 99cd6a91fcb0931feaebbb4832681d40a66fad41)
If application uses tls_session_secret_cb for session resumption
set the CCS_OK flag.
(cherry picked from commit 953c592572e8811b7956cc09fbd8e98037068b58)
Only accept change cipher spec when it is expected instead of at any
time. This prevents premature setting of session keys before the master
secret is determined which an attacker could use as a MITM attack.
Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for reporting this issue
and providing the initial fix this patch is based on.
(cherry picked from commit bc8923b1ec)
If multiple TLS extensions are expected but not received, the TLS extension and supplemental data 'generate' callbacks are the only chance for the receive-side to trigger a specific TLS alert during the handshake.
Removed logic which no-op'd TLS extension generate callbacks (as the generate callbacks need to always be called in order to trigger alerts), and updated the serverinfo-specific custom TLS extension callbacks to track which custom TLS extensions were received by the client, where no-ops for 'generate' callbacks are appropriate.
(cherry picked from commit ac20719d99)
Conflicts:
ssl/t1_lib.c
Removed prior audit proof logic - audit proof support was implemented using the generic TLS extension API
Tests exercising the new supplemental data registration and callback api can be found in ssltest.c.
Implemented changes to s_server and s_client to exercise supplemental data callbacks via the -auth argument, as well as additional flags to exercise supplemental data being sent only during renegotiation.
(cherry picked from commit 36086186a9)
Conflicts:
Configure
apps/s_client.c
apps/s_server.c
ssl/ssl.h
ssl/ssl3.h
ssl/ssltest.c
Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.
This is a forward-port of commits:
4af793036ff4c93b46ed3da721dac92583270191
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.
Make DTLS behave like TLS when negotiating version: record layer has
DTLS 1.0, message version is 1.2.
Tolerate different version numbers if version hasn't been negotiated
yet.
(cherry picked from commit 40088d8b81)
Check for Suite B support using method flags instead of version numbers:
anything supporting TLS 1.2 cipher suites will also support Suite B.
Return an error if an attempt to use DTLS 1.0 is made in Suite B mode.
(cherry picked from commit 4544f0a691)
Add new methods DTLS_*_method() which support both DTLS 1.0 and DTLS 1.2 and
pick the highest version the peer supports during negotiation.
As with SSL/TLS options can change this behaviour specifically
SSL_OP_NO_DTLSv1 and SSL_OP_NO_DTLSv1_2.
(cherry picked from commit c6913eeb76)
Conflicts:
CHANGES
Add correct flags for DTLS 1.2, update s_server and s_client to handle
DTLS 1.2 methods.
Currently no support for version negotiation: i.e. if client/server selects
DTLS 1.2 it is that or nothing.
(cherry picked from commit c3b344e36a)
Conflicts:
apps/s_server.c
Use the enc_flags field to determine whether we should use explicit IV,
signature algorithms or SHA256 default PRF instead of hard coding which
versions support each requirement.
(cherry picked from commit cbd64894ec)
Conflicts:
ssl/ssl_locl.h
Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.
Specifically almost all of the record generation functions have code like
this:
some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);
...
write_handshake_message(ssl);
Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.
By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.
(cherry picked from commit 173e72e64c)
by a certificate chain. Add additional tests to handle client
certificates: checks for matching certificate type and issuer name
comparison.
Print out results of checks for each candidate chain tested in
s_server/s_client.
(backport from HEAD)
details in s_client.
Also add ctrl to set client certificate types. If not used sensible values
will be included based on supported signature algorithms: for example if
we don't include any DSA signing algorithms the DSA certificate type is
omitted.
Fix restriction in old code where certificate types would be truncated
if it exceeded TLS_CT_NUMBER.
(backport from HEAD)
is required by client or server. An application can decide which
certificate chain to present based on arbitrary criteria: for example
supported signature algorithms. Add very simple example to s_server.
This fixes many of the problems and restrictions of the existing client
certificate callback: for example you can now clear existing certificates
and specify the whole chain.
(backport from HEAD)
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.
Submitted by: Peter Sylvester <peter.sylvester@edelweb.fr>
Reviewed by: steve
Make SRP conformant to rfc 5054.
Changes are:
- removal of the addition state after client hello
- removal of all pre-rfc srp alert ids
- sending a fatal alert when there is no srp extension but when the
server wants SRP
- removal of unnecessary code in the client.
