knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.
Also, get rid of compile-time switch OPENSSL_NO_RELEASE_BUFFERS
because it was rather pointless (the new behavior has to be explicitly
requested by setting SSL_MODE_RELEASE_BUFFERS anyway).
of handshake failure
2. Changes to x509_certificate_type function (crypto/x509/x509type.c) to
make it recognize GOST certificates as EVP_PKT_SIGN|EVP_PKT_EXCH
(required for s3_srvr to accept GOST client certificates).
3. Changes to EVP
- adding of function EVP_PKEY_CTX_get0_peerkey
- Make function EVP_PKEY_derive_set_peerkey work for context with
ENCRYPT operation, because we use peerkey field in the context to
pass non-ephemeral secret key to GOST encrypt operation.
- added EVP_PKEY_CTRL_SET_IV control command. It is really
GOST-specific, but it is used in SSL code, so it has to go
in some header file, available during libssl compilation
4. Fix to HMAC to avoid call of OPENSSL_cleanse on undefined data
5. Include des.h if KSSL_DEBUG is defined into some libssl files, to
make debugging output which depends on constants defined there, work
and other KSSL_DEBUG output fixes
6. Declaration of real GOST ciphersuites, two authentication methods
SSL_aGOST94 and SSL_aGOST2001 and one key exchange method SSL_kGOST
7. Implementation of these methods.
8. Support for sending unsolicited serverhello extension if GOST
ciphersuite is selected. It is require for interoperability with
CryptoPro CSP 3.0 and 3.6 and controlled by
SSL_OP_CRYPTOPRO_TLSEXT_BUG constant.
This constant is added to SSL_OP_ALL, because it does nothing, if
non-GOST ciphersuite is selected, and all implementation of GOST
include compatibility with CryptoPro.
9. Support for CertificateVerify message without length field. It is
another CryptoPro bug, but support is made unconditional, because it
does no harm for draft-conforming implementation.
10. In tls1_mac extra copy of stream mac context is no more done.
When I've written currently commited code I haven't read
EVP_DigestSignFinal manual carefully enough and haven't noticed that
it does an internal digest ctx copying.
This implementation was tested against
1. CryptoPro CSP 3.6 client and server
2. Cryptopro CSP 3.0 server
(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.
This change resolves a number of problems and obviates multiple kludges.
A new feature is that you can now say "AES256" or "AES128" (not just
"AES", which enables both).
In some cases the ciphersuite list generated from a given string is
affected by this change. I hope this is just in those cases where the
previous behaviour did not make sense.
(CVE-2006-3738) [Tavis Ormandy and Will Drewry, Google Security Team]
Fix SSL client code which could crash if connecting to a
malicious SSLv2 server. (CVE-2006-4343)
[Tavis Ormandy and Will Drewry, Google Security Team]
This tidies up verify parameters and adds support for integrated policy
checking.
Add support for policy related command line options. Currently only in smime
application.
WARNING: experimental code subject to change.
relates to SSL_CTX flags and the use of "external" session caching. The
existing flag, "SSL_SESS_CACHE_NO_INTERNAL_LOOKUP" remains but is
supplemented with a complimentary flag, "SSL_SESS_CACHE_NO_INTERNAL_STORE".
The bitwise OR of the two flags is also defined as
"SSL_SESS_CACHE_NO_INTERNAL" and is the flag that should be used by most
applications wanting to implement session caching *entirely* by its own
provided callbacks. As the documented behaviour contradicted actual
behaviour up until recently, and since that point behaviour has itself been
inconsistent anyway, this change should not introduce any compatibility
problems. I've adjusted the relevant documentation to elaborate about how
this works.
Kudos to "Nadav Har'El" <nyh@math.technion.ac.il> for diagnosing these
anomalies and testing this patch for correctness.
PR: 311
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:
New macros SSL[_CTX]_set_msg_callback_arg().
Message callback imlementation for SSL 3.0/TLS 1.0 (no SSL 2.0 yet).
New '-msg' option for 'openssl s_client' and 'openssl s_server'
that enable a message callback that displays all protocol messages.
In ssl3_get_client_hello (ssl/s3_srvr.c), generate a fatal alert if
client_version is smaller than the protocol version in use.
Also change ssl23_get_client_hello (ssl/s23_srvr.c) to select TLS 1.0
if the client demanded SSL 3.0 but only TLS 1.0 is enabled; then the
client will at least see that alert.
Fix SSL[_CTX]_ctrl prototype (void * instead of char * for generic
pointer).
Add/update some OpenSSL copyright notices.
Both have per-SSL_CTX defaults.
These new values can be set by calling SSL[_CTX]_[callback_]ctrl
with codes SSL_CTRL_SET_MSG_CALLBACK and SSL_CTRL_SET_MSG_CALLBACK_ARG.
So far, the callback is never actually called.
Also rearrange some SSL_CTX struct members (some exist just in
SSL_CTXs, others are defaults for SSLs and are either copied
during SSL_new, or used if the value in the SSL is not set;
these three classes of members were not in a logical order),
and add some missing assignments to SSL_dup.
See the commit log message for that for more information.
NB: X509_STORE_CTX's use of "ex_data" support was actually misimplemented
(initialisation by "memset" won't/can't/doesn't work). This fixes that but
requires that X509_STORE_CTX_init() be able to handle errors - so its
prototype has been changed to return 'int' rather than 'void'. All uses of
that function throughout the source code have been tracked down and
adjusted.
setting stack (actually, array) values in ex_data. So only increment the
global counters if the underlying CRYPTO_get_ex_new_index() call succeeds.
This change doesn't make "ex_data" right (see the comment at the head of
ex_data.c to know why), but at least makes the source code marginally less
frustrating.
His comments are:
. adds use of replay cache to protect against replay attacks
. adds functions kssl_tgt_is_available() and
kssl_keytab_is_available() which are used within s3_lib.c
and ssl_lib.c to determine at runtime whether or not
KRB5 ciphers can be supported during the current session.
an SSL_CTX's session cache, it is necessary to compare the ssl_version at
the same time (a conflict is defined, courtesy of SSL_SESSION_cmp(), as a
matching id/id_length pair and a matching ssl_version). However, the
SSL_SESSION that will result from the current negotiation does not
necessarily have the same ssl version as the "SSL_METHOD" in use by the
SSL_CTX - part of the work in a handshake is to agree on an ssl version!
This is fixed by having the check function accept an SSL pointer rather
than the SSL_CTX it belongs to.
[Thanks to Lutz for illuminating the full extent of my stupidity]
the ID will be padded out to 16 bytes if the callback attempted to generate
a shorter one. The problem is that the uniqueness checking function used in
callbacks may mistakenly think a 9-byte ID is unique when in fact its
padded 16-byte version is not. This makes the checking function detect
SSLv2 cases, and ensures the padded form is checked rather than the shorter
one passed by the callback.
SSL/TLS session IDs in a server. According to RFC2246, the session ID is an
arbitrary value chosen by the server. It can be useful to have some control
over this "arbitrary value" so as to choose it in ways that can aid in
things like external session caching and balancing (eg. clustering). The
default session ID generation is to fill the ID with random data.
The callback used by default is built in to ssl_sess.c, but registering a
callback in an SSL_CTX or in a particular SSL overrides this. BTW: SSL
callbacks will override SSL_CTX callbacks, and a new SSL structure inherits
any callback set in its 'parent' SSL_CTX. The header comments describe how
this mechanism ticks, and source code comments describe (hopefully) why it
ticks the way it does.
Man pages are on the way ...
[NB: Lutz was also hacking away and helping me to figure out how best to do
this.]
DECLARE/IMPLEMENT macros now exist to create type (and prototype) safe
wrapper functions that avoid the use of function pointer casting yet retain
type-safety for type-specific callbacks. However, most of the usage within
OpenSSL itself doesn't really require the extra function because the hash
and compare callbacks are internal functions declared only for use by the
hash table. So this change catches all those cases and reimplements the
functions using the base-level LHASH prototypes and does per-variable
casting inside those functions to convert to the appropriate item type.
The exception so far is in ssl_lib.c where the hash and compare callbacks
are not static - they're exposed in ssl.h so their prototypes should not be
changed. In this last case, the IMPLEMENT_LHASH_*** macros have been left
intact.
casts) used in the lhash code are about as horrible and evil as they can
be. For starters, the callback prototypes contain empty parameter lists.
Yuck.
This first change defines clearer prototypes - including "typedef"'d
function pointer types to use as "hash" and "compare" callbacks, as well as
the callbacks passed to the lh_doall and lh_doall_arg iteration functions.
Now at least more explicit (and clear) casting is required in all of the
dependant code - and that should be included in this commit.
The next step will be to hunt down and obliterate some of the function
pointer casting being used when it's not necessary - a particularly evil
variant exists in the implementation of lh_doall.
