Re: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS

[Tomas Mraz via RT]

On Po, 2016-08-29 at 14:27 +, Richard Levitte via RT wrote:
> On Mon Aug 29 12:27:59 2016, appro wrote:
> > 
> > Or maybe ("maybe" is reference to "I don't quite grasp" above) what
> > we
> > are talking about is Configure reading CFLAGS and LDFLAGS and
> > *adding*
> > them to generated Makefile. I mean we are not talking about passing
> > them
> > to 'make', but "freezing" them to their values at configure time.
> > Could
> > you clarify?
> I assume, and please correct me if I'm wrong, that the request is to
> treat the
> environment variables CFLAGS and LDFLAGS the same way we treat CC,
> i.e. as an
> initial value to be used instead of what we get from the
> configuration target
> information.
> 
> This should be quite easy to implement, and we can also continue to
> use
> whatever additional Configure arguments as compiler or linker flags
> to be used
> *in addition* to the initial value (that comes from the config target
> information, or if we decide to implement it, CFLAGS)

Ideally the optimization/debugging flags not affecting directly the
code that is being compiled would be replaced with what is placed into
CFLAGS/LDFLAGS. But things like -D would be kept from the config target
information.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS

[Tomas Mraz via RT]

I would like to join this request as maintainer of OpenSSL for Fedora
and Red Hat Enterprise Linux. It would clean up things for us as well.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

[Tomas Mraz via RT]

On Út, 2016-06-28 at 22:10 +, Thomas Waldmann via RT wrote:
> On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote:
> > 
> > On Mon, Jun 27, 2016 at 08:50:43PM +, Thomas Waldmann via RT
> > wrote:
> > > 
> > > I didn't ask where to get the missing code from, I asked whether
> > > you
> > > maybe want to make life simpler for people by adding this to
> > > 1.0.x
> > > rather than having a thousand software developers copy and
> > > pasting it
> > > into their projects.
> > I think this will not actually make life easier.  People using a
> > 1.0.x version are not always using the latest 1.0.x version.
> Aren't they?
> 
> Don't they use 1.0.xLATEST rather soon, due to security fixes?
> 
> And in case some dist maintainer chooses to rather backport, couldn't
> they also backport the added function if it is documented as "openssl
> 1.1.x migration support" or so?
> 
> We aren't talking about incompatible changes, just adding 2 trivial
> functions that were not there yet (but should have been there, when
> looking at the rest of the API).

You might get such kind of backport to something that still evolves
such as (RHEL/CentOS 7) however you would not get it in older releases
(RHEL/CentOS 5 and most probably RHEL/CentOS 6 either).

So you will still be facing the issue that there are environments where
someone wants to build your code and these functions are not present.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Tomas Mraz via RT]

On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote:
> In message  on
> Mon, 25 Apr 2016 13:19:38 +, "Salz, Rich via RT" 
> said:
> 
> rt> No, he means setting the same value twice.  For example, making
> this change:
> rt> If (r=->n != n) BN_free(r->n);
> rt> If(r->e != e) BN_free(r->e);
> rt> If (r->d != d) BN_free(r->d);
> rt> 
> rt> I agree it shouldn't happen, but do we want to protect against
> that?  I could be convinced either way.
> 
> Ah ok...  sorry, I misread the intention.
> 
> Agreed that we could make sure not to free the pointers in that case.

In that case this should be properly documented so the users of the API
can depend on it.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4518
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Tomas Mraz via RT]

On Po, 2016-04-25 at 13:08 +, Richard Levitte via RT wrote:
> 
> rsalz> > If nothing else, all the RSA_set0 routines should test if
> the same pointer
> rsalz> > value is being replaced if so do not free it.
> rsalz> > 
> rsalz> > The same logic need to be done for all the RSA_set0_*
> functions as well as
> rsalz> > the DSA_set0_* functions.
> rsalz> 
> rsalz> That seems like a bug we should fix.
> 
> No, it's by design:
> 

Then perhaps there should be a function to set only the private part of
the RSA and DSA keys?

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4518
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4240] Document some of the speed options

[Tomas Mraz via RT]

The attached patch provides documentation of some of the currently
undocumented speed options.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



diff --git a/doc/apps/speed.pod b/doc/apps/speed.pod
index 1cd1998..a295709 100644
--- a/doc/apps/speed.pod
+++ b/doc/apps/speed.pod
@@ -8,6 +8,9 @@ speed - test library performance
 
 B
 [B<-engine id>]
+[B<-elapsed>]
+[B<-evp algo>]
+[B<-decrypt>]
 [B]
 [B]
 [B]
@@ -49,6 +52,19 @@ to attempt to obtain a functional reference to the specified engine,
 thus initialising it if needed. The engine will then be set as the default
 for all available algorithms.
 
+=item B<-elapsed>
+
+Measure time in real time instead of CPU time. It can be useful when testing
+speed of hardware engines.
+
+=item B<-evp algo>
+
+Use the specified cipher or message digest algorithm via the EVP interface.
+
+=item B<-decrypt>
+
+Time the decryption instead of encryption. Affects only the EVP testing.
+
 =item B<[zero or more test algorithms]>
 
 If any options are given, B tests those algorithms, otherwise all of
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4124] Illegal instruction when using aes-ni-sha256 stitched implementation on AMD CPU

[Tomas Mraz via RT]

The aes-ni-sha256 stitched implementation causes SIGILL on AMD A4-6210.
It is caused by not using the AVX+SSSE3 code path for non-Intel CPUs
although the CPU seems to be fully capable of running it.

The ia32cap vector is 0x7ED8220B078B but when you set it explicitly
with OPENSSL_ia32cap=0x7ED8220B478B (i.e. the Intel CPU bit is set)
it works fine and the AVX+SSSE3 codepath is taken.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1278194 for
details.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3913] [RFE] Add a way to application to know a minimum DH size allowed by the client

[Tomas Mraz via RT]

The current minimum DH size allowed by the client is 768 bits which is a
hardcoded constant. It would be nice if the constant was at least
#define in public headers or even better if there was an API to query
various minimum and maximum bit sizes that are checked in the library
such as the maximum supported key lengths, etc.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of regression - fails to connect to server where 1.0.2a works fine

[Tomas Mraz via RT]

On Po, 2015-06-15 at 14:22 +, Arkadiusz Miskiewicz via RT wrote:
 Hello.
 
 I've just upgraded from 1.0.2a to 1.0.2c and now I no longer can connect from
 mysql client to my mysql server. Downgrading to 1.0.2a and the problem is 
 gone.
 

That's because mysql server hardcodes 512 bits DH parameters. That's
insecure and connect is prevented by the LOGJAM fix. You can configure
the server to not use DH ciphersuites as a workaround, or patch the
mysql server to use at least 1024 bits DH parameters.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3675] Fix key wrapping mode with padding to conform to RFC 5649

[Tomas Mraz via RT]

Hello OpenSSL developers,
can you please include this fix which although a trivial code change
nevertheless does have big impact on the encrypted key-wrapped data.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

[Tomas Mraz via RT]

On St, 2014-12-10 at 18:35 +0100, Andy Polyakov via RT wrote:
  Excellent. My summary is:
  -  valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect 
  my program in operation (you will probably say will not affect)
 
 Well, as there is suggestion of what I would say, I would only say that
 it's false positive.
 
  - when OpenSLL 1.0.2 eventually percolates through to Ubuntu and Fedora 
  valgrind will stop complaining.
 
 Another alternative is that they recognize it as bug worthy fixing,
 valgrind or OpenSSL. Even though I argue that it's valgrind bug, I'm
 ready to assist in addressing the issue on OpenSSL side. In other words
 try to report it to your favorite distro vendor. Refer to this ticket.
 But for now, I'm dismissing the case.

As the Fedora OpenSSL maintainer I would say it is not worth fixing in
OpenSSL. We will rebase to 1.0.2 final in Fedora Rawhide once it is
released.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



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

[openssl.org #3560] OpenSSL selects weak digest for (EC)DH kex signing in TLSv1.2 when connecting to SNI virtual server

[Tomas Mraz via RT]

When connecting to a virtual, SNI defined host openssl selects SHA1
digest instead of SHA512, as it does for the default host.

Steps to Reproduce:
1. openssl req -x509 -newkey rsa:2048 -keyout localhost.key -out localhost.crt 
-subj /CN=localhost -nodes -batch
2. openssl req -x509 -newkey rsa:2048 -keyout server.key -out server.crt -subj 
/CN=server -nodes -batch
3. openssl s_server -key localhost.key -cert localhost.crt -key2 server.key 
-cert2 server.crt -servername server

In other console, using OpenSSL 1.0.2:
1. openssl s_client -connect localhost:4433 /dev/null 2/dev/null| grep 'Peer 
signing digest'
2. openssl s_client -connect localhost:4433 -servername server /dev/null 
2/dev/null| grep 'Peer signing digest'


Actual results:
1. Peer signing digest: SHA512
2. Peer signing digest: SHA1

Expected results:
1. Peer signing digest: SHA512
2. Peer signing digest: SHA512

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1150033

I've investigated this a little and found that the second SSL context
that is used when the server receives the servername extension does not
have full copy of settings from the main context. Namely the
tls1_process_sigalgs() is not properly called for it. I am not sure what
would be the proper fix though.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

[openssl.org #3537] Bug in TS_check_status_info() and misleading comments

[Tomas Mraz via RT]

In the TS_check_status_info() there is bug where instead of appending
the ',' character to the failure info texts this character overwrites
the previous failure info text with strcpy() call.

Also the TS_STATUS_BUF_SIZE is named incorrectly as it does not relate
to status text but to the failure info text.

The attached patch fixes these minor bugs.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


diff --git a/crypto/ts/ts_rsp_verify.c b/crypto/ts/ts_rsp_verify.c
index 3c7f816..ec0d37e 100644
--- a/crypto/ts/ts_rsp_verify.c
+++ b/crypto/ts/ts_rsp_verify.c
@@ -87,8 +87,6 @@ static int TS_find_name(STACK_OF(GENERAL_NAME) *gen_names, GENERAL_NAME *name);
 
 /*
  * Local mapping between response codes and descriptions.
- * Don't forget to change TS_STATUS_BUF_SIZE when modifying 
- * the elements of this array.
  */
 static const char *TS_status_text[] =
 	{ granted,
@@ -101,11 +99,15 @@ static const char *TS_status_text[] =
 #define TS_STATUS_TEXT_SIZE	(sizeof(TS_status_text)/sizeof(*TS_status_text))
 
 /*
- * This must be greater or equal to the sum of the strings in TS_status_text
+ * This must be greater or equal to the sum of the strings in TS_failure_info
  * plus the number of its elements.
  */
-#define TS_STATUS_BUF_SIZE	256
+#define TS_FAILURE_INFO_BUF_SIZE	256
 
+/*
+ * Don't forget to change TS_FAILURE_INFO_BUF_SIZE when modifying 
+ * the elements of this array.
+ */
 static struct
 	{
 	int code;
@@ -482,7 +484,7 @@ static int TS_check_status_info(TS_RESP *response)
 	long status = ASN1_INTEGER_get(info-status);
 	const char *status_text = NULL;
 	char *embedded_status_text = NULL;
-	char failure_text[TS_STATUS_BUF_SIZE] = ;
+	char failure_text[TS_FAILURE_INFO_BUF_SIZE] = ;
 
 	/* Check if everything went fine. */
 	if (status == 0 || status == 1) return 1;
@@ -509,7 +511,7 @@ static int TS_check_status_info(TS_RESP *response)
 		TS_failure_info[i].code))
 {
 if (!first)
-	strcpy(failure_text, ,);
+	strcat(failure_text, ,);
 else
 	first = 0;
 strcat(failure_text, TS_failure_info[i].text);

Re: [openssl.org #3451] patch for x509.c

[Tomas Mraz via RT]

On Út, 2014-07-15 at 20:08 +0200, Jan Just Keijser via RT wrote:
 On 15/07/14 15:20, Daniel Kahn Gillmor wrote:
  On 07/15/2014 07:58 AM, Salz, Rich via RT wrote:
  The Globus syntax is strange. :)
 
  We should support the ISO date/time standard, and use that throughout and 
  not invent yet another syntax, or yet another flag.  It's fairly simple to 
  parse, and handles timezones, relative times, date/time mixing, and so on. 
   The XML XSD spec, for example, has a reasonable explanation.
  Agreed here.  also, the presence of a hyphen in a time marker is too
  easily misunderstood as a minus sign.
 
  If we're talking about the duration of a certificate, we could use
  something like the ISO-8601 duration syntax:
 
 https://en.wikipedia.org/wiki/ISO-8601#Durations
 
  e.g. PT1800S is 1800 seconds
 
 
 I like the idea, but I won't have time to rewrite the patch right now. 
 Implementing full ISO8061 timestamps will take some effort. I'd also 
 propose to rename '-valid' to '-duration' .
 I'll get back on this in mid August.

What about just supporting float number argument for -days (0.5 for 12
hours certificate validity)? That should be fairly simple. In the first
step. And add something like -notafter argument that would specify the
exact end datetime in the ISO format (not duration) as a second step.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



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

Re: [openssl.org #3451] patch for x509.c

[Tomas Mraz via RT]

On St, 2014-07-16 at 17:46 +0200, Daniel Kahn Gillmor via RT wrote:
 On 07/16/2014 11:24 AM, Salz, Rich wrote:
  do you realistically think we'll ever drop support for the -days argument
  though?  Dropping -days would break a million scripts.
  
  No, we'll never drop support for -days.  But whether the code is atoi() or 
  atof() is a big difference and might cause important silent failures for 
  new scripts running on anything other than the most recent openssl.  On 
  most systems atoi(0.5) returns 0 and no error indicator so -days 0.5 
  would silently do the wrong thing on anything other than openssl 
  1.0.whatever  Which seems much worse.
 
 ugh, you're quite right.  Sorry, i wasn't thinking about the support
 hassle in that direction.
 
 And to make matters worse, openssl req -x509 currently interprets
 -days 0 or -days 0.5 or -days PT1800S as use the default number
 of days, which is 30. :/  From experimentation, i just discovered that
 -days is also happy to accept and interpret negative integer arguments
 as well, resulting in a key with ValidNotBefore later than ValidNotAfter
 :(  not even an error message to let you know that you've just created a
 certificate that no validation stack in its right mind should ever accept.
 
 I withdraw my support for making -days take a fractional argument, given
 the behavior of the existing deployed base.

I agree with that as well. I did not look at the actual code in openssl
so I did not know that the fractional argument with the current version
does not error out.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



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

Re: [openssl.org #3415] Bug report: Uninitialized memory reads reported by valgrind for ECDSA signatures

[Tomas Mraz via RT]

On Čt, 2014-07-03 at 23:47 +0200, Matt Caswell via RT wrote:

 I've put together a fix (see below), but not pushed it because I was working 
 on
 the assumption that if you had PURIFY defined then you wouldn't care about
 constant time operation. I've since been told that possibly some distros 
 define
 PURIFY in their production builds. Anyone know of an example where this is 
 used
 in a production build?

We use -DPURIFY in regular openssl packages in Red Hat Enterprise Linux
and Fedora.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



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

Re: [openssl.org #3266] [PATCH] Add the SYSTEM cipher keyword

[Tomas Mraz via RT]

On St, 2014-02-19 at 23:03 +0100, Nikos Mavrogiannopoulos via RT wrote:
 This keyword allows a program to simply specify SYSTEM in its
 configuration file and the SSL cipher used will be determined at
 run-time from a system-specific file. The system default keywords can be
 extended by appending any application-specific ciphers such as
 SYSTEM:PSK.
 
 Such a keyword allows distributors of applications to centrally control
 the allowed ciphers.

Can OpenSSL developers please at least say what they think about the
acceptability of the SYSTEM keyword support in the cipher string? I'd
like to add the support to Fedora openssl package but we would like to
see it upstreamed sooner or later.

Thanks,
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)



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

[openssl.org #3264] openssl req ignores key length set in config file

[Tomas Mraz via RT]

'openssl req -newkey rsa' ignores keylen set in the openssl config file
in the req section. It also misleadingly prints out the configured
keylen in 'Generating  bit RSA private key.' message when it
generates the library hardcoded default of 1024 bits.

The attached patch fixes this bug.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)

diff -up openssl-1.0.1e/apps/req.c.keylen openssl-1.0.1e/apps/req.c
--- openssl-1.0.1e/apps/req.c.keylen	2014-02-12 14:58:29.0 +0100
+++ openssl-1.0.1e/apps/req.c	2014-02-14 13:52:48.692325000 +0100
@@ -644,6 +644,12 @@ bad:
 		if (inrand)
 			app_RAND_load_files(inrand);
 
+		if (newkey = 0)
+			{
+			if (!NCONF_get_number(req_conf,SECTION,BITS, newkey))
+newkey=DEFAULT_KEY_LENGTH;
+			}
+
 		if (keyalg)
 			{
 			genctx = set_keygen_ctx(bio_err, keyalg, pkey_type, newkey,
@@ -651,12 +657,6 @@ bad:
 			if (!genctx)
 goto end;
 			}
-	
-		if (newkey = 0)
-			{
-			if (!NCONF_get_number(req_conf,SECTION,BITS, newkey))
-newkey=DEFAULT_KEY_LENGTH;
-			}
 
 		if (newkey  MIN_KEY_LENGTH  (pkey_type == EVP_PKEY_RSA || pkey_type == EVP_PKEY_DSA))
 			{
@@ -1649,6 +1649,8 @@ static EVP_PKEY_CTX *set_keygen_ctx(BIO
 keylen = atol(p + 1);
 *pkeylen = keylen;
 }
+			else
+keylen = *pkeylen;
 			}
 		else if (p)
 			paramfile = p + 1;

Re: [openssl.org #3264] openssl req ignores key length set in config file

[Tomas Mraz via RT]

Heh, good :)
As we both came independently to the same patch we can declare it right
and perhaps the openssl upstream developers can finally commit it to the
git repository.



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

Re: [openssl.org #3224] OpenSSL 1.0.1f rsa_pmeth.c duplicate code block

[Tomas Mraz via RT]

On Pá, 2014-01-10 at 09:53 +0100, Paul Suhler via RT wrote:
 Lines 612 through 615 of rsa_pmeth.c apparently contain duplicated lines:
 
 Line 612:
   else if (!strcmp(value, oeap))
   pm = RSA_PKCS1_OAEP_PADDING;
   else if (!strcmp(value, oaep))
   pm = RSA_PKCS1_OAEP_PADDING;
 
 This appears to be a cut and paste error.

No, this is actually a fix for typo 'oeap' in previous versions.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

[openssl.org #3176] Locking problem in fips_drgb_rand.c

[Tomas Mraz via RT]

The fips_drbg_bytes() function calls CRYPTO_w_lock(CRYPTO_LOCK_RAND);
unfortunately the FIPS_drbg_generate() function can eventually call
drbg_reseed() if sufficiently enough bytes are pulled out of the DRBG.
This function in turn pulls bytes from the MD rand using the
RAND_SSLeay()-bytes(). However MD rand uses
CRYPTO_w_lock(CRYPTO_LOCK_RAND); in ssleay_rand_bytes().

This leads to double locking the CRYPTO_LOCK_RAND which can mean
undefined behavior unless for example in case of pthreads the mutex type
used is PTHREAD_MUTEX_RECURSIVE.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)

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

Re: [openssl.org #3002] Communication problems with 1.0.1e

[Tomas Mraz via RT]

On Fri, 2013-03-01 at 22:01 +0100, Kurt Roeckx wrote: 
 I can't either, and yet I have multiple people reporting problems
 with the 1.0.1e version saying the 1.0.1c version works without
 problems.

This happened recently on Fedora as well.

See: 
https://bugzilla.redhat.com/show_bug.cgi?id=918981

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #2936] Properly set default trusted CA paths if -CAfile and -CApath not used

[Tomas Mraz via RT]

The current behavior of s_client, s_server and s_time commands in
regards to the default trusted CA store path is incorrect. The default
paths are loaded only in case SSL_CTX_load_verify_locations() does not
fail. This means that you have to use -CApath or -CAfile
The attached patch properly sets the default paths only if neither
-CApath nor -CAfile is specified.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.1c/apps/s_client.c.default-paths openssl-1.0.1c/apps/s_client.c
--- openssl-1.0.1c/apps/s_client.c.default-paths	2012-03-18 19:16:05.0 +0100
+++ openssl-1.0.1c/apps/s_client.c	2012-12-06 18:24:06.425933203 +0100
@@ -1166,12 +1166,19 @@ bad:
 	if (!set_cert_key_stuff(ctx,cert,key))
 		goto end;
 
-	if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
-		(!SSL_CTX_set_default_verify_paths(ctx)))
+	if (CAfile == NULL  CApath == NULL)
 		{
-		/* BIO_printf(bio_err,error setting default verify locations\n); */
-		ERR_print_errors(bio_err);
-		/* goto end; */
+		if (!SSL_CTX_set_default_verify_paths(ctx))
+			{
+			ERR_print_errors(bio_err);
+			}
+		}
+	else
+		{
+		if (!SSL_CTX_load_verify_locations(ctx,CAfile,CApath))
+			{
+			ERR_print_errors(bio_err);
+			}
 		}
 
 #ifndef OPENSSL_NO_TLSEXT
diff -up openssl-1.0.1c/apps/s_server.c.default-paths openssl-1.0.1c/apps/s_server.c
--- openssl-1.0.1c/apps/s_server.c.default-paths	2012-03-18 19:16:05.0 +0100
+++ openssl-1.0.1c/apps/s_server.c	2012-12-06 18:25:11.199329611 +0100
@@ -1565,13 +1565,21 @@ bad:
 		}
 #endif
 
-	if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
-		(!SSL_CTX_set_default_verify_paths(ctx)))
+	if (CAfile == NULL  CApath == NULL)
 		{
-		/* BIO_printf(bio_err,X509_load_verify_locations\n); */
-		ERR_print_errors(bio_err);
-		/* goto end; */
+		if (!SSL_CTX_set_default_verify_paths(ctx))
+			{
+			ERR_print_errors(bio_err);
+			}
+		}
+	else
+		{
+		if (!SSL_CTX_load_verify_locations(ctx,CAfile,CApath))
+			{
+			ERR_print_errors(bio_err);
+			}
 		}
+
 	if (vpm)
 		SSL_CTX_set1_param(ctx, vpm);
 
@@ -1622,8 +1630,11 @@ bad:
 		else
 			SSL_CTX_sess_set_cache_size(ctx2,128);
 
-		if ((!SSL_CTX_load_verify_locations(ctx2,CAfile,CApath)) ||
-			(!SSL_CTX_set_default_verify_paths(ctx2)))
+		if (!SSL_CTX_load_verify_locations(ctx2,CAfile,CApath))
+			{
+			ERR_print_errors(bio_err);
+			}
+		if (!SSL_CTX_set_default_verify_paths(ctx2))
 			{
 			ERR_print_errors(bio_err);
 			}
diff -up openssl-1.0.1c/apps/s_time.c.default-paths openssl-1.0.1c/apps/s_time.c
--- openssl-1.0.1c/apps/s_time.c.default-paths	2006-04-17 14:22:13.0 +0200
+++ openssl-1.0.1c/apps/s_time.c	2012-12-06 18:27:41.694574044 +0100
@@ -373,12 +373,19 @@ int MAIN(int argc, char **argv)
 
 	SSL_load_error_strings();
 
-	if ((!SSL_CTX_load_verify_locations(tm_ctx,CAfile,CApath)) ||
-		(!SSL_CTX_set_default_verify_paths(tm_ctx)))
+	if (CAfile == NULL  CApath == NULL)
 		{
-		/* BIO_printf(bio_err,error setting default verify locations\n); */
-		ERR_print_errors(bio_err);
-		/* goto end; */
+		if (!SSL_CTX_set_default_verify_paths(tm_ctx))
+			{
+			ERR_print_errors(bio_err);
+			}
+		}
+	else
+		{
+		if (!SSL_CTX_load_verify_locations(tm_ctx,CAfile,CApath))
+			{
+			ERR_print_errors(bio_err);
+			}
 		}
 
 	if (tm_cipher == NULL)

[openssl.org #2874] Missing initialization of str in aes_ccm_init_key

[Tomas Mraz via RT]

The str member of EVP_AES_CCM_CTX structure stays uninitialized when aes
ccm is used with the vpaes backend causing it to crash when the str is
later called as it is non-NULL. The attached patch fixes the problem.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.1c/crypto/evp/e_aes.c.init-str openssl-1.0.1c/crypto/evp/e_aes.c
--- openssl-1.0.1c/crypto/evp/e_aes.c.init-str	2012-09-06 17:20:45.0 +0200
+++ openssl-1.0.1c/crypto/evp/e_aes.c	2012-09-06 17:18:30.0 +0200
@@ -1216,6 +1216,7 @@ static int aes_ccm_init_key(EVP_CIPHER_C
 			vpaes_set_encrypt_key(key, ctx-key_len*8, cctx-ks);
 			CRYPTO_ccm128_init(cctx-ccm, cctx-M, cctx-L,
 	cctx-ks, (block128_f)vpaes_encrypt);
+			cctx-str = NULL;
 			cctx-key_set = 1;
 			break;
 			}

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

[Tomas Mraz via RT]

On Sun, 2012-06-10 at 18:04 +0200, Michael Tuexen wrote: 
 On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote:
 
  The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
  value of length 4. On little endian systems this is not so critical
  problem however on big endian 64 bit systems it means the interpretation
  of the returned value by the code in dgram_ctrl() is completely wrong -
  
  Actually similar argument applies even to sockopt_len. Modulo fact
  that you get into trouble in cases when *expected*
  sizeof(sockopt_len) is 8, while the value is declared int. The
  situation is intensified by fact that in some cases expected
  sizeof(sockopt_len) depends on compiler flags. And I'm not talking
  about -m32 vs. -m64 compiler flags, I'm talking about flags in
  64-bit case [Tru64 for one if you have to know]. One way to attack
  the problem is depicted in crypto/bio/b_sock.c:975. I mean union
  between unsigned int and size_t, explicit zeroing of size_t member
  and heuristic that detects big-endian trouble. Then one can declare
  even sockopt_val as similar union and pick int or long depending on
  calculated sockopt_len being 4 or 8.
  General comment:
  Can't you use socklen_t as the type of the last argument?
  
  As it says in crypto/bio/b_sock.c:975, there *are* platforms that don't 
  have socklen_t. Of course one can question if these platforms are modern 
  enough/worth to care about, but why not, if it's feasible and enriching? Or 
  course one can go for #ifdef, but does one have to?
  
  At least
  this is what I normally use. The type of *option_value might be
  platform dependent, but then we need some #ifdefs for platforms.
  
  But the choice is still between 32- and 64-bit integers. And if so, you can 
  distinguish among them at run time as accurately. Or should one say even 
  more accurately, because it's actual value, not assumed one from compile 
  time. Of course, absolute majority of compiled code heavily relies on 
  assumed values being equal to actual, but it's not prohibited to assume 
  that there are not, is it? #ifdefs have to be maintained in sense that you 
  have to follow their changes on multiple platforms, while #ifdef-free 
  alternative simply adapts to whichever situation with *no* maintenance.
  
  Regarding the IP_MTU/IPV6_MTU socket option on Linux: The Linux man
  page says, that the type of the option_value is int. So I guess the
  bug is simply, that the code uses long sockopt_val instead of int
  sockopt_val. All this is specific to Linux.
  
  Can you guarantee that the code in question won't ever become interesting 
  to reuse even in non-Linux context? I mean do you really have to assume 
  Linux that categorically? In other words in context of multi-platform code 
  such as OpenSSL there is value in *not* assuming things.
 I think
 http://rt.openssl.org/Ticket/Display.html?id=2830user=guestpass=guest
 already fixes the bug, since it changes sockopt_val from long to int.

It fixes the first problem (although non-portably). But there are still
the signed/unsigned int comparisons of the mtu values later in the code
in d1_both.c. Of course fixing the first problem will probably mask the
second problem.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

[Tomas Mraz via RT]

The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code in dgram_ctrl() is completely wrong -
you will get a bogus huge value of MTU which leads even to a segfault
(fortunately without security impact) later in the DTLS code. The
simplest fix would be to use int instead of long for the sockopt_val
although I am not sure about the portability to other non-linux kernels.

Another problem is when s-d1-mtu is compared to dtls1_min_mtu() value
in dtls1_do_write() - as signed integer value is compared to unsigned
value an implicit conversion of the signed integer to unsigned value is
performed and negative value (which came out of the bogus call in
dgram_ctrl()) is converted to some large value and thus the comparison
fails and the fallback code for choosing some safe MTU value is not
invoked.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: [openssl.org #2802] 1.0.0's SSL_OP_ALL and SSL_OP_NO_TLSv1_1

[Tomas Mraz via RT]

On Wed, 2012-04-25 at 10:35 +0200, Andy Polyakov via RT wrote: 
 more secure protocols. Trade-off. As 1.0.0 application is not in
 position to expect anything above TLS1.0, trade-off can as well be
 resolved in favor of interoperability. Note that there is not such
 trade-off in 1.0.1 application context, because 1.0.1 SSL_OP_ALL won't
 disable protocols above TLS1.0.

I'd be in favor to moving the SSL_OP_NO_TLSv1_1 out of SSL_OP_ALL as of
1.0.0 as application should not in general really care against which
openssl version _with stable ABI_ it is linked. And the capabilities
should be defined by the underlying installed library version and not
the version it was built against. Of course in case the application
needs to refer to API additions for the new functionality the situation
is different, but that is not the case of TLS1.1.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389

[Tomas Mraz via RT]

On Sun, 2012-04-15 at 16:45 +0200, Andy Polyakov via RT wrote: 
  Here is an experimental patch I wrote that implements the 1/n-1
  record splitting technique for OpenSSL. I am sending it here for
  consideration by OpenSSL upstream developers.
  
  By default the 0/n split is used but in case the
  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first
  record with 1/n-1.
 
 What would you [and others] say about this alternative? Non-committed,
 relative to HEAD...


The patch seems OK however it is not clear whether this change really
brings much.

The original experimental patch is not really usable as there are
already known applications which are even broken by the 1/n-1 split. So
for SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS the split cannot be done at all
anyway. Your patch will improve the compatibility of the case where
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not used however I have not seen
any reports, at least in our Bugzilla, that would ask for that. So it's
just a matter of preference whether you want to change the 0/n split to
1/n-1 one.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389

[Tomas Mraz via RT]

On Mon, 2012-04-16 at 11:49 +0200, Andy Polyakov via RT wrote: 
  Here is an experimental patch I wrote that implements the 1/n-1
  record splitting technique for OpenSSL. I am sending it here for
  consideration by OpenSSL upstream developers.
 
  By default the 0/n split is used but in case the
  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first
  record with 1/n-1.
  What would you [and others] say about this alternative? Non-committed,
  relative to HEAD...
  
  
  The patch seems OK however it is not clear whether this change really
  brings much.
  
  The original experimental patch is not really usable as there are
  already known applications which are even broken by the 1/n-1 split. So
  for SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS the split cannot be done at all
  anyway. Your patch will improve the compatibility of the case where
  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not used however I have not seen
  any reports, at least in our Bugzilla, that would ask for that. So it's
  just a matter of preference whether you want to change the 0/n split to
  1/n-1 one.
 
 Have you heard of *clients* that suffer from 1/n-1 split? I mean if
 clients are tolerant to it, it might make sense to favor 1/n-1 on server
 side. Major obstacle for 0/n used to be Microsoft TLS or in more
 practical terms IE, and with 1/n-1 IE would work...

I did not hear about any HTTPS clients that would be intolerant of the
1/n-1 split but other TLS usage (VPN, Jabber, ?) might be different in
this respect. But I do not know of any concrete cases where the client
is intolerant of the split.

 As for client side, arguably it would make things worth. I mean  if
 client plays smart and implements 1/n-1 split itself depending on
 situation, e.g. not when using POST, then such split in libssl would be
 counterproductive.

I do not know of any client that uses libssl as TLS backend that would
do such 1/n-1 split on itself.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #2786] Prevent crash if dctx-get_entropy() fails

[Tomas Mraz via RT]

On Sat, 2012-04-07 at 21:44 +0200, Stephen Henson via RT wrote: 
  [tm...@redhat.com - Sat Apr 07 15:39:00 2012]:
  
  This bug report applies to the OpenSSL FIPS 2.0 module.
  
  If dctx-get_entropy() fails and thus the tout is set to NULL we will
  set the output entropy pointer to NULL + blocklen. This will later lead
  to crash as we check for NULL entropy before calling
  fips_cleanup_entropy() but it will be invalid non-NULL pointer in this
  case.
  
  The attached patch prevents returning invalid non-NULL pointer from the 
  fips_get_entropy() function.
  
  
 
 While that is valid changing the FIPS code at this late stage of the
 validation is problematical.
 
 Since the output entropy pointer is restored to its original value in
 fips_cleanup_entropy can't we just make sure that function treats a NULL
 parameter as a no-op instead? 

Yes, that's surely possible as well.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #2786] Prevent crash if dctx-get_entropy() fails

[Tomas Mraz via RT]

This bug report applies to the OpenSSL FIPS 2.0 module.

If dctx-get_entropy() fails and thus the tout is set to NULL we will
set the output entropy pointer to NULL + blocklen. This will later lead
to crash as we check for NULL entropy before calling
fips_cleanup_entropy() but it will be invalid non-NULL pointer in this
case.

The attached patch prevents returning invalid non-NULL pointer from the 
fips_get_entropy() function.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-fips-2.0-test-20120202/fips/rand/fips_drbg_lib.c.entropy openssl-fips-2.0-test-20120202/fips/rand/fips_drbg_lib.c
--- openssl-fips-2.0-test-20120202/fips/rand/fips_drbg_lib.c.entropy	2011-12-13 01:22:17.0 +0100
+++ openssl-fips-2.0-test-20120202/fips/rand/fips_drbg_lib.c	2012-04-05 17:42:50.814929366 +0200
@@ -160,6 +160,8 @@ static size_t fips_get_entropy(DRBG_CTX
 		return dctx-get_entropy(dctx, pout, entropy, min_len, max_len);
 	rv = dctx-get_entropy(dctx, tout, entropy + bl,
 min_len + bl, max_len + bl);
+	if (tout == NULL)
+		return 0;
 	*pout = tout + bl;
 	if (rv  (min_len + bl) || (rv % bl))
 		return 0;

[openssl.org #2710] Add missing checks for load_certs_crls failure

[Tomas Mraz via RT]

The attached trivial patch adds missing check for load_certs_crls
failure in apps.c. It is applicable to 1.0.0 and 1.0.1 branches.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0a/apps/apps.c.load-certs openssl-1.0.0a/apps/apps.c
--- openssl-1.0.0a/apps/apps.c.load-certs	2010-05-27 16:09:13.0 +0200
+++ openssl-1.0.0a/apps/apps.c	2011-04-28 21:24:06.0 +0200
@@ -1208,7 +1208,8 @@ STACK_OF(X509) *load_certs(BIO *err, con
 	const char *pass, ENGINE *e, const char *desc)
 	{
 	STACK_OF(X509) *certs;
-	load_certs_crls(err, file, format, pass, e, desc, certs, NULL);
+	if (!load_certs_crls(err, file, format, pass, e, desc, certs, NULL))
+		return NULL;
 	return certs;
 	}	
 
@@ -1216,7 +1217,8 @@ STACK_OF(X509_CRL) *load_crls(BIO *err, 
 	const char *pass, ENGINE *e, const char *desc)
 	{
 	STACK_OF(X509_CRL) *crls;
-	load_certs_crls(err, file, format, pass, e, desc, NULL, crls);
+	if (!load_certs_crls(err, file, format, pass, e, desc, NULL, crls))
+		return NULL;
 	return crls;
 	}	
 

[openssl.org #2711] Fix possible NULL dereference on bad MIME headers

[Tomas Mraz via RT]

In some cases when a S/MIME message with broken MIME headers is
processed a NULL dereference in mime_hdr_cmp can happen. The attached
patch guards against this dereference.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-0.9.8j/crypto/asn1/asn_mime.c.bad-mime openssl-0.9.8j/crypto/asn1/asn_mime.c
--- openssl-0.9.8j/crypto/asn1/asn_mime.c.bad-mime	2008-08-05 17:56:11.0 +0200
+++ openssl-0.9.8j/crypto/asn1/asn_mime.c	2009-01-14 22:08:34.0 +0100
@@ -792,6 +792,10 @@ static int mime_hdr_addparam(MIME_HEADER
 static int mime_hdr_cmp(const MIME_HEADER * const *a,
 			const MIME_HEADER * const *b)
 {
+	if ((*a)-name == NULL || (*b)-name == NULL)
+		return (*a)-name - (*b)-name  0 ? -1 :
+			(*a)-name - (*b)-name  0 ? 1 : 0;
+
 	return(strcmp((*a)-name, (*b)-name));
 }
 

[openssl.org #2712] Be more liberal when trying to recognize the XMPP starttls headers

[Tomas Mraz via RT]

The attached simple patch allows other possible syntaxes of XMPP
starttls headers to be recognized.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -ru openssl-1.0.0d.old/apps/s_client.c openssl-1.0.0d/apps/s_client.c
--- openssl-1.0.0d.old/apps/s_client.c	2011-07-17 21:05:19.934181169 +0200
+++ openssl-1.0.0d/apps/s_client.c	2011-07-17 21:11:42.747824990 +0200
@@ -1186,7 +1186,7 @@
 		xmlns='jabber:client' to='%s' version='1.0', host);
 		seen = BIO_read(sbio,mbuf,BUFSIZZ);
 		mbuf[seen] = 0;
-		while (!strstr(mbuf, starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'))
+		while (!strcasestr(mbuf, starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls')  !strcasestr(mbuf, starttls xmlns=\urn:ietf:params:xml:ns:xmpp-tls\))
 			{
 			if (strstr(mbuf, /stream:features))
 goto shut;

[openssl.org #2713] Move libraries that are not needed for dynamic linking to Libs.private in the .pc files

[Tomas Mraz via RT]

The attached simple patch moves the libraries that are not needed for
dynamic linking to the Libs.private section in the OpenSSL .pc files.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0e/Makefile.org.private openssl-1.0.0e/Makefile.org
--- openssl-1.0.0e/Makefile.org.private	2011-11-03 10:01:53.0 +0100
+++ openssl-1.0.0e/Makefile.org	2011-11-22 11:50:27.0 +0100
@@ -326,7 +326,8 @@ libcrypto.pc: Makefile
 	echo 'Description: OpenSSL cryptography library'; \
 	echo 'Version: '$(VERSION); \
 	echo 'Requires: '; \
-	echo 'Libs: -L$${libdir} -lcrypto $(EX_LIBS)'; \
+	echo 'Libs: -L$${libdir} -lcrypto'; \
+	echo 'Libs.private: $(EX_LIBS)'; \
 	echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' )  libcrypto.pc
 
 libssl.pc: Makefile
@@ -339,7 +340,8 @@ libssl.pc: Makefile
 	echo 'Description: Secure Sockets Layer and cryptography libraries'; \
 	echo 'Version: '$(VERSION); \
 	echo 'Requires: '; \
-	echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
+	echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
+	echo 'Libs.private: $(EX_LIBS)'; \
 	echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' )  libssl.pc
 
 openssl.pc: Makefile
@@ -352,7 +354,8 @@ openssl.pc: Makefile
 	echo 'Description: Secure Sockets Layer and cryptography libraries and tools'; \
 	echo 'Version: '$(VERSION); \
 	echo 'Requires: '; \
-	echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
+	echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
+	echo 'Libs.private: $(EX_LIBS)'; \
 	echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' )  openssl.pc
 
 Makefile: Makefile.org Configure config

[openssl.org #2714] Fix build with no-srp option

[Tomas Mraz via RT]

OpenSSL-1.0.1-beta2 build with no-srp option fails because there are
some missing #ifdef OPENSSL_NO_SRP directives in the s_server code. The
attached patch fixes this.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.1-beta2/apps/progs.pl.no-srp openssl-1.0.1-beta2/apps/progs.pl
--- openssl-1.0.1-beta2/apps/progs.pl.no-srp	2009-06-30 17:08:38.0 +0200
+++ openssl-1.0.1-beta2/apps/progs.pl	2012-02-07 01:14:08.979758307 +0100
@@ -51,6 +51,8 @@ foreach (@ARGV)
 		{ print #ifndef OPENSSL_NO_CMS\n${str}#endif\n; }
 	elsif ( ($_ =~ /^ocsp$/))
 		{ print #ifndef OPENSSL_NO_OCSP\n${str}#endif\n; }
+	elsif ( ($_ =~ /^srp$/))
+		{ print #ifndef OPENSSL_NO_SRP\n${str}#endif\n; }
 	else
 		{ print $str; }
 	}
diff -up openssl-1.0.1-beta2/apps/s_server.c.no-srp openssl-1.0.1-beta2/apps/s_server.c
--- openssl-1.0.1-beta2/apps/s_server.c.no-srp	2012-02-07 01:04:12.0 +0100
+++ openssl-1.0.1-beta2/apps/s_server.c	2012-02-07 01:13:21.573362310 +0100
@@ -2248,6 +2248,7 @@ static int sv_body(char *hostname, int s
 { static count=0; if (++count == 100) { count=0; SSL_renegotiate(con); } }
 #endif
 k=SSL_write(con,(buf[l]),(unsigned int)i);
+#ifndef OPENSSL_NO_SRP
 while (SSL_get_error(con,k) == SSL_ERROR_WANT_X509_LOOKUP)
 	{
 	BIO_printf(bio_s_out,LOOKUP renego during write\n);
@@ -2258,6 +2259,7 @@ static int sv_body(char *hostname, int s
 		BIO_printf(bio_s_out,LOOKUP not successful\n);
 		k=SSL_write(con,(buf[l]),(unsigned int)i);
 	}
+#endif
 switch (SSL_get_error(con,k))
 	{
 case SSL_ERROR_NONE:
@@ -2305,6 +2307,7 @@ static int sv_body(char *hostname, int s
 {
 again:	
 i=SSL_read(con,(char *)buf,bufsize);
+#ifndef OPENSSL_NO_SRP
 while (SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP)
 	{
 	BIO_printf(bio_s_out,LOOKUP renego during read\n);
@@ -2315,6 +2318,7 @@ again:
 		BIO_printf(bio_s_out,LOOKUP not successful\n);
 	i=SSL_read(con,(char *)buf,bufsize);
 	}
+#endif
 switch (SSL_get_error(con,i))
 	{
 case SSL_ERROR_NONE:
@@ -2392,6 +2396,7 @@ static int init_ssl_connection(SSL *con)
 
 
 	i=SSL_accept(con);
+#ifndef OPENSSL_NO_SRP
 	while (i = 0   SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP) 
 		{
 			BIO_printf(bio_s_out,LOOKUP during accept %s\n,srp_callback_parm.login);
@@ -2402,6 +2407,7 @@ static int init_ssl_connection(SSL *con)
 BIO_printf(bio_s_out,LOOKUP not successful\n);
 			i=SSL_accept(con);
 		}
+#endif
 	if (i = 0)
 		{
 		if (BIO_sock_should_retry(i))
@@ -2626,6 +2632,7 @@ static int www_body(char *hostname, int
 		if (hack)
 			{
 			i=SSL_accept(con);
+#ifndef OPENSSL_NO_SRP
 			while (i = 0   SSL_get_error(con,i) == SSL_ERROR_WANT_X509_LOOKUP) 
 		{
 			BIO_printf(bio_s_out,LOOKUP during accept %s\n,srp_callback_parm.login);
@@ -2636,7 +2643,7 @@ static int www_body(char *hostname, int
 BIO_printf(bio_s_out,LOOKUP not successful\n);
 			i=SSL_accept(con);
 		}
-
+#endif
 			switch (SSL_get_error(con,i))
 {
 			case SSL_ERROR_NONE:

[openssl.org #2641] Move the libraries needed for static linking to Libs.private

[Tomas Mraz via RT]

The attached patch changes the generated pkgconfig files so the
libraries needed for static linking are in Libs.private instead of Libs.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0e/Makefile.org.private openssl-1.0.0e/Makefile.org
--- openssl-1.0.0e/Makefile.org.private	2011-11-03 10:01:53.0 +0100
+++ openssl-1.0.0e/Makefile.org	2011-11-22 11:50:27.0 +0100
@@ -326,7 +326,8 @@ libcrypto.pc: Makefile
 	echo 'Description: OpenSSL cryptography library'; \
 	echo 'Version: '$(VERSION); \
 	echo 'Requires: '; \
-	echo 'Libs: -L$${libdir} -lcrypto $(EX_LIBS)'; \
+	echo 'Libs: -L$${libdir} -lcrypto'; \
+	echo 'Libs.private: $(EX_LIBS)'; \
 	echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' )  libcrypto.pc
 
 libssl.pc: Makefile
@@ -339,7 +340,8 @@ libssl.pc: Makefile
 	echo 'Description: Secure Sockets Layer and cryptography libraries'; \
 	echo 'Version: '$(VERSION); \
 	echo 'Requires: '; \
-	echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
+	echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
+	echo 'Libs.private: $(EX_LIBS)'; \
 	echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' )  libssl.pc
 
 openssl.pc: Makefile
@@ -352,7 +354,8 @@ openssl.pc: Makefile
 	echo 'Description: Secure Sockets Layer and cryptography libraries and tools'; \
 	echo 'Version: '$(VERSION); \
 	echo 'Requires: '; \
-	echo 'Libs: -L$${libdir} -lssl -lcrypto $(EX_LIBS)'; \
+	echo 'Libs: -L$${libdir} -lssl -lcrypto'; \
+	echo 'Libs.private: $(EX_LIBS)'; \
 	echo 'Cflags: -I$${includedir} $(KRB5_INCLUDES)' )  openssl.pc
 
 Makefile: Makefile.org Configure config

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

[Tomas Mraz via RT]

On Fri, 2011-11-18 at 12:16 +0100, Andy Polyakov via RT wrote: 
  commit 6c3f6041172b78d5532c6bf3680d304e92ec2e66
  Author: Sheng Yang sh...@linux.intel.com
  Date:   Tue Jun 22 13:49:21 2010 +0800
  
  KVM: x86: Enable AVX for guest
  
  Enable Intel(R) Advanced Vector Extension(AVX) for guest.
  
  The detection of AVX feature includes OSXSAVE bit testing. When
  OSXSAVE bit 
  not set, even if AVX is supported, the AVX instruction would result
  in UD
  as
  well. So we're safe to expose AVX bits to guest directly.
  
  Signed-off-by: Sheng Yang sh...@linux.intel.com
  Signed-off-by: Avi Kivity a...@redhat.com
 
 This kind of sounds that it *was* masked and they decided to change
 this. Question is why? BTW, why isn't FMA flag discussed at the same time?
 
  Latest KVM still exposes AVX, and sets OSXSAVE to 0. This gives the
  guest
  kernel the option, which is based on XSAVE.
 
 This kind sounds that KVM maintains per-guest XCR0 in which case it's
 indeed more than appropriate to stop masking AVX flag. I.e. is it
 possible to conclude that what it was masked earlier and they stopped
 masking it after making KVM XCR0-aware? If so, why do you find it
 appropriate to not mask it without making Xen XCR0-aware? But the
 question is more of rhetorical character... because we kind of agree
 that latest version is acceptable, right?

I forwarded your other questions to our virtualization developers.
However for the last question the answer is yes, the latest version is
acceptable.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

[Tomas Mraz via RT]

On Tue, 2011-11-08 at 22:29 +0100, Andy Polyakov via RT wrote: 
  As for XEN, if it in fact masks XSAVE, but not AVX bits, than even
  check for XSAVE bit should 'jnc (label(clear_avx));' instead of
  done. As well as that x86_64cpuid.pl should test for XSAVE...
  That would also work, but it's useless because the spec OTOH says that 
  you *can* ignore XSAVE (and anyway XSAVE means nothing: it says the 
  feature is available, but only OSXSAVE says it is actually unusable).
  I still fail to see how exactly did it fail for you. Once again, which
  flags does guest OS observe exactly? Is guest OS YMM-capable? Does
  latest x86cpuid.pl work for you or is it still problem?
  No, it does not work as the cpuid on the guest OS observes cleared XSAVE
  and set AVX bit.
 
 How does XSAVE end up being 0? Hypervisor masks it, right? By what
 means? Through a config file or is it explicitly programmed? What was
 the reasoning for masking it? In config file or code? Why same reasoning
 didn't apply to AVX [as FMA] bit? As implied, I'd argue that it's
 inappropriate to mask XSAVE but not AVX [and FMA].
 
 Either way, can you at least tell if it's controlled through config? Or
 in other words, it it possible to work around the problem by configuring
 your Xen? Context of the question is frozen FIPS code.
 
  Which means that the AVX instructions will be used in
  the SHA1 code which then fail with SIGILL.
  
  The OSXSAVE is also cleared so that means if the XSAVE test was just
  dropped it would work.
 
 So would jumping to clear_avx if XSAVE is 0, right? Anyway, see
 http://cvs.openssl.org/chngview?cn=21675.
 
Forwarding reply from our virtualization developers:

RHEL5 Xen's cpuid masking is hardcoded in the HV (so no nice config to
quick
modify). We've recently changed it to be a whitelist, where the
structure is
heavily influenced by KVM. Looking at KVM's whitelist patch history I
found
this commit, which I believe describes this issue best.

commit 6c3f6041172b78d5532c6bf3680d304e92ec2e66
Author: Sheng Yang sh...@linux.intel.com
Date:   Tue Jun 22 13:49:21 2010 +0800

KVM: x86: Enable AVX for guest

Enable Intel(R) Advanced Vector Extension(AVX) for guest.

The detection of AVX feature includes OSXSAVE bit testing. When
OSXSAVE bit 
not set, even if AVX is supported, the AVX instruction would result
in UD
as
well. So we're safe to expose AVX bits to guest directly.

Signed-off-by: Sheng Yang sh...@linux.intel.com
Signed-off-by: Avi Kivity a...@redhat.com

Latest KVM still exposes AVX, and sets OSXSAVE to 0. This gives the
guest
kernel the option, which is based on XSAVE. Now, RHEL Xen masks XSAVE,
so the
option isn't really there for its guest kernels, but I don't believe
that means
we can't rely on the same protocol.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

[Tomas Mraz via RT]

On Sat, 2011-11-05 at 11:53 +0100, Andy Polyakov via RT wrote:

  x86cpuid.pl instead is completely broken:
  
  - the whole test is bypassed if XSAVE=1, which makes absolutely no sense. 
  x86_64cpuid.pl is right in testing OSXSAVE
 
 No, the test is bypassed if XSAVE is 0, not 1. XSAVE being 0 also
 implies that AVX flag [as well as FMA and XOP] is 0, which is why is
 jumps to 'done' and not 'clear_avx'.

This assertion is unfortunately not true on RHEL-6 guests on AVX capable
CPUs in XEN VM.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #2637] Missing documentation for -no_ign_eof option

[Tomas Mraz via RT]

The attached patch adds missing documentation for the -no_ign_eof
option.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0e/doc/apps/s_client.pod.doc-noeof openssl-1.0.0e/doc/apps/s_client.pod
--- openssl-1.0.0e/doc/apps/s_client.pod.doc-noeof	2009-06-26 13:28:51.0 +0200
+++ openssl-1.0.0e/doc/apps/s_client.pod	2011-11-03 08:30:35.0 +0100
@@ -27,6 +27,7 @@ Bopenssl Bs_client
 [B-nbio]
 [B-crlf]
 [B-ign_eof]
+[B-no_ign_eof]
 [B-quiet]
 [B-ssl2]
 [B-ssl3]
@@ -161,6 +162,11 @@ by some servers.
 inhibit shutting down the connection when end of file is reached in the
 input.
 
+=item B-no_ign_eof
+
+shut down the connection when end of file is reached in the
+input. Can be used to override the implicit B-ign_eof after B-quiet.
+
 =item B-quiet
 
 inhibit printing of session and certificate information.  This implicitly

[openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

[Tomas Mraz via RT]

Here is analysis by Paolo Bonzini:

I compared crypto/x86_64cpuid.pl and crypto/x86cpuid.pl, and the code in the
latter is wrong.

From x86_64cpuid.pl:

mov %edx,%r10d  # %r9d:%r10d is copy of %ecx:%edx
bt  \$27,%r9d   # check OSXSAVE bit
jnc .Lclear_avx
xor %ecx,%ecx   # XCR0
.byte   0x0f,0x01,0xd0  # xgetbv
and \$6,%eax# isolate XMM and YMM state support
cmp \$6,%eax
je  .Ldone
.Lclear_avx:
mov \$0xefffe7ff,%eax   # ~(128|112|111)
and %eax,%r9d   # clear AVX, FMA and AMD XOP bits
.Ldone:


From x86cpuid.pl:

bt (ecx,26); # check XSAVE bit
jnc(label(done));
bt (ecx,27); # check OSXSAVE bit
jnc(label(clear_xmm));
xor(ecx,ecx);
data_byte(0x0f,0x01,0xd0); # xgetbv
and(eax,6);
cmp(eax,6);
je (label(done));
cmp(eax,2);
je (label(clear_avx));
set_label(clear_xmm);
and(ebp,0xfdfd); # clear AESNI and PCLMULQDQ bits
and(esi,0xfeff); # clear FXSR
set_label(clear_avx);
and(ebp,0xefffe7ff); # clear AVX, FMA and AMD XOP bits
set_label(done);


x86_64cpuid.pl is not completely correct; if bit 1 of EAX was zero (XMM support
not enabled in the OS) you would need to clear AESNI and PCLMULQDQ bits as done
in x86cpuid.pl.  However, in practice does not matter because any OS new enough
to set OSXSAVE will always enable XMM support as well.

x86cpuid.pl instead is completely broken:

- the whole test is bypassed if XSAVE=1, which makes absolutely no sense. 
x86_64cpuid.pl is right in testing OSXSAVE

- if OSXSAVE=0, all SSE code is disabled, which also makes no sense because any
OS less than 10 years old lets you use SSE even if it does not set OSXSAVE (via
FXSAVE), and this includes of course RHEL6.

The attached patch (unfortunately not yet tested) synchronizes the two tests.

--- crypto/x86cpuid.pl	2011-10-26 17:13:03.599641479 +0200
+++ crypto/x86cpuid.pl	2011-10-26 17:41:04.400262001 +0200
@@ -119,20 +119,13 @@
 	mov	(esi,edx);
 	or	(ebp,ecx);		# merge AMD XOP flag
 
-	bt	(ecx,26);		# check XSAVE bit
-	jnc	(label(done));
 	bt	(ecx,27);		# check OSXSAVE bit
-	jnc	(label(clear_xmm));
-	xor	(ecx,ecx);
+	jnc	(label(clear_avx));
+	xor	(ecx,ecx);  # XCR0
 	data_byte(0x0f,0x01,0xd0);	# xgetbv
-	and	(eax,6);
+	and	(eax,6);  # isolate XMM and YMM state support
 	cmp	(eax,6);
 	je	(label(done));
-	cmp	(eax,2);
-	je	(label(clear_avx));
-set_label(clear_xmm);
-	and	(ebp,0xfdfd);	# clear AESNI and PCLMULQDQ bits
-	and	(esi,0xfeff);	# clear FXSR
 set_label(clear_avx);
 	and	(ebp,0xefffe7ff);	# clear AVX, FMA and AMD XOP bits
 set_label(done);

[openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389

[Tomas Mraz via RT]

Here is an experimental patch I wrote that implements the 1/n-1
record splitting technique for OpenSSL. I am sending it here for
consideration by OpenSSL upstream developers.

By default the 0/n split is used but in case the
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first
record with 1/n-1.

Tomas Mraz

diff -up openssl-1.0.0e/ssl/s3_both.c.beast openssl-1.0.0e/ssl/s3_both.c
--- openssl-1.0.0e/ssl/s3_both.c.beast	2010-03-25 00:16:49.0 +0100
+++ openssl-1.0.0e/ssl/s3_both.c	2011-10-13 14:05:50.0 +0200
@@ -758,15 +758,12 @@ int ssl3_setup_write_buffer(SSL *s)
 	if (s-s3-wbuf.buf == NULL)
 		{
 		len = s-max_send_fragment
-			+ SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD
-			+ headerlen + align;
+			+ 2 * (SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD
+			+ headerlen + align);
 #ifndef OPENSSL_NO_COMP
 		if (!(s-options  SSL_OP_NO_COMPRESSION))
 			len += SSL3_RT_MAX_COMPRESSED_OVERHEAD;
 #endif
-		if (!(s-options  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS))
-			len += headerlen + align
-+ SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD;
 
 		if ((p=freelist_extract(s-ctx, 0, len)) == NULL)
 			goto err;
diff -up openssl-1.0.0e/ssl/s3_enc.c.beast openssl-1.0.0e/ssl/s3_enc.c
--- openssl-1.0.0e/ssl/s3_enc.c.beast	2011-09-07 14:00:41.0 +0200
+++ openssl-1.0.0e/ssl/s3_enc.c	2011-10-13 14:05:50.0 +0200
@@ -428,23 +428,20 @@ int ssl3_setup_key_block(SSL *s)
 
 	ret = ssl3_generate_key_block(s,p,num);
 
-	if (!(s-options  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS))
+	/* enable vulnerability countermeasure for CBC ciphers with
+	 * known-IV problem (http://www.openssl.org/~bodo/tls-cbc.txt)
+	 */
+	s-s3-need_empty_fragments = 1 + (s-options  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS ? 1 : 0);
+
+	if (s-session-cipher != NULL)
 		{
-		/* enable vulnerability countermeasure for CBC ciphers with
-		 * known-IV problem (http://www.openssl.org/~bodo/tls-cbc.txt)
-		 */
-		s-s3-need_empty_fragments = 1;
+		if (s-session-cipher-algorithm_enc == SSL_eNULL)
+			s-s3-need_empty_fragments = 0;
 
-		if (s-session-cipher != NULL)
-			{
-			if (s-session-cipher-algorithm_enc == SSL_eNULL)
-s-s3-need_empty_fragments = 0;
-			
 #ifndef OPENSSL_NO_RC4
-			if (s-session-cipher-algorithm_enc == SSL_RC4)
-s-s3-need_empty_fragments = 0;
+		if (s-session-cipher-algorithm_enc == SSL_RC4)
+			s-s3-need_empty_fragments = 0;
 #endif
-			}
 		}
 
 	return ret;
diff -up openssl-1.0.0e/ssl/s3_pkt.c.beast openssl-1.0.0e/ssl/s3_pkt.c
--- openssl-1.0.0e/ssl/s3_pkt.c.beast	2011-05-25 17:21:12.0 +0200
+++ openssl-1.0.0e/ssl/s3_pkt.c	2011-10-13 14:05:50.0 +0200
@@ -685,7 +685,10 @@ static int do_ssl3_write(SSL *s, int typ
 			 * this prepares and buffers the data for an empty fragment
 			 * (these 'prefix_len' bytes are sent out later
 			 * together with the actual payload) */
-			prefix_len = do_ssl3_write(s, type, buf, 0, 1);
+			prefix_len = do_ssl3_write(s, type, buf,
+		   s-s3-need_empty_fragments-1, 1);
+			buf += s-s3-need_empty_fragments-1;
+			len -= s-s3-need_empty_fragments-1;
 			if (prefix_len = 0)
 goto err;
 
diff -up openssl-1.0.0e/ssl/t1_enc.c.beast openssl-1.0.0e/ssl/t1_enc.c
--- openssl-1.0.0e/ssl/t1_enc.c.beast	2011-09-07 14:00:41.0 +0200
+++ openssl-1.0.0e/ssl/t1_enc.c	2011-10-13 14:07:55.0 +0200
@@ -608,23 +608,20 @@ printf(\nkey block\n);
 { int z; for (z=0; znum; z++) printf(%02X%c,p1[z],((z+1)%16)?' ':'\n'); }
 #endif
 
-	if (!(s-options  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS))
+	/* enable vulnerability countermeasure for CBC ciphers with
+	 * known-IV problem (http://www.openssl.org/~bodo/tls-cbc.txt)
+	 */
+	s-s3-need_empty_fragments = 1 + (s-options  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS ? 1 : 0);
+
+	if (s-session-cipher != NULL)
 		{
-		/* enable vulnerability countermeasure for CBC ciphers with
-		 * known-IV problem (http://www.openssl.org/~bodo/tls-cbc.txt)
-		 */
-		s-s3-need_empty_fragments = 1;
+		if (s-session-cipher-algorithm_enc == SSL_eNULL)
+			s-s3-need_empty_fragments = 0;
 
-		if (s-session-cipher != NULL)
-			{
-			if (s-session-cipher-algorithm_enc == SSL_eNULL)
-s-s3-need_empty_fragments = 0;
-			
 #ifndef OPENSSL_NO_RC4
-			if (s-session-cipher-algorithm_enc == SSL_RC4)
-s-s3-need_empty_fragments = 0;
+		if (s-session-cipher-algorithm_enc == SSL_RC4)
+			s-s3-need_empty_fragments = 0;
 #endif
-			}
 		}
 		
 	ret = 1;

[openssl.org #2616] Missing initialization in the CHIL engine

[Tomas Mraz via RT]

There is a missing initialization of a variable in the CHIL engine. In
case the uninitialized value of the variable answer is 'C' and there is
no prompt, the engine startup will erroneously fail.
The attached patch fixes this.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0e/engines/e_chil.c.chil openssl-1.0.0e/engines/e_chil.c
--- openssl-1.0.0e/engines/e_chil.c.chil	2010-06-15 19:25:12.0 +0200
+++ openssl-1.0.0e/engines/e_chil.c	2011-09-21 17:32:03.0 +0200
@@ -1287,7 +1287,7 @@ static int hwcrhk_insert_card(const char
 
 	if (ui)
 		{
-		char answer;
+		char answer = '\0';
 		char buf[BUFSIZ];
 		/* Despite what the documentation says wrong_info can be
 	 	 * an empty string.

[openssl.org #2572] Correct help output in openssl cms

[Tomas Mraz via RT]

openssl cms help output contains -skeyid option which is actually -keyid
option as recognized by the cms code. The attached trivial patch
corrects the help output.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0d/apps/cms.c.keyid openssl-1.0.0d/apps/cms.c
--- openssl-1.0.0d/apps/cms.c.keyid	2009-10-18 16:42:26.0 +0200
+++ openssl-1.0.0d/apps/cms.c	2011-07-26 12:56:48.0 +0200
@@ -618,7 +618,7 @@ int MAIN(int argc, char **argv)
 		BIO_printf (bio_err, -certsout file certificate output file\n);
 		BIO_printf (bio_err, -signer file   signer certificate file\n);
 		BIO_printf (bio_err, -recip  file   recipient certificate file for decryption\n);
-		BIO_printf (bio_err, -skeyiduse subject key identifier\n);
+		BIO_printf (bio_err, -keyid use subject key identifier\n);
 		BIO_printf (bio_err, -in file   input file\n);
 		BIO_printf (bio_err, -inform arginput format SMIME (default), PEM or DER\n);
 		BIO_printf (bio_err, -inkey fileinput private key (if not signer or recipient)\n);

[openssl.org #2565] More tolerant detection of XMPP starttls sequence

[Tomas Mraz via RT]

The attached patch written by J.H.M Ray Dassen improves detection of the
XMPP starttls sequence for s_client. Please consider applying it.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -ru openssl-1.0.0d.old/apps/s_client.c openssl-1.0.0d/apps/s_client.c
--- openssl-1.0.0d.old/apps/s_client.c	2011-07-17 21:05:19.934181169 +0200
+++ openssl-1.0.0d/apps/s_client.c	2011-07-17 21:11:42.747824990 +0200
@@ -1186,7 +1186,7 @@
 		xmlns='jabber:client' to='%s' version='1.0', host);
 		seen = BIO_read(sbio,mbuf,BUFSIZZ);
 		mbuf[seen] = 0;
-		while (!strstr(mbuf, starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'))
+		while (!strcasestr(mbuf, starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls')  !strcasestr(mbuf, starttls xmlns=\urn:ietf:params:xml:ns:xmpp-tls\))
 			{
 			if (strstr(mbuf, /stream:features))
 goto shut;

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

[Tomas Mraz via RT]

There is code error in s3_srvr.c function ssl3_get_cert_verify().

There is a condition if ((peer != NULL)  (type | EVP_PKT_SIGN))
- the second part of the condition is a no-op. The correct condition
should be if ((peer != NULL)  (type  EVP_PKT_SIGN)) although the
non-signing certificates with static DH parameters are not really used.

The bug was found by Coverity scan.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: [openssl.org #2395] openssl-1.0.0c bug: Decoding cert causes segv in ASN1 code

[Tomas Mraz via RT]

 int mk_test_cert(int buflen, char* buf)
 {
   char*  p;
   char*  q;
   X509*  sign_cert;
 
   q = unbase64_raw(cert_b64, cert_b64+sizeof(cert_b64)-1, p=buf, 
 std_index_64);
   if (!d2i_X509(sign_cert, p, q-p) || !sign_cert) {

You're passing uninitialized X509* pointer sign_cert to the d2i_X509().
The function then tries to reuse the structure that the pointer is
supposed to be pointing to.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #2347] Wrong help in the openssl cms command

[Tomas Mraz via RT]

There is -skeyid option described in the help of the openssl cms
command. However the cms application expects -keyid option instead. The
attached patch corrects the error in the help.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


diff -up openssl-1.0.0a/apps/cms.c.keyid openssl-1.0.0a/apps/cms.c
--- openssl-1.0.0a/apps/cms.c.keyid	2009-10-18 16:42:26.0 +0200
+++ openssl-1.0.0a/apps/cms.c	2010-09-23 16:28:50.0 +0200
@@ -618,7 +618,7 @@ int MAIN(int argc, char **argv)
 		BIO_printf (bio_err, -certsout file certificate output file\n);
 		BIO_printf (bio_err, -signer file   signer certificate file\n);
 		BIO_printf (bio_err, -recip  file   recipient certificate file for decryption\n);
-		BIO_printf (bio_err, -skeyiduse subject key identifier\n);
+		BIO_printf (bio_err, -keyid use subject key identifier\n);
 		BIO_printf (bio_err, -in file   input file\n);
 		BIO_printf (bio_err, -inform arginput format SMIME (default), PEM or DER\n);
 		BIO_printf (bio_err, -inkey fileinput private key (if not signer or recipient)\n);

[openssl.org #2171] ssl2 is unnecessarily rejected as not supporting the safe renegotiation

[Tomas Mraz via RT]

As SSLv2 does not specify any renegotiation at all does it really make
sense to reject it in the ssl23_get_client_hello() if legacy
renegotiation is not enabled in the ssl options?

openssl s_server when contacted with openssl s_client -sslv2 returns:
140392456742728:error:14076152:SSL
routines:SSL23_GET_CLIENT_HELLO:unsafe legacy renegotiation
disabled:s23_srvr.c:509:
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

[openssl.org #2169] OPENSSL_cleanse does not handle zero length gracefully

[Tomas Mraz via RT]

The various OPENSSL_cleanse assembler implementations in contrast with
the C implementation do not handle zero length gracefully - that is
returning without touching the memory. Instead they overflow and
segfault.

Steps to reproduce:

echo 'test' | openssl dgst -md5 -hmac ''

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

[openssl.org #2127] Missing checks for unavailable algorithms in EVP_PBE_CipherInit

[Tomas Mraz via RT]

In the function EVP_PBE_CipherInit there are missing checks for
unavailable algorithms (such as when they are not compiled in or when
OpenSSL_add_all_algorithms() is not called).

The attached patch adds the checks although probably new error codes
should be added for these failures.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0-beta4/crypto/evp/evp_pbe.c.no-cipher openssl-1.0.0-beta4/crypto/evp/evp_pbe.c
--- openssl-1.0.0-beta4/crypto/evp/evp_pbe.c.no-cipher	2008-11-05 19:38:57.0 +0100
+++ openssl-1.0.0-beta4/crypto/evp/evp_pbe.c	2009-12-14 22:54:27.0 +0100
@@ -174,12 +174,20 @@ int EVP_PBE_CipherInit(ASN1_OBJECT *pbe_
 	if (cipher_nid == -1)
 		cipher = NULL;
 	else
-		cipher = EVP_get_cipherbynid(cipher_nid);
+		if ((cipher = EVP_get_cipherbynid(cipher_nid)) == NULL)
+			{
+			EVPerr(EVP_F_EVP_PBE_CIPHERINIT,EVP_R_KEYGEN_FAILURE);
+			return 0;
+			}
 
 	if (md_nid == -1)
 		md = NULL;
 	else
-		md = EVP_get_digestbynid(md_nid);
+		if ((md = EVP_get_digestbynid(md_nid)) == NULL)
+			{
+			EVPerr(EVP_F_EVP_PBE_CIPHERINIT,EVP_R_KEYGEN_FAILURE);
+			return 0;
+			}
 
 	if (!keygen(ctx, pass, passlen, param, cipher, md, en_de))
 		{

[openssl.org #2128] PKCS12_PBE_add is a noop but maybe it should add the algorithms?

[Tomas Mraz via RT]

If you call just SSL_library_init() and PKCS12_PBE_add some pkcs12 files
will not be loadable and moreover the openssl will crash due to missing
checks for ciphers not found. I've reported the crash in a separate
report. Perhaps the PKCS12_PBE_add should add the algorithms which are
not added in the SSL_library_init() call but which are used in the
static PBE algorithms table?
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #2105] Please reconsider the client side of the CVE-2009-3555 fix in 1.0.0

[Tomas Mraz via RT]

On Fri, 2009-12-11 at 14:14 +0100, Stephen Henson via RT wrote: 
 The problem of adding fields to SSL_CTX and SSL has been mentioned by a
 number of people before. How bad is that in practice? SSL_CTX and SSL
 structures are both allocated dynamically so the size change wont
 matter. The only remaining case is applications that access the fields
 directly instead of using APIs.
 
 We should and will make the SSL and SSL_CTX structures opaque at some
 point but not during a beta release cycle ;-)

As for the ABI breakage I think it would be minimal if the additional
fields were added to the end of the struct. I do not expect that offsets
of the other fields would change on any reasonable C ABIs. As the
structures should never be allocated directly by the application I think
this breakage could be tolerated in beta.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #2105] Please reconsider the client side of the CVE-2009-3555 fix in 1.0.0

[Tomas Mraz via RT]

The TLS client in openssl-1.0.0 branch aborts the connection if
SSL_OP_ALLOW_UNSAFE_RENEGOTIATION (or SSL_OP_ALL) flag is not set by the
calling application and the connected server does not return the
extension in the server hello message. Unfortunately too many
applications do not set SSL_OP_ALL which makes them incompatible with
currently virtually every server as the renegotiation extension
supporting servers are not deployed yet. I propose adding a new flag for
the client which would explicitely disable connection to unsafe servers
and to allow this connection by default. For now in Fedora I am forced
to just disable the client side check.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=537962

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

[openssl.org #2072] Avoid potential doublefree and reuse of freed handshake_buffer

[Tomas Mraz via RT]

The attached patch against 1.0.0 fixes a potential doublefree and reuse
of freed handshake_buffer when SSL_clear() is called.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

--- s3_lib.c.hbuf-clear	2009-05-28 20:10:47.0 +0200
+++ s3_lib.c	2009-10-16 09:50:24.0 +0200
@@ -2211,6 +2211,7 @@ void ssl3_clear(SSL *s)
  	wlen = s-s3-wbuf.len;
 	if (s-s3-handshake_buffer) {
 		BIO_free(s-s3-handshake_buffer);
+		s-s3-handshake_buffer = NULL;
 	}
 	if (s-s3-handshake_dgst) {
 		ssl3_free_digest_list(s);

[openssl.org #2073] Avoid use of freed SSL_CTX in SSL_free()

[Tomas Mraz via RT]

The attached patch against 1.0.0 fixes a potential use
of freed SSL_CTX when SSL_free() is called after SSL_CTX_free()
in application.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0-beta3/ssl/ssl_lib.c.ctx-free openssl-1.0.0-beta3/ssl/ssl_lib.c
--- openssl-1.0.0-beta3/ssl/ssl_lib.c.ctx-free	2009-10-08 20:44:26.0 +0200
+++ openssl-1.0.0-beta3/ssl/ssl_lib.c	2009-10-16 11:56:53.0 +0200
@@ -556,7 +556,6 @@ void SSL_free(SSL *s)
 	if (s-cert != NULL) ssl_cert_free(s-cert);
 	/* Free up if allocated */
 
-	if (s-ctx) SSL_CTX_free(s-ctx);
 #ifndef OPENSSL_NO_TLSEXT
 	if (s-tlsext_hostname)
 		OPENSSL_free(s-tlsext_hostname);
@@ -580,6 +579,8 @@ void SSL_free(SSL *s)
 
 	if (s-method != NULL) s-method-ssl_free(s);
 
+	if (s-ctx) SSL_CTX_free(s-ctx);
+
 #ifndef	OPENSSL_NO_KRB5
 	if (s-kssl_ctx != NULL)
 		kssl_ctx_free(s-kssl_ctx);

Re: [openssl.org #1847] Bug in Openssl 0.9.8j CA.sh script

[Tomas Mraz via RT]

I've attached integrated changes to CA.sh script from RT #912, RT #1209,
and RT #1847 as one patch.
Please consider adding this at least to trunk and openssl-1.0 branch
CVS.
Thanks,
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

--- apps/CA.sh	2005-07-04 23:44:16.0 +0200
+++ download/CA.sh	2009-09-22 18:27:33.0 +0200
@@ -5,10 +5,10 @@
 #  things easier between now and when Eric is convinced to fix it :-)
 #
 # CA -newca ... will setup the right stuff
-# CA -newreq ... will generate a certificate request 
-# CA -sign ... will sign the generated request and output 
+# CA -newreq ... will generate a certificate request
+# CA -sign ... will sign the generated request and output
 #
-# At the end of that grab newreq.pem and newcert.pem (one has the key 
+# At the end of that grab newreq.pem and newcert.pem (one has the key
 # and the other the certificate) and cat them together and that is what
 # you want/need ... I'll make even this a little cleaner later.
 #
@@ -16,8 +16,8 @@
 # 12-Jan-96 tjhAdded more things ... including CA -signcert which
 #  converts a certificate to a request and then signs it.
 # 10-Jan-96 eayFixed a few more bugs and added the SSLEAY_CONFIG
-#		   environment variable so this can be driven from
-#		   a script.
+#  environment variable so this can be driven from
+#  a script.
 # 25-Jul-96 eayCleaned up filenames some more.
 # 11-Jun-96 eayFixed a few filename missmatches.
 # 03-May-96 eayModified to use 'ssleay cmd' instead of 'cmd'.
@@ -29,52 +29,87 @@
 
 # default openssl.cnf file has setup as per the following
 # demoCA ... where everything is stored
+cp_pem() {
+infile=$1
+outfile=$2
+bound=$3
+flag=0
+exec $infile;
+while read line; do
+	if [ $flag -eq 1 ]; then
+		echo $line|grep ^-END.*$bound  2/dev/null 1/dev/null
+		if [ $? -eq 0 ] ; then
+			echo $line $outfile
+			break
+		else
+			echo $line $outfile
+		fi
+	fi
+
+	echo $line|grep ^-BEGIN.*$bound  2/dev/null 1/dev/null
+	if [ $? -eq 0 ]; then
+		echo $line $outfile
+		flag=1
+	fi
+done
+}
+
+usage() {
+ echo usage: $0 -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify 2
+}
 
 if [ -z $OPENSSL ]; then OPENSSL=openssl; fi
 
-DAYS=-days 365	# 1 year
+if [ -z $DAYS ] ; then DAYS=-days 365 ; fi	# 1 year
 CADAYS=-days 1095	# 3 years
 REQ=$OPENSSL req $SSLEAY_CONFIG
 CA=$OPENSSL ca $SSLEAY_CONFIG
 VERIFY=$OPENSSL verify
 X509=$OPENSSL x509
+PKCS12=openssl pkcs12
 
-CATOP=./demoCA
+if [ -z $CATOP ] ; then CATOP=./demoCA ; fi
 CAKEY=./cakey.pem
 CAREQ=./careq.pem
 CACERT=./cacert.pem
 
-for i
-do
-case $i in
+RET=0
+
+while [ $1 !=  ] ; do
+case $1 in
 -\?|-h|-help)
-echo usage: CA -newcert|-newreq|-newca|-sign|-verify 2
+usage
 exit 0
 ;;
--newcert) 
+-newcert)
 # create a certificate
 $REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS
 RET=$?
 echo Certificate is in newcert.pem, private key is in newkey.pem
 ;;
--newreq) 
+-newreq)
 # create a certificate request
 $REQ -new -keyout newkey.pem -out newreq.pem $DAYS
 RET=$?
 echo Request is in newreq.pem, private key is in newkey.pem
 ;;
--newca) 
+-newreq-nodes) 
+# create a certificate request
+$REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS
+RET=$?
+echo Request (and private key) is in newreq.pem
+;;
+-newca)
 # if explicitly asked for or it doesn't exist then setup the directory
-# structure that Eric likes to manage things 
+# structure that Eric likes to manage things
 NEW=1
 if [ $NEW -o ! -f ${CATOP}/serial ]; then
 	# create the directory hierarchy
-	mkdir ${CATOP} 
-	mkdir ${CATOP}/certs 
-	mkdir ${CATOP}/crl 
-	mkdir ${CATOP}/newcerts
-	mkdir ${CATOP}/private
-	echo 00  ${CATOP}/serial
+	mkdir -p ${CATOP}
+	mkdir -p ${CATOP}/certs
+	mkdir -p ${CATOP}/crl
+	mkdir -p ${CATOP}/newcerts
+	mkdir -p ${CATOP}/private
 	touch ${CATOP}/index.txt
 fi
 if [ ! -f ${CATOP}/private/$CAKEY ]; then
@@ -83,37 +118,60 @@
 
 	# ask user for existing CA certificate
 	if [ $FILE ]; then
-	cp $FILE ${CATOP}/private/$CAKEY
+	cp_pem $FILE ${CATOP}/private/$CAKEY PRIVATE
+	cp_pem $FILE ${CATOP}/$CACERT CERTIFICATE
 	RET=$?
+	if [ ! -f ${CATOP}/serial ]; then
+		$X509 -in ${CATOP}/$CACERT -noout -next_serial \
+		  -out ${CATOP}/serial
+	fi
 	else
 	echo Making CA certificate ...
 	$REQ -new -keyout ${CATOP}/private/$CAKEY \
 			   -out ${CATOP}/$CAREQ
-	$CA -out ${CATOP}/$CACERT $CADAYS -batch \
+	$CA -create_serial -out ${CATOP}/$CACERT $CADAYS -batch \
 			   -keyfile ${CATOP}/private/$CAKEY -selfsign \
-			   -infiles ${CATOP}/$CAREQ 
+			   -extensions v3_ca \
+			   -infiles ${CATOP}/$CAREQ
 	RET=$?
 	fi
 fi
 ;;
 -xsign)
-$CA -policy policy_anything -infiles newreq.pem 
+$CA -policy 

Re: [openssl.org #2035] openssl speed camellia-192-cbc segfaults

[Tomas Mraz via RT]

On Sat, 2009-09-12 at 17:32 +0200, Andy Polyakov via RT wrote:

 Could you complement back-trace with 'info reg' output?

(gdb) bt
#0  _x86_64_Camellia_encrypt () at cmll-x86_64.s:74
#1  0x77a7a4b4 in Camellia_cbc_encrypt () at cmll-x86_64.s:1686
#2  0x7fffca30 in ?? ()
#3  0x0068e190 in ?? ()
#4  0x in ?? ()
(gdb) info reg
rax0x90a464 9479268
rbx0x7ee5f47f   2128999551
rcx0x0  0
rdx0xcef1a9fe   3471944190
rsi0xa6 166
rdi0xaf 175
rbp0x77a793c0   0x77a793c0
rsp0x7fffadb8   0x7fffadb8
r8 0x263e264d   641607245
r9 0x34a1c456   883016790
r100x6824eed3   1747250899
r110xcef1a9fe   3471944190
r120x68e180 6873472
r130x68e180 6873472
r140x7fffeff0   140737488351216
r150x207fbfcb30 9147661865175856
rip0x77a78570   0x77a78570 _x86_64_Camellia_encrypt+16
eflags 0x10282  [ SF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0
fctrl  0x37f895
fstat  0x0  0
ftag   0x   65535
fiseg  0x0  0
fioff  0x0  0
foseg  0x0  0
fooff  0x0  0
fop0x0  0
mxcsr  0x1f80   [ IM DM ZM OM UM PM ]


 Verify that following fixes the problem:
 
 --- crypto/camellia/asm/cmll-x86_64.pl  6 Apr 2009 15:13:16 -
 +++ crypto/camellia/asm/cmll-x86_64.pl  12 Sep 2009 15:20:49 -
 @@ -656,7 +656,7 @@
 mov %rsi,$out   # out argument
 mov %r8,%rbx# ivp argument
 mov %rcx,$key   # key argument
 -   mov 272(%rcx),$keyend   # grandRounds
 +   mov 272(%rcx),${keyend}d# grandRounds
 
 mov %r8,$_ivp
 mov %rbp,$_rsp

Yes, this patch fixes the problem.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #2035] openssl speed camellia-192-cbc segfaults

[Tomas Mraz via RT]

This was reported in Fedora bugzilla by Pekka Pietikainen :

The other variants seem fine, but

(gdb) set args speed camellia-192-cbc
(gdb) run
Starting program: /usr/bin/openssl speed camellia-192-cbc
[Thread debugging using libthread_db enabled]
Doing camellia-192 cbc for 3s on 16 size blocks: 
Program received signal SIGSEGV, Segmentation fault.
_x86_64_Camellia_encrypt () at cmll-x86_64.s:232
232  movl 64(%r14),%ebx
Current language:  auto
The current source language is auto; currently asm.
(gdb) bt
#0  _x86_64_Camellia_encrypt () at cmll-x86_64.s:232
#1  0x0036cfe814b4 in Camellia_cbc_encrypt () at cmll-x86_64.s:1686

which looks a bit worrying, considering the nature of openssl


This was reported on Red Hat rpm build of openssl.

I've tried to rebuild openssl with most patches especially touching
nearby code removed and it still segfaults. The compiler options are:

OpenSSL 1.0.0-beta3 15 Jul 2009
built on: Fri Sep  4 10:37:51 CEST 2009
options:bn(64,64) md2(int) rc4(1x,char) des(idx,cisc,16,int)
aes(partial) blowfish(ptr2) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack
-DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM

When compiled with default options it does not segfault however I don't
think that the options we use are the cause of the bug they just make
the problem appear (I suppose the -fstack-protector or _FORTIFY_SOURCE=2
can reveal this as they change things on the stack). Also I've found
that the necessary thing to trigger the bug is to have a large enough
array of 0 bytes on the stack after the Camellia key schedule.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

[openssl.org #2029] Fix openssl dgst -dss1

[Tomas Mraz via RT]

In the openssl-1.0.0-beta3 the command openssl dgst -dss1 -verify fails
with error:
Error setting context
139832466196296:error:0A07806A:dsa routines:PKEY_DSA_CTRL:invalid digest
type:dsa_pmeth.c:192:

See https://bugzilla.redhat.com/show_bug.cgi?id=520152 for detailed test
case.

I've patched the pkey_dsa_ctrl function to make the command work (see
the attached patch). However I am not quite sure the fix is completely
right.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0-beta3/crypto/dsa/dsa_pmeth.c.dss1 openssl-1.0.0-beta3/crypto/dsa/dsa_pmeth.c
--- openssl-1.0.0-beta3/crypto/dsa/dsa_pmeth.c.dss1	2008-11-05 19:38:56.0 +0100
+++ openssl-1.0.0-beta3/crypto/dsa/dsa_pmeth.c	2009-08-31 12:53:47.0 +0200
@@ -186,6 +186,7 @@ static int pkey_dsa_ctrl(EVP_PKEY_CTX *c
 
 		case EVP_PKEY_CTRL_MD:
 		if (EVP_MD_type((const EVP_MD *)p2) != NID_sha1   
+		EVP_MD_type((const EVP_MD *)p2) != NID_dsa
 		EVP_MD_type((const EVP_MD *)p2) != NID_sha224 
 		EVP_MD_type((const EVP_MD *)p2) != NID_sha256)
 			{

Re: [openssl.org #2020] [PATCH] tsget 1.0.0 b3

[Tomas Mraz via RT]

On Tue, 2009-08-25 at 08:43 +0200, Keith Beckman via RT wrote:
 I came up against some of the same problems as this poster to openssl-user:
 
 http://www.mail-archive.com/openssl-us...@openssl.org/msg56755.html
 
 This diff covers the improperly-capitalized references to
 WWW::Curl::Easy and a problem with some TSAs returning a non-standard
 mimetype for their response.

Here is better patch in unified diff.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0-beta3/apps/tsget.curl openssl-1.0.0-beta3/apps/tsget
--- openssl-1.0.0-beta3/apps/tsget.curl	2006-02-13 00:11:21.0 +0100
+++ openssl-1.0.0-beta3/apps/tsget	2009-08-21 15:37:24.0 +0200
@@ -7,7 +7,7 @@ use strict;
 use IO::Handle;
 use Getopt::Std;
 use File::Basename;
-use WWW::Curl::easy;
+use WWW::Curl::Easy;
 
 use vars qw(%options);
 
@@ -37,7 +37,7 @@ sub create_curl {
 my $url = shift;
 
 # Create Curl object.
-my $curl = WWW::Curl::easy::new();
+my $curl = WWW::Curl::Easy::new();
 
 # Error-handling related options.
 $curl-setopt(CURLOPT_VERBOSE, 1) if $options{d};
@@ -192,4 +192,4 @@ REQUEST: foreach (@ARGV) {
 STDERR-printflush(, $output written.\n) if $options{v};
 }
 $curl-cleanup();
-WWW::Curl::easy::global_cleanup();
+WWW::Curl::Easy::global_cleanup();

[openssl.org #2001] Missing commit on the 1.0.0 trunk

[Tomas Mraz via RT]

The 1.0.0 branch and trunk is missing the check-in
http://cvs.openssl.org/chngview?cn=14635
which fixes a memory leak in the RSA_setup_blinding() function.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

[openssl.org #2002] Mistake in linkage to krb5 library

[Tomas Mraz via RT]

There is a bug in the Makefile.org which breaks linking libssl to
libkrb5. The simple attached patch (against 1.0.0-beta3) solves the
problem.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

diff -up openssl-1.0.0-beta3/Makefile.org.krb5 openssl-1.0.0-beta3/Makefile.org
--- openssl-1.0.0-beta3/Makefile.org.krb5	2009-04-23 18:12:09.0 +0200
+++ openssl-1.0.0-beta3/Makefile.org	2009-08-04 23:01:16.0 +0200
@@ -299,7 +299,7 @@ build-shared: do_$(SHLIB_TARGET) link-sh
 
 do_$(SHLIB_TARGET):
 	@ set -e; libs='-L. $(SHLIBDEPS)'; for i in $(SHLIBDIRS); do \
-		if [ $(SHLIBDIRS) = ssl -a -n $(LIBKRB5) ]; then \
+		if [ $$i = ssl -a -n $(LIBKRB5) ]; then \
 			libs=$(LIBKRB5) $$libs; \
 		fi; \
 		$(CLEARENV)  $(MAKE) -f Makefile.shared -e $(BUILDENV) \

Re: [openssl.org #1853] Bugs in ./crpto/x509/x509_vfy.c and ./crpto/x509/x509_cmp.c

[Tomas Mraz via RT]

On Mon, 2009-03-09 at 15:10 +0100, Stephen Henson via RT wrote:

 An update to X509_NAME_cmp() was applied to 0.9.8-stable recently,
 please try a recent snapshot.

I do not think the fix is correct anyway. The only correct thing to do
if the value types are different is to return the j. Even with the fix
the function is not a stable comparsion function.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #1574] Session Ticket in OpenSSL 0.9.9 and EAP-FAST

[Tomas Mraz via RT]

We would really appreciate any comments on the possibility of getting
the patch into the official OpenSSL sources. Are the OpenSSL developers
interested in getting the EAP-FAST support into OpenSSL or they do not
want it at all and if so, then why?

Thanks for any response,
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #1574] Session Ticket in OpenSSL 0.9.9 and EAP-FAST

[Tomas Mraz via RT]

We are also interested in supporting EAP-FAST in wpa_supplicant. Can
someone from OpenSSL developers comment whether the approach taken in
this patch is feasible and if they are willing to accept it into
OpenSSL?
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #1629] BUG: SSLv3 only client broken with some servers

[Tomas Mraz via RT]

OpenSSL 0.9.8g SSLv3 only client (with tlsext support compiled in) is
broken when communicating with some servers.

Example:
openssl s_client -ssl3 -connect irc.mozilla.org:6697 -debug
CONNECTED(0003)
write to 0x67f3c0 [0x6891b0] (111 bytes = 111 (0x6F))
 - 16 03 00 00 6a 01 00 00-66 03 00 47 60 56 dc 7a   j...f..G`V.z
0010 - f6 39 00 47 08 6c 19 46-2e b6 c9 85 b6 68 88 59   .9.G.l.F.h.Y
0020 - e3 0e 79 96 df e1 68 ff-ea d0 0a 00 00 38 00 39   ..y...h..8.9
0030 - 00 38 00 35 00 88 00 87-00 84 00 16 00 13 00 0a   .8.5
0040 - 00 33 00 32 00 2f 00 9a-00 99 00 96 00 45 00 44   .3.2./...E.D
0050 - 00 41 00 05 00 04 00 15-00 12 00 09 00 14 00 11   .A..
0060 - 00 08 00 06 00 03 02 01-00 00 04 00 23#
006f - SPACES/NULS
read from 0x67f3c0 [0x6849a0] (5 bytes = 5 (0x5))
 - 15 03 00 00 02.
read from 0x67f3c0 [0x6849a5] (2 bytes = 2 (0x2))
 - 02 28 .(
5468:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake 
failure:s3_pkt.c:1053:SSL alert number 40
5468:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
failure:s3_pkt.c:530:

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

[openssl.org #1623] Bug report: default CA certs file path ignored

[Tomas Mraz via RT]

The default CA certs file path is ignored in commands like s_client
because if you don't specify -CApath or -CAfile on s_client command line
the SSL_CTX_load_verify_locations() will return 0 and the code:

if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
(!SSL_CTX_set_default_verify_paths(ctx)))
will skip the SSL_CTX_set_default_verify_paths() call.

There are two possible ways how to fix this problem - either do not call 
SSL_CTX_load_verify_locations() when CAfile and CApath are both NULL. Or
fix the code of X509_STORE_load_locations() to not to return 0 when both
path and file are NULL. 

The X509_STORE_load_locations() implementation is debatable in more ways
because it will return with 0 immediately when the file lookup load
fails and so it will not attempt to add the dir lookup at all in this
case. In my opinion it should at least try both (of course returning
failure if any load fails).

See also https://bugzilla.redhat.com/show_bug.cgi?id=421011

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

Re: [openssl.org #1623] Bug report: default CA certs file path ignored

[Tomas Mraz via RT]

On Wed, 2007-12-12 at 20:11 +0100, Tomas Mraz via RT wrote:
 The default CA certs file path is ignored in commands like s_client
...
 See also https://bugzilla.redhat.com/show_bug.cgi?id=421011

Oops, should have been
https://bugzilla.redhat.com/show_bug.cgi?id=418771
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb


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

[openssl.org #1411] Simple enhancement request - allow trusted certs in SSL_CTX_use_certificate_chain_file()

[Tomas Mraz via RT]

It should be possible to use trusted certificates when
SSL_CTX_use_certificate_chain_file() is called. Simply replacing
PEM_read_bio_X509 with PEM_read_bio_X509_AUX should work. Or is there
some reason why this should not be changed?

See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208746

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

[openssl.org #1407] Bug - add_cert_dir() logic is broken

[Tomas Mraz via RT]

The add_cert_dir() function in openssl/crypto/x509/by_dir.c is broken.
There is a loop to detect duplicate entries but its results are ignored,
it will also go out of bounds on some malformed parameters.

See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206346

Patches against 0.9.8 and CVS attached.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]