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.
1) Certificate Message with no certs
OpenSSL implementation sends the Certificate message during SSL
handshake, however as per the specification, these have been omitted.
-- RFC 2712 --
CertificateRequest, and the ServerKeyExchange shown in Figure 1
will be omitted since authentication and the establishment of a
master secret will be done using the client's Kerberos credentials
for the TLS server. The client's certificate will be omitted for
the same reason.
-- RFC 2712 --
3) Pre-master secret Protocol version
The pre-master secret generated by OpenSSL does not have the correct
client version.
RFC 2712 says, if the Kerberos option is selected, the pre-master
secret structure is the same as that used in the RSA case.
TLS specification defines pre-master secret as:
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
where client_version is the latest protocol version supported by the
client
The pre-master secret generated by OpenSSL does not have the correct
client version. The implementation does not update the first 2 bytes
of random secret for Kerberos Cipher suites. At the server-end, the
client version from the pre-master secret is not validated.
PR: 1336
- hide the EC_KEY structure definition in ec_lcl.c + add
some functions to use/access the EC_KEY fields
- change the way how method specific data (ecdsa/ecdh) is
attached to a EC_KEY
- add ECDSA_sign_ex and ECDSA_do_sign_ex functions with
additional parameters for pre-computed values
- rebuild libeay.num from 0.9.7
functions and macros.
This change has associated tags: LEVITTE_before_const and
LEVITTE_after_const. Those will be removed when this change has been
properly reviewed.
I have tried to convert 'len' type variable declarations to unsigned as a
means to address these warnings when appropriate, but when in doubt I have
used casts in the comparisons instead. The better solution (that would get
us all lynched by API users) would be to go through and convert all the
function prototypes and structure definitions to use unsigned variables
except when signed is necessary. The proliferation of (signed) "int" for
strictly non-negative uses is unfortunate.
from external cache (using d2i_SSL_SESSION). Perform comparison based on
the cipher's id instead.
Submitted by: Steve Haslam <araqnid@innocent.com>
Reviewed by:
PR: 288
Changes marked "(CHATS)" were sponsored by the Defense Advanced
Research Projects Agency (DARPA) and Air Force Research Laboratory,
Air Force Materiel Command, USAF, under agreement number
F30602-01-2-0537.
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:
'Handshake' protocol structures are kept in memory, including
'msg_type' and 'length'.
(This is in preparation of future support for callbacks that get to
peek at handshake messages and the like.)
His comments are:
First, it corrects a problem introduced in the last patch where the
kssl_map_enc() would intentionally return NULL for valid ENCTYPE
values. This was done to prevent verification of the kerberos 5
authenticator from being performed when Derived Key ciphers were
in use. Unfortunately, the authenticator verification routine was
not the only place that function was used. And it caused core dumps.
Second, it attempt to add to SSL_SESSION the Kerberos 5 Client
Principal Name.
SSL according to RFC 2712. His comment is:
This is a patch to openssl-SNAP-20010702 to support Kerberized SSL
authentication. I'm expecting to have the full kssl-0.5 kit up on
sourceforge by the end of the week. The full kit includes patches
for mod-ssl, apache, and a few text clients. The sourceforge URL
is http://sourceforge.net/projects/kssl/ .
Thanks to a note from Simon Wilkinson I've replaced my KRB5 AP_REQ
message with a real KerberosWrapper struct. I think this is fully
RFC 2712 compliant now, including support for the optional
authenticator field. I also added openssl-style ASN.1 macros for
a few Kerberos structs; see crypto/krb5/ if you're interested.
applications to use EVP. Add missing calls to HMAC_cleanup() and
don't assume HMAC_CTX can be copied using memcpy().
Note: this is almost identical to the patch submitted to openssl-dev
by Verdon Walker <VWalker@novell.com> except some redundant
EVP_add_digest_()/EVP_cleanup() calls were removed and some changes
made to avoid compiler warnings.
yet tighter, and also put some heat on the rest of the library by
insisting (correctly) that compare callbacks used in stacks are prototyped
with "const" parameters. This has led to a depth-first explosion of
compiler warnings in the code where 1 constification has led to 3 or 4
more. Fortunately these have all been resolved to completion and the code
seems cleaner as a result - in particular many of the _cmp() functions
should have been prototyped with "const"s, and now are. There was one
little problem however;
X509_cmp() should by rights compare "const X509 *" pointers, and it is now
declared as such. However, it's internal workings can involve
recalculating hash values and extensions if they have not already been
setup. Someone with a more intricate understanding of the flow control of
X509 might be able to tighten this up, but for now - this seemed the
obvious place to stop the "depth-first" constification of the code by
using an evil cast (they have migrated all the way here from safestack.h).
Fortunately, this is the only place in the code where this was required
to complete these type-safety changes, and it's reasonably clear and
commented, and seemed the least unacceptable of the options. Trying to
take the constification further ends up exploding out considerably, and
indeed leads directly into generalised ASN functions which are not likely
to cooperate well with this.
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.
While modifying the sources, I found some inconsistencies on the use of
s->cert vs. s->session->sess_cert; I don't know if those could
really have caused problems, but possibly this is a proper bug-fix
and not just a clean-up.
called sess_cert instead of just cert. This is in preparation of further
changes: Probably often when s->session->sess_cert is used, we should
use s->cert instead; s->session->sess_cert should be a new structure
containing only the stuff that is for just one connection (e.g.
the peer's certificate, which the SSL client implementations currently
store in s->session->[sess_]cert, which is a very confusing thing to do).
Submitted by:
Reviewed by:
PR:
