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 4544f0a69161a37ee3edce3cc1bc34c3678a4d64)
If we successfully match a cookie don't set return value to 2 as this
results in other error conditions returning 2 as well.
Instead set return value to -2 which can be checked later if everything
else is OK.
(cherry picked from commit c56f5b8edfbcec704f924870daddd96a5f768fbb)
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 c6913eeb762edffddecaaba5c84909d7a7962927)
Conflicts:
CHANGES
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 cbd64894ec687c6f37d8e43c16dff78e63f6be87)
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 173e72e64c6a07ae97660c322396b66215009f33)
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)
TLS v1.2. These are sent as an extension for clients and during a certificate
request for servers.
TODO: add support for shared signature algorithms, respect shared algorithms
when deciding which ciphersuites and certificates to permit.
(backport from HEAD)
enabled instead of requiring an application to hard code a (possibly
inappropriate) parameter set and delve into EC internals we just
automatically use the preferred curve.
(backport from HEAD)
Submitted by: steve
Update maximum message size for certifiate verify messages to support
4096 bit RSA keys again as TLS v1.2 messages is two bytes longer.
Submitted by: Peter Sylvester <peter.sylvester@edelweb.fr>
Reviewed by: steve
- remove some unncessary SSL_err and permit
an srp user callback to allow a worker to obtain
a user verifier.
- cleanup and comments in s_server and demonstration
for asynchronous srp user lookup
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.
than client side as we need to keep the handshake record cache frozen when
it contains all the records need to process the certificate verify message.
(backport from HEAD).
