[openssl-dev] [openssl.org #2459] ecdsa_method declaration prevents use in implementing a dynamic engine

[Tim Hudson via RT]

Note: the interface suggested by Doug was added by Steve Henson into master in
commit 94c2f77a62be7079ab1893ab14b18a30157c4532 and OpenSSL 1.0.2 in commit
7c23127fde8fe94af914961eb7702caa7f256a05 and {set,get}_app_data into master in
commit 387b844ffdc79b733be0b1dbaddd2ac64a6c1192 and OpenSSL 1.0.2 in commit
654ae3d6ad61367060ffc20db11c7cf86b8f95b8

Currently there is no init or finish function in the method.

Tim.

___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: Building win64 openssl static library with no-ssl3 option fails on 1.0.1j

[Tim Hudson]

On 18/10/2014 3:07 AM, Arthur Ramsey wrote:
> Hello,
>
> I want to disable SSLv3 for a tomcat / tcnative deployment on
> Windows.  Tomcat lacks the ability to disable SSLv3 while retaining
> TLSv1.1 and TLSv1.2, so I'm attempting to disable SSLv3 at build time
> with no-ssl3.  This was successful on Linux, but not on Windows.  I
> was able to build on Windows with the following procedure.
>
> 1.
> Install Strawbery perl
> 2.
> Open Visual Studio x64 Cross Tools Command prompt
> %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 
> 9.0\VC\vcvarsall.bat" x86_amd64
> 3.
> Change to the directory containing openssl sources
> cd C:\openssl-1.0.1j
> 4.
> Configure the openssl build
> perl Configure VC-WIN64A no-ssl2
> 5.
> Prepare the target environment
> ms\do_win64a
> 6.
> Clean up previous compliation
> nmake -f ms\nt.mak clean
> 7.
> Build
> nmake -f ms\nt.mak
> 8.
> Test the build
> nmake -f ms\nt.mak test
>
> Once I add the no-ssl3 option, compilation of the 64-bit static
> library fails with the following.
>
> Building OpenSSL
> lib /nologo /out:out32\ssleay32.lib 
> @C:\Users\arthurr\AppData\Local\Temp\nm96B5.tmp
> link /nologo /subsystem:console /opt:ref /debug 
> /out:out32\constant_time_test.exe 
> @C:\Users\arthurr\AppData\Local\Temp\nm96D5.tmp
> LINK : fatal error LNK1181: cannot open input file 'out32\ssleay32.lib'
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
> 9.0\VC\BIN\x86_amd64\link.EXE"' : return code '0x49d'
> Stop.
>
> I see there was a fix for no-ssl3 in 1.0.1j, but it may still be an
> issue with Windows builds?  The error isn't descriptive, but perhaps a
> openssl-dev could try reproducing the issue.  I feel pretty confident
> this a issue with the build scripts for Windows.  I initially tried
> the openssl-users list, but didn't get any responses.

Thanks for the detailed bug report!
Applying this temporary patch to util/mk1mf.pl will resolve this issue.

Tim.

diff --git a/util/mk1mf.pl b/util/mk1mf.pl
index f0c2df0..4d2bbb2 100755
--- a/util/mk1mf.pl
+++ b/util/mk1mf.pl
@@ -671,11 +671,11 @@ foreach (values %lib_nam)
$lib_obj=$lib_obj{$_};
local($slib)=$shlib;

-   if (($_ eq "SSL") && $no_ssl2 && $no_ssl3)
-   {
-   $rules.="\$(O_SSL):\n\n";
-   next;
-   }
+#  if (($_ eq "SSL") && $no_ssl2 && $no_ssl3)
+#  {
+#  $rules.="\$(O_SSL):\n\n";
+#  next;
+#  }

$defs.=&do_defs(${_}."OBJ",$lib_obj,"\$(OBJ_D)",$obj);
$lib=($slib)?" \$(SHLIB_CFLAGS)".$shlib_ex_cflags{$_}:"
\$(LIB_CFLAGS)";



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2204] Contribution [OS: all] [Version openssl-0.9.8m]

[Tim Hudson via RT]

Closing this item - see #3434 which is an overlapping (and more detailed
replacement).
Further discussions on AES wrapping should be added into that ticket and/or
continue on openssl-dev.

Thanks,
Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3436] Platform strategy

[Tim Hudson via RT]

I am closing this item as it is not actually a defect (although we do
appreciate getting rapid feedback on the roadmap).

The discussion in terms of platform strategy should continue on the openssl-dev
mailing list as we work through tackling platform related issues.

Separately I'm looking through the range of systems and the automated building
items that various users have put in place - it is great to see the enthusiasm
for the range of platforms OpenSSL works on.

If you are able to provide access to a platform to the OpenSSL development team
then noting that on openssl-dev would be useful.

Thanks,
Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: BIO_get_accept_socket weirdness

[Tim Hudson]

> Some google engineering (search) will show the the variety of
confusion that this causes in cross-platform code.

Start here for some interesting reading -
http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
You will find *many* exchanges of details about that.

And yes - originally this was (mostly) for being able to start a server
again after stopping it when sockets were remaining in TIME_WAIT state -
but it wasn't implemented as just that and the semantics have varied.

Tim.

Re: [openssl.org #3436] Platform strategy

[Tim Hudson]

On 5/07/2014 1:06 PM, hmbrand via RT wrote:
> I think it is highly thinkable that the dev-team does not have access to 
> proprietary OS's like HP-UX or AIX. Personally I give a shit about AIX, 
> but I value HP-UX a lot and I might be the only one left still releasing 
> software-depots (what HP uses for binary distributions) for a lot of 
> OpenSource products for HP-UX back to 10.20, long dead and gone 
> according to HP itself.

Are you able to provide ssh access into those systems for OpenSSL
development team vendors?

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: BIO_get_accept_socket weirdness

[Tim Hudson]

On 5/07/2014 2:14 PM, Kurt Roeckx wrote:
> On Sat, Jul 05, 2014 at 12:45:37PM -0400, Tim Hudson wrote:
>> If you have SO_REUSEADDR set and a listener already in place you will
>> start a new listener 
> No you won't.  You will get a bind() error:
> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(3, {sa_family=AF_INET, sin_port=htons(3344), 
> sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
>
> Except on windows it seems.

All the world is not (yet) Linux :-) ... and those semantics were
defined log ago - and evolved ... and there is also REUSEPORT (added
later) and a variety of interpretations - but the base REUSEADDR can
indeed behave that way depending on what platform you are on. Linux has
its own slightly different interpretation. Some google engineering
(search) will show the the variety of confusion that this causes in
cross-platform code.

Tim

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: BIO_get_accept_socket weirdness

[Tim Hudson]

On 5/07/2014 9:12 AM, Kurt Roeckx wrote:
> On Sat, Jul 05, 2014 at 08:13:04AM -0400, Eric Covener wrote:
>> On Sat, Jul 5, 2014 at 7:37 AM, Kurt Roeckx  wrote:
>>> Does anybody have an idea why it's trying to do that, and why we
>>> shouldn't just do SO_REUSEADDR the first time?  Was there some
>>> OS that maybe did strange things when trying to use SO_REUSEADDR
>>> and it was already in use?
>> FWLIW: I've seen this pattern in some other proprietary software,
>> where they try hard to not set SO_REUSEADDR unless it appears needed
>> due to a bind failure. But whatever they were working around, it is
>> detrimental to modern Linux where the outgoing TIME_WAIT socket has to
>> also have been opened with SO_REUSEADDR for the reuse to be allowed.
> man socket(7) documents that behavior on Linux.  They also say that
> you ussually don't notice it because most things always set
> SO_REUSEADDR.  So it seems to me like the behavior of that piece
> of code will at least don't do what you want it to do on Linux so
> other than being weird it looks like an other reason to just drop
> it.

If you have SO_REUSEADDR set and a listener already in place you will
start a new listener and who gets the incoming connections is not well
defined.
You need to determine if this is just a time-wait socket stopping the
bind or there is a listener in place. That is the semantics being
handled in the code.

See crypto/bio/bss_acpt.c where the bind_mode is "documented" in a comment:

/* If 0, it means normal, if 1, do a connect on bind failure,
 * and if there is no-one listening, bind with SO_REUSEADDR.
 * If 2, always use SO_REUSEADDR. */


Setting SO_REUSEADDR on always will not result in what you are expecting ...

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #1979] Add uClibc support

[Tim Hudson]

On 30/06/2014 10:23 PM, Salz, Rich wrote:
> Feel free to re-open :)
>
> --  
> Principal Security Engineer
> Akamai Technologies, Cambridge, MA
> IM: rs...@jabber.me; Twitter: RichSalz
>
>
>> -Original Message-
>> From: owner-openssl-...@openssl.org [mailto:owner-openssl-
>> d...@openssl.org] On Behalf Of Kurt Roeckx via RT
>> Sent: Monday, June 30, 2014 6:48 PM
>> To: phil...@redfish-solutions.com
>> Cc: openssl-dev@openssl.org
>> Subject: Re: [openssl.org #1979] Add uClibc support
>>
>> On Tue, Jul 01, 2014 at 12:25:00AM +0200, Rich Salz via RT wrote:
>>> Unsupported platform.
>> Not having read the ticket, uClibc and newlib might be useful to support if
>> possible since they're popular for embedded devices.


They are actively used - but with a case that old and known current
usage (one of the FIPS140 validated platforms is indeed uClibc based) so
closing the ticket in my view is the right approach.
If there is a specific issue with current releases those impacted should
raise a new issue ...

The specific suggested Makefile included in the RT item is also somewhat
rather specific to the snapgear distribution layout ...

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Website Contribution

[Tim Hudson]

On 21/06/2014 9:20 AM, Michael "Croydon" K. wrote:
I would like to see the git website repository also on Github. Exactly 
like it's done with the openssl library.
I would likely going to contribute some improvements since I'm 
thinking the website needs that more than urgent.


Do you have specific areas that you feel need addressing more than others?
The /related/ area has already been tidied up ...

Thanks,
Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors

[Tim Hudson via RT]

On 8/06/2014 11:40 AM, Kurt Roeckx via RT wrote:
> On Sun, Jun 08, 2014 at 12:01:28AM +0200, Tim Hudson via RT wrote:
>> Already fixed in the 1.0.1 stable branch so it is already included in
>> 1.0.1h onwards and 1.0.1m is the current recommended version.
> [...]
>> Can you re-run parfait against the current release version of OpenSSL
>> for that branch - i.e. 1.0.1m
> It seems you have your branches mixed up.  The latest version is
> 1.0.1h.  There is an also an 1.0.0m, but that's from an older
> branch.

Opps - you are right - I did indeed mean *1.0.1h* ... 'm' is in the
1.0.0 branch - and I am requesting is for it to be run against the
current 1.0.1 version not an older version - which was especially
noticeable when it is pointing out an already resolved item.

It is always a good idea to run any tools against the current release
versions for a particular branch - and also handy to see the same
reports against "master" so that the forward development version also
gets items picked up - as it contains the latest not-yet-in-a-release code.

For coverity we use "master" and "OpenSSL_1_0_1-stable"

Tim.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3387] Bug Report with fixes: null pointer and uninitialised memory errors

[Tim Hudson via RT]

On 7/06/2014 7:10 PM, Jenny Yung via RT wrote:
> Hello,
>
> We ran parfait on OpenSSL and found the following errors in openssl-1.0.1g:
>
> 1. Error: Uninitialised memory (CWE 456)
> Possible access to uninitialised memory '&num'
>  at line 267 of 
> components/openssl/openssl-1.0.1/build/sparcv9-wanboot/crypto/evp/bio_b64.c 
> in function 'b64_read'.
> &num allocated at line 146.
> &num uninitialised when ctx->start != 0 at line 221.

Already fixed in the 1.0.1 stable branch so it is already included in
1.0.1h onwards and 1.0.1m is the current recommended version.

commit a41d5174e27c99d1caefd76a8e927c814ede509e
Author: Dr. Stephen Henson 
Date:   Tue May 6 14:07:37 2014 +0100

Initialize num properly.
   
PR#3289
PR#3345
(cherry picked from commit 3ba1e406c2309adb427ced9815ebf05f5b58d155)


> 2. Error: Null pointer dereference (CWE 476)
> Read from null pointer rctx
>  at line 114 of 
> components/openssl/openssl-1.0.1/build/sparcv9-wanboot/crypto/ocsp/ocsp_ht.c 
> in function 'OCSP_REQ_CTX_free'.
>Function OCSP_sendreq_new may return constant 'NULL' at line 
> 171, called at line 491 in function 'OCSP_sendreq _bio'.
>Constant 'NULL' passed into function OCSP_REQ_CTX_free, 
> argument rctx, from call at line 498.
>Null pointer introduced at line 171 in function 
> 'OCSP_sendreq_new'.

This indicates a different issue is present - in that the error handling
path will leak memory.

rctx->iobuf = OPENSSL_malloc(rctx->iobuflen);
if (!rctx->iobuf)
return 0;

So if malloc fails rctx itself isn't freed - so that will leak. That
will need to be looked at too.


> 3. Error: Null pointer dereference (CWE 476)
> Read from null pointer rctx
>  at line 268 of 
> components/openssl/openssl-1.0.1/build/sparcv9-wanboot/crypto/ocsp/ocsp_ht.c 
> in function 'OCSP_sendreq_nbio'.
>Function OCSP_sendreq_new may return constant 'NULL' at line 
> 171, called at line 491 in function 'OCSP_sendreq_bio'.
>Constant 'NULL' passed into function OCSP_sendreq_nbio, 
> argument rctx, from call at line 495.
>Null pointer introduced at line 171 in function 
> 'OCSP_sendreq_new'.

Looks good - but missed other issue with memory leak on malloc failure.

> 4. Error: Null pointer dereference (CWE 476)
> Read from null pointer frag
>  at line 1175 of 
> components/openssl/openssl-1.0.1/build/sparcv9-wanboot/ssl/d1_both.c in 
> function 'dtls1_buffer_message'.
>Function dtls1_hm_fragment_new may return constant 'NULL' at 
> line 189, called at line 1173.
>Null pointer introduced at line 189 in function 
> 'dtls1_hm_fragment_new'.

Looks good.

> The following changes fixes the errors:
>
> 2 --- openssl-1.0.1g/crypto/evp/bio_b64.c.~1~ Tue Jun  3 
> 14:13:33 2014
> 3 +++ openssl-1.0.1g/crypto/evp/bio_b64.c Tue Jun  3 14:14:23 2014
> 4 @@ -143,7 +143,7 @@
> 5
> 6  static int b64_read(BIO *b, char *out, int outl)
> 7 {
> 8 -   int ret=0,i,ii,j,k,x,n,num,ret_code=0;
> 9 +   int ret=0,i,ii,j,k,x,n,num=0,ret_code=0;
>10 BIO_B64_CTX *ctx;
>11 unsigned char *p,*q;

Already covered in previous commits.

>12
>13 --- openssl-1.0.1g/crypto/ocsp/ocsp_ht.c.~1~Tue Jun  3 
> 14:15:18 2014
>14 +++ openssl-1.0.1g/crypto/ocsp/ocsp_ht.cTue Jun  3 
> 14:15:46 2014
>15 @@ -490,6 +490,9 @@
>16
>17 ctx = OCSP_sendreq_new(b, path, req, -1);
>18
>19 +   if (!ctx)
>20 +   return NULL;
>21 +
>22 do
>23 {
>24 rv = OCSP_sendreq_nbio(&resp, ctx);

Looks reasonable - although I don't think the spin loop there is
appropriate - basically with no delay, and no select, this will spin on
a non-blocking retry condition (which is meant to make it back to the
caller to enter their event loop. That is a broader issue to look at.

>25 --- openssl-1.0.1g/ssl/d1_both.c.~1~Tue Jun  3 14:16:25 2014
>26 +++ openssl-1.0.1g/ssl/d1_both.cTue Jun  3 14:17:26 2014
>27 @@ -1172,6 +1172,8 @@
>28
>29 frag = dtls1_hm_fragment_new(s->init_num, 0);
>30
>31 +   if (!frag)
>32 +   return 0;
>33 memcpy(frag->fragment, s->init_buf->data, s->init_num);
>34
>35 if ( is_ccs)

That looks good as a patch.

> Can you integrate this into the next release of OpenSSL?

Can you re-run parfait against the current release version of OpenSSL
for that branch - i.e. 1.0.1m

It would also be helpful to see suggested patch as a separate RT issue -
so we can discuss and track them individually.

Thanks,
Tim.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manage

Re: [openssl.org #3380] OpenSSL 1.0.1h on SGI IRIX

[Tim Hudson]

On 7/06/2014 4:02 AM, Dr. Stephen Henson wrote:
> On Fri, Jun 06, 2014, Mike Bland wrote:
>
>> __func__ is defined in C99. What version of the SGI C compiler are you
>> using? According to the following, as of version 7.4, the -c99 flag
>> should enable this to compile:
>>
>> http://www.sgi.com/products/software/irix/tools/c.html
>>
> Note that VC++ under Windows doesn't support __func__ either. Well at least
> the versions I tested didn't.

Adding in C99 dependencies in the code will run into a lot of non-C99
environments which still are being actively used. 
I think it is time to either decide that C99 is now a requirement (and
there are features in C99 that would be nice to be able to use) or to
decide that code which uses those features shouldn't go in - i.e. don't
use those features so that platforms which don't support C99 are still
supportable.

Either approach leads to things breaking for at least some users ...

In this particular case (the ssl/heartbeat_test.c) the use of __func__
really isn't critical and can easily be changed to not be a C99 __func__
dependency and pass in a test name in the 9 locations rather than the
function name. That would fix the couple of platforms already noted that
had issues.

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2578] s_client bind ip

[Tim Hudson via RT]

On 24/05/2014 11:06 PM, Krzysztof Kwiatkowski via RT wrote:
> Hello,
>
> This patch implements request for ticket 2578. I've also created pull
> request in github that you can find here:
> https://github.com/openssl/openssl/pull/108

Why is there a crypto/objects/obj_xref.h  change mixed in with this patch?
It does not belong there.

Thanks,
Tim.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3345] potential bug in crypto/evp/bio_b64.c

[Tim Hudson]

On 6/05/2014 1:13 PM, Arthur Mesh via RT wrote:
> Coverity run has uncovered the following use of uninitialized local
> variable in b64_read(). This applies to both 1.0.1g and master branch:

Arthur - what version of the coverity analysis tools are you running?
I don't see this in the current scan.coverity.com reported list of items
so either it has been previously looked at or your configuration is
different or your version of tools is different or you are running
across a more recent source drop than we have put into scan.coverity.com
(I suspect the latter is the issue).

If you refer to this issue you will see where the code was introduced.

https://rt.openssl.org/Ticket/Display.html?id=3289

diff --git a/crypto/evp/bio_b64.c b/crypto/evp/bio_b64.c
index 72a2a67..ac6d441 100644
--- a/crypto/evp/bio_b64.c
+++ b/crypto/evp/bio_b64.c
@@ -264,7 +264,7 @@ static int b64_read(BIO *b, char *out, int outl)
}
 
/* we fell off the end without starting */
-   if (j == i)
+   if ((j == i) && (num == 0))


There needs to be a corresponding num=0 initialisation prior to the
immediately preceding for loop.

I have re-opened that RT issue and cross-referenced both the new RT
issue and the original one which introduced the patch.

Thanks,
Tim.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3345] potential bug in crypto/evp/bio_b64.c

[Tim Hudson via RT]

On Tue May 06 05:13:42 2014, arthurm...@gmail.com wrote:
> Coverity run has uncovered the following use of uninitialized local
> variable in b64_read(). This applies to both 1.0.1g and master branch:

See https://rt.openssl.org/Ticket/Display.html?id=3289 which is the patch which
introduced this issue.
I have re-opened that RT issue.

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3289] base64 BIO decoding bug - patch supplied + examples

[Tim Hudson via RT]

Re-opening item.

See https://rt.openssl.org/Ticket/Display.html?id=3345

This patch introduced an uninitialised read.

A num=0 initialisation is required prior to the for loop.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3342] coverity issue 966577

[Tim Hudson]

On 5/05/2014 6:04 PM, Marcus Meissner wrote:
> On Mon, May 05, 2014 at 02:00:32AM +0200, Tim Hudson via RT wrote:
>> 966577 Resource leak
>> 
>>
>> The system resource will not be reclaimed and reused, reducing the future
>> availability of the resource.
>>
>> In init_client_ip: Leak of memory or pointers to system resources
> This is not helpful without more information, or a patch.

The patch is contained in a git pull request against the public github
repository.
I elected to not have separate messages sent out when adding in the git
pull request - which is in a branch with the RT name against it - this
makes any comments or suggested updates or variations on a patch able to
be discussed openly and also makes the patch able to be easily applied
if you are maintaining your own git tree.

See https://github.com/openssl/openssl/pulls

The specific pull request is noted at
https://rt.openssl.org/Ticket/Display.html?id=3342

And it is https://github.com/openssl/openssl/pull/100

Or to look at the actual patch directly see
https://github.com/openssl/openssl/pull/100/files

This is a simple addition of closesocket() calls in the error path
handling in apps/s_socket.c ...

You will see four PR's (and corresponding patches) for coverity detected
issues ...

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3342] coverity issue 966577

[Tim Hudson via RT]

966577 Resource leak


The system resource will not be reclaimed and reused, reducing the future
availability of the resource.

In init_client_ip: Leak of memory or pointers to system resources

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3341] coverity issue 966597

[Tim Hudson via RT]

966597 Uninitialized scalar variable


The variable will contain an arbitrary value left from earlier computations.

In d2i_SSL_SESSION: Use of an uninitialized variable

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3340] coverity issues 966593-966596

[Tim Hudson via RT]

coverity issues 966593-966596

966593 Uninitialized scalar variable The variable will contain an arbitrary
value left from earlier computations. In SRP_create_verifier: Use of an
uninitialized variable

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

[Tim Hudson]

On 2/05/2014 11:49 PM, Salz, Rich wrote:
>> Steve, have you considered trimming the DEFAULT cipher list?
>> It's currently...
>> #define SSL_DEFAULT_CIPHER_LIST  "ALL:!aNULL:!eNULL:!SSLv2"
>> I wonder how many of these ciphers are actually ever negotiated in 
>> real-world use.
> I'm forwarding a bit of internal discussion; hope it's useful.  This is from 
> one of our chief info-sec people:

A set of recommendations from the Mozilla team along with a write up of
how to configure cipher suite selection in a range of servers is at:

https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite

The short form of their recommendation is:

'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:
DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:
DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:
DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:
AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK'

Their rationale is described at
https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic
and the cipher suite you select entirely depends on what your view point
is on a range of issues.

Discussions on what the "One True Ciphersuite List" should be tend to
result in multiple correct answers.

Placing a set of recommendations on the wiki (wiki.openssl.org) along
with their rationale would be a good step to providing a selection of
choices for OpenSSL users.

Tim.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3033] Bug Report: Make Error: can't encode register '%ch' in an instruction requiring REX prefix.

[Tim Hudson via RT]

Closing item as resolved.

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3068] [PATCH] Safari broken ECDHE-ECDSA workaround

[Tim Hudson via RT]

On Tue Jun 04 17:53:41 2013, rob.stradl...@comodo.com wrote:
> The Safari browser on OSX versions 10.8 to 10.8.3 advertises support for
> several ECDHE-ECDSA ciphers but fails to negotiate them.

Closing as resolved.
Ben committed fixes across all branches.

https://github.com/openssl/openssl/commit/cadbbd51c8b4e66515cd3e97754cfeda606c7b15

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured

[Tim Hudson via RT]

Closing item as resolved.
SteveH committed patches across all branches.

Tim

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2538] Code error - bad condition in s3_srvr.c

[Tim Hudson via RT]

On Mon Jun 06 17:23:48 2011, tm...@redhat.com wrote:
> There is code error in s3_srvr.c function ssl3_get_cert_verify().
> The bug was found by Coverity scan.

Closing as resolved.
Andy committed fix across all branches.

https://github.com/openssl/openssl/commit/3b1fb1a0226e29c9d7c79ff7fbde21ef9cac4deb

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2771] [BUG] Openssl 1.0.1 times out when connecting to Outlook Exchange 2007

[Tim Hudson via RT]

On Wed Nov 06 22:15:45 2013, steve wrote:
> On Thu Mar 29 21:17:31 2012, steve wrote:
> > A temporary workaround for this is to apply these two patches to OpenSSL

Closing issue as resolved. Multiple work arounds are in the tree.
SteveH commited across all relevant branches.

https://github.com/openssl/openssl/commit/89bd25eb26bbc2ebceb4cd892e7453337804820c
https://github.com/openssl/openssl/commit/4a1cf50187659e60c5867ecbbc36e37b2605d2c3

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3071] [PATCH] Documentation updates from the wiki

[Tim Hudson via RT]

On Fri Jun 07 20:12:54 2013, fr...@baggins.org wrote:
> This patch is the first submission of what is planned to be a regular
> series of patches. It represents the collected updates made to the pod
> documentation published on the openssl wiki:

Closed as resolved. Patch was committed.

Tim

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3146] [PATCH 1/2] POD: Fix item numbering

[Tim Hudson via RT]

Closed item as resolved.

SteveH committed patch.

https://github.com/openssl/openssl/commit/ed77017b594754240013c378b4f7c10440c94d7a

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3147] [PATCH 2/2] POD: Fix list termination

[Tim Hudson via RT]

Closed as resolved.

SteveH committed patch.
https://github.com/openssl/openssl/commit/c8919dde09d56f03615a52031964bc9a77b26e90

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3172] Duplicated entry in ssl_option_single

[Tim Hudson via RT]

Closed as resolved.

SteveH committed fix.

https://github.com/openssl/openssl/commit/44314cf64d1e51c7493799e77b14ae4e94a4c8cf

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3169] [PATCH] Additional "chain_cert" functions for 1.0.2-dev

[Tim Hudson via RT]

On Mon Nov 11 18:04:23 2013, rob.stradl...@comodo.com wrote:
> This patch, which currently applies successfully against master and
> 1_0_2, adds the following functions:

Closing as resolved.

SteveH committed patch.
https://github.com/openssl/openssl/commit/7b6b246fd393cbe07bc1f0d456140efdff59f971

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3106] [PATCH] Fix build with OPENSSL_NO_NEXTPROTONEG.

[Tim Hudson via RT]

Marking issue as resolved.

SteveH checked in fixes.
https://github.com/openssl/openssl/commit/2911575c6e790541e495927a60121d7546a66962

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3216] Invalid shell syntax "==" in test/testssl (only 0.9.8 and 1.0.0)

[Tim Hudson via RT]

On Tue Jan 07 09:26:25 2014, rainer.j...@kippdata.de wrote:
> File test/testssl in branches 0.9.8 and 1.0.0 contains the line
>
> if [ $protocol == "SSLv3" ] ; then

Closed as resolved.

SteveH committed fixes.
https://github.com/openssl/openssl/commit/080ae6843299c873808c04487d4ccf51624fe618

Tim

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3178] TLS status_request possibly not honored when SSL_set_SSL_CTX is called later on

[Tim Hudson via RT]

On Wed Feb 05 14:14:23 2014, ossl...@velox.ch wrote:
> For the record - this was committed on 16 January ("Omit initial
> status request callback check"):

Marking issue as resolved.

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3183] SSL_set_SSL_CTX() should apply more settings from the SSL_CTX being switched to

[Tim Hudson via RT]

Leaving issue open.

Note: SteveH checked in a partial fix adding in a getter function -
SSL_CTX_get_ssl_method

https://github.com/openssl/openssl/commit/ba168244a14bbd056e502d7daa04cae4aabe9d0d

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3244] ssl/s3_srvr.c: 2 * reading wrong memory

[Tim Hudson via RT]

On Sat Jan 25 11:14:41 2014, dcb...@hotmail.com wrote:
> Hello there,
>
> I just ran the static analyser cppcheck over the source code
> of openssl-1.0.1e

Closed as resolved.

SteveH committed fixes.

https://github.com/openssl/openssl/commit/9614d2c676ffe74ce0c919d9e5c0d622a011cbed
etc

Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3253] Compile issues - Solaris 10

[Tim Hudson via RT]

On Mon Feb 03 15:16:14 2014, steve wrote:
> ...
> I've just committed a fix. Let me know of any problems.

Closed as resolved.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3309] Bug: Missing critical flag for extended key usage not detected in time-stamp verification

[Tim Hudson via RT]

On Wed Apr 16 14:25:34 2014, s...@pdflib.com wrote:
> Am 15.04.14 20:00, schrieb Stephen Henson via RT:
> > I've just added a fix (and to two other cases in the same file). Let
> me know of any problems.

Closed as resolved.

SteveH committed changes across all branches.

https://github.com/openssl/openssl/commit/300b9f0b704048f60776881f1d378c74d9c32fbd
etc


Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3289] base64 BIO decoding bug - patch supplied + examples

[Tim Hudson via RT]

On Wed Apr 02 19:22:14 2014, e...@pobox.com wrote:
> Fixing one of my own bugs, there since SSLeay days I belive :-)

Closing item as resolved.

SteveH committed the fix across all branches ...

https://github.com/openssl/openssl/commit/10378fb5f4c67270b800e8f7c600cd0548874811
https://github.com/openssl/openssl/commit/bfc3424d1fbaf684c812c03e3c6cb8d38d2d6f1d
etc


Thanks,

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3312] OpenSSL :: crypto/mem.c without "memset()" calls?

[Tim Hudson via RT]

On Mon Apr 14 21:53:00 2014, mar...@activezone.de wrote:
> Hi!
>
> I have "checked" the current source code of 'crpyto/mem.c' and I'm a
> little bit suprised that no memset()-calls are made before the free_*()
> functions are entered. I think a "zeroing" of the previous used memory
> is a good solutions to beware for accessing old memory content.

Closed as rejected.

The API for using for sensitive information is OpenSSL_cleanse and in the
malloc wrapping functions at the points you suggest in your proposed path the
length of the allocate buffer simply is not available.

The use of strlen assumes that the provide buffer is a valid NUL terminated
string - and that is not a valid assumption to make.

It is possible to register a set of replacement routines using the
CRYPTO_set_mem_functions function and use those to track the allocated lengths
and then elect to zeroise automatically if that is the behaviour you want to
see used.

Additionally some operating systems provided malloc libraries have options to
control that sort of behaviour at runtime.

Thanks,

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3232] [PATCH] Makefile.org: Fix usage of CC=gcc -m32

[Tim Hudson via RT]

Note: PR#3274 is a duplicate of this issue just closed.

Closing this item too as resolved as SteveH checked in a fix for this in
master, 1.0.1 stable and 1.0.2 stable after the issue was reported.

https://github.com/openssl/openssl/commit/24e20db4aa18ff8a6f67ae7faf80cf2b99f8b74a
https://github.com/openssl/openssl/commit/19a68574a9d1f59c355385a1b64cbd443bf49e00
https://github.com/openssl/openssl/commit/7f6e09b5316928a9da24d2f695d1885a26dd38ec

Thanks,
Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3274] Quoting problem in v1.0.1f

[Tim Hudson via RT]

On Tue Mar 04 16:03:58 2014, dominik.stras...@onespin-solutions.com wrote:
> Hi all,
> the top level Makefile has a small with quoting when CC has an argument.
> The attached mini-patch fixes the problem

Closing item s resolved as SteveH checked in a fix for this in master, 1.0.1
stable and 1.0.2 stable after the issue was reported.

https://github.com/openssl/openssl/commit/24e20db4aa18ff8a6f67ae7faf80cf2b99f8b74a
https://github.com/openssl/openssl/commit/19a68574a9d1f59c355385a1b64cbd443bf49e00
https://github.com/openssl/openssl/commit/7f6e09b5316928a9da24d2f695d1885a26dd38ec

Thanks,
Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3039] Can't Compile openssl-fips-1.1.2: collect2: ld returned 1 exit status

[Tim Hudson via RT]

On Fri May 03 19:05:13 2013, burton.sm...@williams.com wrote:
> Thanks, but after playing with this puzzle for a while I combined the
> configuration options that were supposed to correct it individually.
> It worked.

Closed as resolved.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3046] bug report, openssl 1.0.1e sha1 hash generation

[Tim Hudson via RT]

 The two echo commands are different values (being different actual echo
programs) and hence have different digests.

As a user:

macbuild:~ tjh$ echo -n "12345" | od -x 000 3231 3433 0035 005

As root:

echo -n "12345" | od -x 000 6e2d 3120 3332 3534 000a 011

The root echo is one that does not support the -n option:

macbuild:~ root# echo -n "12345" -n 12345

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3320] Invalid large memory access in openssl due to a bug on the client side

[Tim Hudson via RT]

On 26/04/2014 11:04 PM, Kurt Roeckx via RT wrote:
> Libressl has a patch for this at:
> http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/lib/libssl?id=cb8b51bf2f6517fe96ab0d20c4d9bba2eef1b67c
>
> I believe that patch is not really the correct fix.
>
> My understanding is that "tot" is what is already written, and
> that "len" is until where we want to write and so that len should
> never be smaller than tot and I think we should instead find out
> why len can be smaller then tot and fix that instead.

Actually the code should check that the caller has violated the API
requirements (that the buffer and len values in subsequent calls must
match the original call when a non-blocking IO reports incomplete) and
report an error at that point. Silently truncating the request isn't
really the right behaviour.

The referenced note from the list at
http://marc.info/?l=openssl-dev&m=139809485525663&w=2
 makes the
circumstances to trigger this clear.

i=SSL_write(s,buf,len);

/* assuming that the non-blocking handling returns -1 indicating buffer
is not yet (completely) written */

/* this is what the API requires - recalling with the same parameters */
i=SSL_write(s,buf,len);

/* this is what the caller did ... and that leaves tot > len if less
than someval bytes have gone out between the first call and then the
rest of the pending bytes make it out in this call then bingo we get the
library writing out a large buffer because it isn't checking ... */
i=SSL_write(s,buf,len-someval);

The actual effect is that if a user incorrectly calls the API the
library will (under the right set of circumstances which are not that
unusual but neither the typical context) actually send out beyond the
number of bytes the user is expecting to see sent from the buffer
because of the n = (len - tot) when tot > len and that is undesirable
behaviour and well beyond the 'len' argument of the call - thereby
allowing the users incorrect use of the API to turn into their leakage
of whatever happens to be beyond the buffer.

BUT (and this is the important thing) the circumstances described as
required to produce this context get checked in ssl3_write_pending to
make sure that len cannot actually be smaller than the previous write.

if ((s->s3->wpend_tot > (int)len)

The right fix is perhaps to add in the following check ...

if ( len < tot)
{
SSLerr(SSL_F_SSL3_WRITE_BYTES,SSL_R_BAD_LENGTH);
return(-1);
}

I've created a pull request for this at
https://github.com/openssl/openssl/pull/83

Thanks,
Tim.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3320] Invalid large memory access in openssl due to a bug on the client side

[Tim Hudson]

On 26/04/2014 11:04 PM, Kurt Roeckx via RT wrote:
> Libressl has a patch for this at:
> http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/lib/libssl?id=cb8b51bf2f6517fe96ab0d20c4d9bba2eef1b67c
>
> I believe that patch is not really the correct fix.
>
> My understanding is that "tot" is what is already written, and
> that "len" is until where we want to write and so that len should
> never be smaller than tot and I think we should instead find out
> why len can be smaller then tot and fix that instead.

Actually the code should check that the caller has violated the API
requirements (that the buffer and len values in subsequent calls must
match the original call when a non-blocking IO reports incomplete) and
report an error at that point. Silently truncating the request isn't
really the right behaviour.

The referenced note from the list at
http://marc.info/?l=openssl-dev&m=139809485525663&w=2
 makes the
circumstances to trigger this clear.

i=SSL_write(s,buf,len);

/* assuming that the non-blocking handling returns -1 indicating buffer
is not yet (completely) written */

/* this is what the API requires - recalling with the same parameters */
i=SSL_write(s,buf,len);

/* this is what the caller did ... and that leaves tot > len if less
than someval bytes have gone out between the first call and then the
rest of the pending bytes make it out in this call then bingo we get the
library writing out a large buffer because it isn't checking ... */
i=SSL_write(s,buf,len-someval);

The actual effect is that if a user incorrectly calls the API the
library will (under the right set of circumstances which are not that
unusual but neither the typical context) actually send out beyond the
number of bytes the user is expecting to see sent from the buffer
because of the n = (len - tot) when tot > len and that is undesirable
behaviour and well beyond the 'len' argument of the call - thereby
allowing the users incorrect use of the API to turn into their leakage
of whatever happens to be beyond the buffer.

BUT (and this is the important thing) the circumstances described as
required to produce this context get checked in ssl3_write_pending to
make sure that len cannot actually be smaller than the previous write.

if ((s->s3->wpend_tot > (int)len)

The right fix is perhaps to add in the following check ...

if ( len < tot)
{
SSLerr(SSL_F_SSL3_WRITE_BYTES,SSL_R_BAD_LENGTH);
return(-1);
}

I've created a pull request for this at
https://github.com/openssl/openssl/pull/83

Thanks,
Tim.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: TLS and bad record mac

[Tim Hudson]

Gregory BELLIER wrote:
I added a cipher in OpenSSL and NSS. I would like to send an email with 
SMTPs from a modified Thunderbird (because of NSS) to a postfix.

The TLS negociation is between NSS and OpenSSL.

[snip]

Do you have any hint in what could be wrong?


Use the -state -debug flags for s_client and s_server to trace each end when 
your modified NSS is at the other end. That will provide you with a lot more 
information to assist in figuring out what you've done wrong in the code.


i.e. point modified thunderbird at a modified s_server with -state -debug 
enabled.

Tim.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2046] OpenSSL 1.0.0 beta 3 ASM fails on z/Linux 64-bit

[Tim Hudson via RT]

> I kicked off some builds last night as I was curious as to the answer to 
> the question - 0.9.8d fails in make test, 0.9.8k passes in make test.

The 1.0.0 beta 3 fails with the SHA1 asm code and in the AES asm code.
I haven't had a chance to look into this in any detail - just noting that the 
out-of-the-box build isn't working. ./config -no-asm works so the issues are 
all 
in the asm code.

0.9.8k passes make test, 0.9.8d fails make test in BN code.

./config
make
make test

tjh:~/work/openssl-1.0.0-beta3/test> gdb sha1test
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "s390x-suse-linux"...ruUsing host libthread_db 
library "/lib64/libthread_db.so.1".

(gdb) run
Starting program: /home/tjh/work/openssl-1.0.0-beta3/test/sha1test

Program received signal SIGILL, Illegal instruction.
sha1_block_data_order () at sha1-s390x.s:13
13  lg  %r0,16(%r15)
Current language:  auto; currently asm
(gdb)


Linux somewhere 2.6.16.21-0.8-default #1 SMP Mon Jul 3 18:25:39 UTC 2006 s390x 
s390x s390x GNU/Linux

tjh:~/work/openssl-1.0.0-beta3> gcc -v
Using built-in specs.
Target: s390x-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man 
--libdir=/usr/lib64 --libexecdir=/usr/lib64 
--enable-languages=c,c++,objc,fortran,java --enable-checking=release 
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp 
--enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib 
--with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit 
--enable-libstdcxx-allocator=new --without-system-libunwind --with-tune=z9-109 
--with-arch=z900 --with-long-double-128 --host=s390x-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)

tjh:~/work/openssl-1.0.0-beta3> cat /proc/cpuinfo
vendor_id   : IBM/S390
# processors: 1
bogomips per cpu: 888.01
processor 0: version = FF,  identification = 0117C9,  machine = 2064




PGP.sig
Description: PGP signature

Re: gnutls fails to verify server sertificate while openssl works

[Tim Hudson]

Peter Volkov wrote:

CC'ing openssl developers for their opinions, since I think this
behavior better to have consistent or configurable. Description of the
problem is here:


Placing this in context - connect with internet explorer or firefox to 
https://metasploit.com/ and you will see that both of those independent 
implementations see nothing wrong with the certificate chain and handle the 
redirect to http://metasploit.com/ without and errors or warnings.


Implementations typically take the list of certificates as untrusted 
certificates to add into the process of walking the certificate chain to a 
trusted root certificate. There are pragmatic reasons for doing it this way.


From an interoperability point of view remember the adage - "Be strict in what 
you generate, be liberal in what you accept"


Tim.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ssl teses forbidden in FIPS mode

[Tim Hudson]

The Doctor wrote:

That being said, how do you get openssl to compile with FIPS
and be backwards compatable at the same time?


That is what the FIPS mode is for - the library built supports all algorithms 
and when in FIPS mode it disables the use of non-approved algorithms.


A single application can work in both FIPS and non-FIPS mode. You can add in 
code to choose which mode to be in on a per-connection basis if that is what 
your application requires.


See the usage of FIPS_mode_set()

Note also that due to an implementation quirk you need to clear the currently 
set RNG when switching back into FIPS mode.


i.e.
RAND_set_rand_method(NULL);
FIPS_set_mode(1);

Tim.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: bad value returned by i2d_RSAPublicKey( RSA, NULL )

[Tim Hudson]

William Estrada wrote:
i2d_RSAPublicKey( RSA, NULL ) is to be used to get the size of an RSA 
structure.


Yes it can and it does. It returns the value for the *public* key - the rest of 
your code is looking at the *private* key.


Change the line:
  Len = i2d_RSAPublicKey( My_RSA, NULL );
To this:
  Len = i2d_RSAPrivateKey( My_RSA, NULL );

And then you get the expected output (although printing out the pointer to the 
structure as an integer isn't exactly all that useful).


Size: 1024, Len: 608, RSA: 0
Size: 1024, Len: 608, RSA: 135062744

Public and private keys contain different values.
Have a look at things using 'openssl rsa'

Write the output of i2d for a public key out to a file and then:
  openssl rsa -text -noout -inform der -in public.der
and write the output of i2d for a private key out to a file and then:
  openssl rsa -text -noout -inform der -in private.der

Tim.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: openssl speed RSA

[Tim Hudson]

Paul Bouché wrote:
I would like to know what the bit length of the public and private keys 

> for the test executed with openssl speed rsa

The keys are 512bit, 1024bit, 2048bit, 4096bit as stated in the output from the 
program.


The actual keys are in the header file testrsa.h in the apps directory.

To write them out nicely you can compile the following in the 'apps' directory 
with gcc -o x x.c and run and then use

openssl rsa -inform d -in rsa0.der -text -noout
(repeat with rsa1.der, rsa2.der, rsa3.der)

Alternatively the keys are all listed below.

Tim.

---8<---

#include 
#include "testrsa.h"

#define RSA_NUM 4

int main(int argc,char *argv[])
{
  static unsigned char *rsa_data[RSA_NUM]=
  {test512,test1024,test2048,test4096};
  static int rsa_data_length[RSA_NUM]={
  sizeof(test512),sizeof(test1024),
  sizeof(test2048),sizeof(test4096)};
  int i,l;
  FILE *fp=NULL;
  char buf[BUFSIZ];

  for(i=0;i openssl rsa -text -noout -inform d -in 
rsa0.der
Private-Key: (512 bit)
modulus:
00:d6:33:b9:c8:fb:4f:3c:7d:c0:01:86:d0:e7:a0:
55:f2:95:93:cc:4f:b7:5b:67:5b:94:68:c9:34:15:
de:a5:2e:1c:33:c2:6e:fc:34:5e:71:13:b7:d6:ee:
d8:a5:65:05:72:87:a8:b0:77:fe:57:f5:fc:5f:55:
83:87:dd:57:49
publicExponent: 65537 (0x10001)
privateExponent:
00:a7:f7:91:c5:0f:84:57:dc:07:f7:6a:7f:60:52:
b3:72:f1:66:1f:7d:97:3b:9e:b6:0a:8f:8c:cf:42:
23:00:04:d4:28:0e:1c:90:c4:11:25:25:a5:93:a5:
2f:70:02:df:81:9c:49:03:a0:f8:6d:54:2e:26:de:
aa:85:59:a8:31
prime1:
00:eb:47:d7:3b:f6:c3:dd:5a:46:c5:b9:2b:9a:a0:
09:8f:a6:fb:f3:78:7a:33:70:9d:0f:42:6b:13:68:
24:d3:15
prime2:
00:e9:10:b0:b3:0d:e2:82:68:77:8a:6e:7c:da:bc:
3e:53:83:fb:d6:22:e7:b5:ae:6e:80:da:00:55:97:
c1:d0:65
exponent1:
4c:f8:73:b1:6a:49:29:61:1f:46:10:0d:f3:c7:e7:
58:d7:88:15:5e:94:9b:bf:7b:a2:42:58:45:41:0c:
cb:01
exponent2:
12:11:ba:31:57:9d:3d:11:0e:5b:8c:2f:5f:e2:02:
4f:05:47:8c:15:8e:b3:56:3f:b8:fb:ad:d4:f4:fc:
10:c5
coefficient:
18:a1:29:99:5b:d9:c8:d4:fc:49:7a:2a:21:2c:49:
e4:4f:eb:ef:51:f1:ab:6d:fb:4b:14:e9:4b:52:b5:
82:2c


[EMAIL PROTECTED] ~/work/openssl/apps> openssl rsa -text -noout -inform d -in 
rsa1.der
Private-Key: (1024 bit)
modulus:
00:dc:98:43:e8:3d:43:5b:e4:05:cd:d0:a9:3e:cb:
83:75:f6:b5:a5:9f:6b:e9:34:41:29:18:fa:6a:55:
4d:70:fc:ec:ae:87:38:0a:20:a9:c0:45:77:6e:57:
60:57:f4:ed:96:22:cb:8f:e1:33:3a:17:1f:ed:37:
a5:6f:eb:a6:bc:12:80:1d:53:bd:70:eb:21:76:3e:
c9:2f:1a:45:24:82:ff:cd:59:32:06:2e:12:3b:23:
78:ed:12:3d:e0:8d:f9:67:4f:37:4e:47:02:4c:2d:
c0:4f:1f:b3:94:e1:41:2e:2d:90:10:fc:82:91:8b:
0f:22:d4:f2:fc:2c:ab:53:55
publicExponent: 65537 (0x10001)
privateExponent:
2b:cc:3f:8f:58:ba:8b:00:16:f6:ea:3a:f0:30:d0:
05:17:da:b0:eb:9a:2d:4f:26:b0:d6:38:c1:eb:f5:
d8:3d:1f:70:f7:7f:f4:e2:cf:51:51:79:88:fa:e8:
32:0e:7b:2d:97:f2:fa:ba:27:c5:9c:d9:c5:eb:8a:
79:52:3c:64:34:7d:c2:cf:28:c7:4e:d5:43:0b:d1:
a6:ca:6d:03:2d:72:23:bc:6d:05:fa:16:09:2f:2e:
5c:b6:ee:74:dd:d2:48:8e:36:0c:06:3d:4d:e5:10:
82:eb:6a:f3:4b:9f:d6:ed:11:b1:6e:ec:f4:fe:8e:
75:94:20:2f:cb:ac:46:f1
prime1:
00:f9:8c:a3:85:b1:dd:29:af:65:c1:33:f3:95:c5:
52:68:0b:d4:f1:e5:0e:02:9f:4f:fa:77:dc:46:9e:
c7:a6:e4:16:29:da:b0:07:cf:5b:a9:12:8a:dd:63:
0a:de:2e:8c:66:8b:8c:dc:19:a3:7e:f4:3b:d0:1a:
8c:a4:c2:e1:d3
prime2:
00:e2:4c:05:f2:04:86:4e:61:43:db:b0:b9:96:86:
52:2c:ca:8d:7b:ab:0b:13:0d:7e:38:5b:e2:2e:7b:
0e:e7:19:99:38:e7:f2:21:bd:85:85:e3:fd:28:77:
20:31:71:2c:d0:ff:fb:2e:af:85:b4:86:ca:f3:bb:
ca:aa:0f:95:37
exponent1:
0e:41:9a:95:e8:b3:59:ce:4b:61:de:35:ec:38:79:
9c:b8:10:52:41:63:ab:82:ae:6f:00:a9:f4:de:dd:
49:0b:7e:b8:a5:65:a9:0c:8f:8f:f9:1f:35:c6:92:
b8:5e:b0:66:ab:52:40:c0:b6:36:6a:7d:80:46:04:
02:e5:9f:41
exponent2:
00:c0:ad:cc:4e:21:ee:1d:24:91:fb:a7:80:8d:9a:
b6:b3:2e:8f:c2:e1:82:df:69:18:b4:71:ff:a6:65:
de:ed:84:8d:42:b7:b3:21:69:56:1c:07:60:51:29:
04:ff:34:06:dd:b9:67:2c:7c:04:93:0e:46:15:bb:
2a:b7:1b:e7:87
coefficient:
78:da:5d:07:51:0c:16:7a:9f:29:20:84:0d:42:fa:
d7:00:d8:77:7e:b0:b0:6b:d6:5b:53:b8:9b:7a:cd:
c7:2b:b8:6a:63:a9:fb:6f:a4:72:bf:4c:5d:00:14:
ba:fa:59:88:ed:e4:e0:8c:a2:ec:14:7e:2d:e2:f0:
46:49:95:45

[EMAIL PROTECTED] ~/work/openssl/apps> openssl rsa -text -noout -inform d -in 
rsa2.der
Private-Key: (2048 bit)
modulus:
00:c0:c0:ce:3e:3c:53:67:3f:4f:c5:2f:a4:c2:5a:
2f:58:fd:27:52:6a:e8:cf:4a:73:47:8d:25:0f:5f:
03:26:78:ef:f0:22:12:d3:de:47:b2:1c:0b:38:63:
1a:6c:85:7a:80:c6:8f:a0:41:af:62:c4:67:32:88:
f8:a6:9c:f5:23:1d:e4:ac:3f:29:f9:ec:e1:8b:26:
03:2c:b2:ab:f3:7d:b5:ca:49:c0:8f:1c:df:33:3a:
60:da:3c:b0:16:f8:a9:12:8f:64:ac:23:0c:69:64:
97:5d:99:d4:09:83:9b:61:d3:ac:f0:de:dd:5e:9f:
44:94:db:3a:4d:97:e8:52:29:f7:db:94:07:45:90:
78:1e:31:0b:80:f7:57:ad:1c:79:c5:cb:32:b0:ce:
cd:74:b3:e2:94:c5:78:2f:34:1a:45:f7:8c:52:a5:
bc:8d:ec:d1:2f:31:3b:

Re: [openssl.org #1726] Bug with FIPS_mode_set

[Tim Hudson]

Brad Smith via RT wrote:

We are running on SLES 10 SP2.  Some of our processes need to enable and 
disable FIPS multiple times within its execution.  The following code worked on 
openssl-fips-1.1.1 but appears to be broken in 1.1.2:


// this works
int rc = FIPS_mode_set( 1 );

// and this works
rc = FIPS_mode_set( 0 );

// but if I try to re-enable, this will fail
rc = FIPS_mode_set( 1 );

I think I narrowed it down to a recent change in fips_rand.c.  If I copy the 
1.1.1 version of fips_rand.c to the 1.1.2 source directory and rebuild, the 
issue goes away.

Let me know if I can offer any more information.  Thanks in advance.
brad



Add in a call to
RAND_set_rand_method(NULL);
before the FIPS_mode_set(1) and it should work fine.

Tim.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Issues with Windows build: /GS and bufferoverflowu.lib

[Tim Hudson]

Trent Nelson wrote:

Hi,

I tried to build 0.9.8g with Visual Studio 2008 x64 vi 'perl Configure 
VC-WIN64A'.  The resulting nt.mak and ntdll.mak files had 'bufferoverflowU.lib' 
added to LFLAGS, courtesy of a few lines in util/pl/VC-32.pl that look like 
this:

$ex_libs.=' bufferoverflowu.lib' if ($FLAVOR =~ /WIN64/);

There are two problems here.  First, /GS isn't ever added to CFLAGS, which means the security checks aren't even enabled, making the specification of bufferoverflowu.lib pointless.  

> I assume this was left out by mistake.


#if _MSC_FULL_VER > 14000 && _MSC_FULL_VER <= 140040310
#pragma comment(lib,"bufferoverflowU.lib")
#endif

Again, all of this is moot if /GS isn't added as a CFLAG ;-)


Things are somewhat more complicated than that depending on which version and 
what form the runtime libraries take when building for WIN64A. Whether or not 
the bufferoverflowU.lib code is required totally independent of what flags have 
been selected when compiling your own code.


Try the following which I've just repeated with the Visual Studio Express 2005 
compiler to confirm its behaviour.


#include 

int main(int argc, char *argv[])
{
  printf("hello\n");
  return(0);
}


cl x.c

This will fail with LIBCMT which includes a reference to the security cookie and 
therefore requires that the application link in bufferoverflowU.lib.


cl /MD x.c

This works - as the DLL form for the C runtime includes the necessary logic to 
handle things.


Adding /GS- (to explicitly disable this stuff) does not change either of these.

Your suggestion of the #if line block does indeed work around the issue for 
Visual Studio Express 2005 at least so that is an alternate approach to consider 
although adding in library references via pragmas feels somewhat strange.


Tim.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Something in ssl crashes!! Help!!!

[Tim Hudson]

biswatosh chakraborty wrote:

Hi Gurus,

My application server crashes giving the following core dump. It goes 
for ssl negotiation ( using openssl) and dumps core on solaris8. Any clues please?


That stack trace back tends to indicate a threaded application.

The following FAQ and document should assist you in checking that the 
appropriate locking callbacks are registered for your platform.


http://www.openssl.org/support/faq.html#PROG1
and
http://www.openssl.org/docs/crypto/threads.html

If you don't have these call backs in place you should add them and re-run your 
application.


Tim.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #1642] patch purify errors

[Tim Hudson via RT]

There are a few UMRs and one FIU in the current OpenSSL-0.9.8g code base.
The attached patch fixes this with minimal code changes.

A better solution would be to use a BN_init call on each of the local BN 
variables being used which would be a trivial adaptation of this patch.

Without this patch there are 17014 purify errors across a total of 208 unique 
code paths in a "make test" for a purify build under linux.

There remains one purify error I'm still tracking down.

TOTAL-ERRORS: 44
UNIQUE-ERRORS: 1
44 - UMR
 AES_cbc_encrypt [aes_cbc.c:77]
 aes_256_cbc_cipher [e_aes.c:87]
 EVP_Cipher [evp_lib.c:183]
 ssl3_enc   [s3_enc.c:497]
 do_ssl3_write  [s3_pkt.c:684]
[heap=1 loc=318 size=18698
 malloc [rtlib.o]
 default_malloc_ex [mem.c:79]
 CRYPTO_malloc  [mem.c:304]
 ssl3_setup_buffers [s3_both.c:612]
 ssl3_connect   [s3_clnt.c:228]

heap=1 loc=318 size=18698]

Tim.

Index: crypto/asn1/f_int.c
===
RCS file: /usr/local/mirrors/openssl/openssl/crypto/asn1/f_int.c,v
retrieving revision 1.10
diff -b -c -r1.10 f_int.c
*** crypto/asn1/f_int.c 13 Nov 2002 15:42:13 -  1.10
--- crypto/asn1/f_int.c 13 Feb 2008 23:19:35 -
***
*** 181,186 
--- 181,187 
}
for (j=0; jflags & RSA_FLAG_NO_CONSTTIME))
{
c = &local_c;
+   local_c.flags = 0;
BN_with_flags(c, I, BN_FLG_CONSTTIME);
if (!BN_mod(r1,c,rsa->q,ctx)) goto err;
}
***
*** 767,772 
--- 768,774 
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
dmq1 = &local_dmq1;
+   local_dmq1.flags=0;
BN_with_flags(dmq1, rsa->dmq1, BN_FLG_CONSTTIME);
}
else
***
*** 778,783 
--- 780,786 
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
c = &local_c;
+   local_c.flags=0;
BN_with_flags(c, I, BN_FLG_CONSTTIME);
if (!BN_mod(r1,c,rsa->p,ctx)) goto err;
}
***
*** 790,795 
--- 793,799 
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
dmp1 = &local_dmp1;
+   local_dmp1.flags=0;
BN_with_flags(dmp1, rsa->dmp1, BN_FLG_CONSTTIME);
}
else
***
*** 809,814 
--- 813,819 
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
pr1 = &local_r1;
+   local_r1.flags=0;
BN_with_flags(pr1, r1, BN_FLG_CONSTTIME);
}
else
Index: crypto/rsa/rsa_gen.c
===
RCS file: /usr/local/mirrors/openssl/openssl/crypto/rsa/rsa_gen.c,v
retrieving revision 1.17.2.2
diff -b -c -r1.17.2.2 rsa_gen.c
*** crypto/rsa/rsa_gen.c28 Mar 2007 00:14:22 -  1.17.2.2
--- crypto/rsa/rsa_gen.c13 Feb 2008 23:20:49 -
***
*** 170,175 
--- 170,176 
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
  pr0 = &local_r0;
+ local_r0.flags=0;
  BN_with_flags(pr0, r0, BN_FLG_CONSTTIME);
}
else
***
*** 180,185 
--- 181,187 
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
d = &local_d;
+   local_d.flags=0;
BN_with_flags(d, rsa->d, BN_FLG_CONSTTIME);
}
else
***
*** 195,200 
--- 197,203 
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
p = &local_p;
+   local_p.flags=0;
BN_with_flags(p, rsa->p, BN_FLG_CONSTTIME);
}
else
Index: crypto/rsa/rsa_lib.c
===
RCS file: /usr/local/mirrors/openssl/openssl/crypto/rsa/rsa_lib.c,v
retrieving revision 1.39.2.4
diff -b -c -r1.39.2.4 rsa_lib.c
*** crypto/rsa/rsa_lib.c28 Mar 2007 00:14:24 -  1.39.2.4
--- crypto/rsa/rsa_lib.c13 Feb 2008 23:20:49 -
***
*** 405,410 
--- 405,411 
{
/* Set BN_FLG_CONSTTIME flag */
n = &local_n;
+   local_n.flags=0;
BN_with_flags(n, rsa->n, BN_FLG_CONSTTIME);
}
else