FdaSilvaYY [Fri, 14 Oct 2016 16:25:14 +0000 (18:25 +0200)]
Fix style issue
Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1694)
FdaSilvaYY [Sun, 13 Mar 2016 13:07:50 +0000 (14:07 +0100)]
Constify command options
Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1694)
Xiaoyin Liu [Mon, 26 Sep 2016 01:28:02 +0000 (21:28 -0400)]
Fix typo
I think the second "VC-WIN32" should be "VC-WIN64". Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
CLA: trivial
Richard Levitte [Wed, 12 Oct 2016 22:08:55 +0000 (00:08 +0200)]
Remove automatic RPATH - adapt shlib_wrap.sh
Looking for something starting with '-Wl,-rpath,' isn't good enough,
as someone might give something like '-Wl,--enable-new-dtags,-rpath,/PATH'.
Looking for ',-rpath,' should be safe enough.
We could remove the preloading stuff entirely, but just in case the
user has chosen to given RPATH setting arguments at configuration,
we'd better make sure testing will still work. Fair warning, there
are some configuration options that do not work with preloaded OpenSSL
libraries, such as the sanity checking ones.
Richard Levitte [Wed, 12 Oct 2016 15:05:35 +0000 (17:05 +0200)]
Remove automatic RPATH - add user rpath support
Make Configure recognise -rpath and -R to support user added rpaths
for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the
Unix Makefile, which the users can use as follows:
Richard Levitte [Wed, 12 Oct 2016 15:18:11 +0000 (17:18 +0200)]
Remove automatic RPATH
Before OpenSSL 1.1.0, binaries were installed in a non-standard
location by default, and runpath directories were therefore added in
those binaries, to make sure the executables would be able to find the
shared libraries they were linked with.
With OpenSSL 1.1.0 and on, binaries are installed in standard
directories by default, and the addition of runpath directories is
therefore not needed any more.
Richard Levitte [Wed, 12 Oct 2016 13:30:43 +0000 (15:30 +0200)]
Add support for C++ in Configurations/unix-Makefile.tmpl
Note that it relies on a trick from Configure, where file names for
object files made from C++ source get '.cc' replaced with '_cc.o' to
recognise them. This is needed so the correct compiler is used when
linking binaries.
Richard Levitte [Wed, 12 Oct 2016 13:30:08 +0000 (15:30 +0200)]
Add support for C++ in Configure
A note: this will form object file names by changing '.cc' to
'_cc.o'. This will permit other configuration code to recognise these
object files were built for C++ rather than C.
David Benjamin [Mon, 10 Oct 2016 16:01:24 +0000 (12:01 -0400)]
Remove trailing whitespace from some files.
The prevailing style seems to not have trailing whitespace, but a few
lines do. This is mostly in the perlasm files, but a few C files got
them after the reformat. This is the result of:
Matt Caswell [Fri, 30 Sep 2016 09:50:57 +0000 (10:50 +0100)]
Remove the special case processing for finished construction
tls_construct_finished() used to have different arguments to all of the
other construction functions. It doesn't anymore, so there is no neeed to
treat it as a special case.
Matt Caswell [Fri, 30 Sep 2016 09:38:32 +0000 (10:38 +0100)]
Harmonise setting the header and closing construction
Ensure all message types work the same way including CCS so that the state
machine doesn't need to know about special cases. Put all the special logic
into ssl_set_handshake_header() and ssl_close_construct_packet().
Matt Caswell [Thu, 29 Sep 2016 21:40:15 +0000 (22:40 +0100)]
Rename ssl_set_handshake_header2()
ssl_set_handshake_header2() was only ever a temporary name while we had
to have ssl_set_handshake_header() for code that hadn't been converted to
WPACKET yet. No code remains that needed that so we can rename it.
Matt Caswell [Thu, 29 Sep 2016 10:43:37 +0000 (11:43 +0100)]
Add the WPACKET_reserve_bytes() function
WPACKET_allocate_bytes() requires you to know the size of the data you
are allocating for, before you create it. Sometimes this isn't the case,
for example we know the maximum size that a signature will be before we
create it, but not the actual size. WPACKET_reserve_bytes() enables us to
reserve bytes in the WPACKET, but not count them as written yet. We then
subsequently need to acall WPACKET_allocate_bytes to actually count them as
written.
Matt Caswell [Thu, 29 Sep 2016 13:26:36 +0000 (14:26 +0100)]
Remove tls12_copy_sigalgs_old()
This was a temporary function needed during the conversion to WPACKET. All
callers have now been converted to the new way of doing this so this
function is no longer required.
Matt Caswell [Wed, 28 Sep 2016 10:15:36 +0000 (11:15 +0100)]
Delete some unneeded code
Some functions were being called from both code that used WPACKETs and code
that did not. Now that more code has been converted to use WPACKETs some of
that duplication can be removed.
Richard Levitte [Wed, 28 Sep 2016 19:28:00 +0000 (21:28 +0200)]
apps/apps.c: initialize and de-initialize engine around key loading
Before loading a key from an engine, it may need to be initialized.
When done loading the key, we must de-initialize the engine.
(if the engine is already initialized somehow, only the reference
counter will be incremented then decremented)
David Woodhouse [Wed, 28 Sep 2016 12:08:45 +0000 (13:08 +0100)]
Call ENGINE_init() before trying to use keys from engine
When I said before that s_client "used to work in 1.0.2" that was only
partly true. It worked for engines which provided a default generic
method for some key type, because it called ENGINE_set_default() and
that ended up being an implicit initialisation and functional refcount.
But an engine which doesn't provide generic methods doesn't get initialised,
and then when you try to use it you get an error:
cannot load client certificate private key file from engine 140688147056384:error:26096075:engine routines:ENGINE_load_private_key:not initialised:crypto/engine/eng_pkey.c:66:
unable to load client certificate private key file
cf. https://github.com/OpenSC/libp11/issues/107 (in which we discover
that engine_pkcs11 *used* to provide generic methods that OpenSSL would
try to use for ephemeral DH keys when negotiating ECDHE cipher suites in
TLS, and that didn't work out very well.)
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1639)
Matt Caswell [Fri, 23 Sep 2016 15:58:11 +0000 (16:58 +0100)]
Fix Use After Free for large message sizes
The buffer to receive messages is initialised to 16k. If a message is
received that is larger than that then the buffer is "realloc'd". This can
cause the location of the underlying buffer to change. Anything that is
referring to the old location will be referring to free'd data. In the
recent commit c1ef7c97 (master) and 4b390b6c (1.1.0) the point in the code
where the message buffer is grown was changed. However s->init_msg was not
updated to point at the new location.
Matt Caswell [Wed, 21 Sep 2016 10:20:18 +0000 (11:20 +0100)]
Add warning about a potential pitfall with WPACKET_allocate_bytes()
If the underlying BUF_MEM gets realloc'd then the pointer returned could
become invalid. Therefore we should always ensure that the allocated
memory is filled in prior to any more WPACKET_* calls.
Russian GOST ciphersuites are vulnerable to the KCI attack because they use
long-term keys to establish the connection when ssl client authorization is
on. This change brings the GOST implementation into line with the latest
specs in order to avoid the attack. It should not break backwards
compatibility.
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
Matt Caswell [Sat, 10 Sep 2016 20:24:40 +0000 (21:24 +0100)]
Fix a hang with SSL_peek()
If while calling SSL_peek() we read an empty record then we go into an
infinite loop, continually trying to read data from the empty record and
never making any progress. This could be exploited by a malicious peer in
a Denial Of Service attack.
Matt Caswell [Fri, 9 Sep 2016 09:53:39 +0000 (10:53 +0100)]
Fix a mem leak in NPN handling
If a server sent multiple NPN extensions in a single ClientHello then a
mem leak can occur. This will only happen where the client has requested
NPN in the first place. It does not occur during renegotiation. Therefore
the maximum that could be leaked in a single connection with a malicious
server is 64k (the maximum size of the ServerHello extensions section). As
this is client side, only occurs if NPN has been requested and does not
occur during renegotiation this is unlikely to be exploitable.