I left many "#if 0" lines, usually because I thought we would
probably want to revisit them later, or because they provided
some useful internal documentation tips.
Reviewed-by: Andy Polyakov <appro@openssl.org>
An expired IETF Internet-Draft (seven years old) that nobody
implements, and probably just as good as NSA DRBG work.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Not interested in helping the NSA in the slightest.
And anyway, it was never implemented, #if'd out.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Since sanity checks are performed for all custom extensions the
serverinfo checks are no longer needed.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
While RFC6367 focuses on Camellia-GCM cipher suites, it also adds a few
cipher suites that use SHA-2 based HMAC that can be very easily
added.
Tested against gnutls 3.3.5
PR#3443
Reviewed-by: Tim Hudson <tjh@openssl.org>
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>
Security callback: selects which parameters are permitted including
sensible defaults based on bits of security.
The "parameters" which can be selected include: ciphersuites,
curves, key sizes, certificate signature algorithms, supported
signature algorithms, DH parameters, SSL/TLS version, session tickets
and compression.
In some cases prohibiting the use of a parameters will mean they are
not advertised to the peer: for example cipher suites and ECC curves.
In other cases it will abort the handshake: e.g DH parameters or the
peer key size.
Documentation to follow...
Add auto DH parameter support. This is roughly equivalent to the
ECDH auto curve selection but for DH. An application can just call
SSL_CTX_set_auto_dh(ctx, 1);
and appropriate DH parameters will be used based on the size of the
server key.
Unlike ECDH there is no way a peer can indicate the range of DH parameters
it supports. Some peers cannot handle DH keys larger that 1024 bits for
example. In this case if you call:
SSL_CTX_set_auto_dh(ctx, 2);
Only 1024 bit DH parameters will be used.
If the server key is 7680 bits or more in size then 8192 bit DH parameters
will be used: these will be *very* slow.
The old export ciphersuites aren't supported but those are very
insecure anyway.
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.
If an application calls the macro SSL_CTX_get_extra_chain_certs
return either the old "shared" extra certificates or those associated
with the current certificate.
This means applications which call SSL_CTX_use_certificate_chain_file
and retrieve the additional chain using SSL_CTX_get_extra_chain_certs
will still work. An application which only wants to check the shared
extra certificates can call the new macro
SSL_CTX_get_extra_chain_certs_only
New ctrl sets current certificate based on certain criteria. Currently
two options: set the first valid certificate as current and set the
next valid certificate as current. Using these an application can
iterate over all certificates in an SSL_CTX or SSL structure.
Replace the full ciphersuites with "EDH-" in their labels with "DHE-"
so that all DHE ciphersuites are referred to in the same way.
Leave backward-compatible aliases for the ciphersuites in question so
that configurations which specify these explicitly will continue
working.
This change normalizes the SSL_CK_DHE_ #defines to use the common term
"DHE", while permitting older code that uses the more uncommon "EDH"
constants to compile properly.
DHE is the standard term used by the RFCs and by other TLS
implementations. It's useful to have the internal variables use the
standard terminology.
This patch leaves a synonym SSL_kEDH in place, though, so that older
code can still be built against it, since that has been the
traditional API. SSL_kEDH should probably be deprecated at some
point, though.
ECDHE is the standard term used by the RFCs and by other TLS
implementations. It's useful to have the internal variables use the
standard terminology.
This patch leaves a synonym SSL_kEECDH in place, though, so that older
code can still be built against it, since that has been the
traditional API. SSL_kEECDH should probably be deprecated at some
point, though.
PR#3169
This patch, which currently applies successfully against master and
1_0_2, adds the following functions:
SSL_[CTX_]select_current_cert() - set the current certificate without
disturbing the existing structure.
SSL_[CTX_]get0_chain_certs() - get the current certificate's chain.
SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain.
The patch also adds these functions to, and fixes some existing errors
in, SSL_CTX_add1_chain_cert.pod.
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.
This change adds support for ALPN[1] in OpenSSL. ALPN is the IETF
blessed version of NPN and we'll be supporting both ALPN and NPN for
some time yet.
[1] https://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00
Conflicts:
ssl/ssl3.h
ssl/t1_lib.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.
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.
Note: although this passes "make test" and some simple DTLS tests there may
be some minor differences in the DTLS code that have to be accounted for.
client hello message. Previously this could only be retrieved on an initial
connection and it was impossible to determine the cipher IDs of any uknown
ciphersuites.
