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]
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.]
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
After some messing around this seems to work but needs
a few more tests. Working out the syntax for sk_set_cmp_func()
(cast it to a function that itself returns a function pointer)
was painful :-(
Needs some testing to see what other compilers think of this
syntax.
Also needs similar stuff for ASN1_SET_OF etc etc.
was a really bad idea. For example, the following:
#include <x509.h>
#include <bio.h>
#include <asn1.h>
would make sure that things like ASN1_UTCTIME_print() wasn't defined
unless you moved the inclusion of bio.h to above the inclusion of
x509.h. The reason is that x509.h includes asn1.h, and the
declaration of ASN1_UTCTIME_print() depended on the definition of
HEADER_BIO_H. That's what I call an obscure bug.
Instead, this change makes sure that whatever header files are needed
for the correct process of one header file are included automagically,
and that the definitions of, for example, BIO-related things are
dependent on the absence of the NO_{foo} macros. This is also
consistent with the way parts of OpenSSL can be excluded at will.
"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order. Thusly fixed.
designed for that. This removes the potential error to mix data and
function pointers.
Please note that I'm a little unsure how incorrect calls to the old
ctrl functions should be handled, in som cases. I currently return 0
and that's it, but it may be more correct to generate a genuine error
in those cases.
as a shared library without RSA. Use #ifndef NO_SSL2 instead of
NO_RSA in ssl/s2*.c.
Submitted by: Kris Kennaway <kris@hub.freebsd.org>
Modified by Ulf Möller
returns int (1 = ok, 0 = not seeded). New function RAND_add() is the
same as RAND_seed() but takes an estimate of the entropy as an additional
argument.
yet.
Add a function X509_STORE_CTX_purpose_inherit() which implements the logic
of "inheriting" purpose and trust from a parent structure and using a default:
this will be used in the SSL code and possibly future S/MIME.
Partial documentation of the 'verify' utility. Still need to document how all
the extension checking works and the various error messages.
In case of a restart, v[0] and v[1] were incorrectly initialised.
This was interpreted by ssl3_get_client_key_exchange as an RSA decryption
failure (don't ask me why) and caused it to create a _random_ master key
instead (even weirder), which obviously led to incorrect input to
ssl3_generate_master_secret and thus caused "block cipher pad is
wrong" error messages from ssl3_enc for the client's Finished message.
Arrgh.
