Removing RSA+MD5 from the default signature algorithm list
prevents its use by default.
If a broken implementation attempts to use RSA+MD5 anyway the sanity
checking of signature algorithms will cause a fatal alert.
(cherry picked from commit 77a0f740d00ecf8f6b01c0685a2f858c3f65a3dd)
Some TLS extensions were disabled for DTLS. Possibly because they caused
problems with the old duplicated code. Enable them again.
(cherry picked from commit 874a18cfad)
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)
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)
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)
possible to have different stores per SSL structure or one store in
the parent SSL_CTX. Include distint stores for certificate chain
verification and chain building. New ctrl SSL_CTRL_BUILD_CERT_CHAIN
to build and store a certificate chain in CERT structure: returing
an error if the chain cannot be built: this will allow applications
to test if a chain is correctly configured.
Note: if the CERT based stores are not set then the parent SSL_CTX
store is used to retain compatibility with existing behaviour.
(backport from HEAD)
the permitted signature algorithms for server and client authentication
are the same but it is now possible to set different algorithms for client
authentication only.
(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)
the certificate can be used for (if anything). Set valid_flags field
in new tls1_check_chain function. Simplify ssl_set_cert_masks which used
to have similar checks in it.
Add new "cert_flags" field to CERT structure and include a "strict mode".
This enforces some TLS certificate requirements (such as only permitting
certificate signature algorithms contained in the supported algorithms
extension) which some implementations ignore: this option should be used
with caution as it could cause interoperability issues.
(backport from HEAD)
Only store encoded versions of peer and configured signature algorithms.
Determine shared signature algorithms and cache the result along with NID
equivalents of each algorithm.
(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)
