Re: [openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-09 Thread Kris Karas

Stephen Henson via RT wrote:

Please see if commit 32cc247 fixes this:

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247


Confirmed!  Works for me.  (But, see P.S., below.)

I re-confirmed the error was repeatably reproducible.
Applied the patch, and was no longer able to reproduce the error.
Reverse-applied the patch, and the error instantly returned.

The patch does indeed do the right thing in this case.
Thank you!

Kris

P.S.  Was supposed to work from home today due to potentially worst snow 
in Boston in 35 years.  But I could not reproduce the error in this 
report on my server at home, despite many recompiles of related things 
into the wee hours.  I'm perplexed as to what the difference could be.  
Same OS, same libraries, at least for Apache and related.  Work system 
is Core-i7 and home is Athlon-II.  Did a diff between the output of 
Configure of both systems and it is identical.  (Certificates?)  I'll 
try pushing the binary package at work to home and see if that makes any 
difference.  Ergo, by virtue of the difficulty in reproducing this bug, 
it might not affect as many people as I first thought.




Re: [openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-09 Thread Kurt Roeckx
On Thu, Feb 07, 2013 at 10:22:24PM +0100, Stephen Henson via RT wrote:
 On Thu Feb 07 00:43:10 2013, steve wrote:
  On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote:
  
   I haven't had a chance (yet?) to bisect the code to find the culprit,
   but I can take a stab at it if a developer doesn't know off the top of
   their head just where it might be.
  
 
  Stop gap measure for now is to revert commit 125093b59f3c
 
 
 Please see if commit 32cc247 fixes this:
 
 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247
 
 It will also appear in the next snapshot of OpenSSL 1.0.1.
 
 If it does and there are no more reports of serious problems in 1.0.1d we'll
 roll another release.

I don't see any report of issues, anymore.  When will you make a
new release?


Kurt

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


Re: [openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-08 Thread Kris Karas via RT
Stephen Henson via RT wrote:
 Please see if commit 32cc247 fixes this:

 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247

Confirmed!  Works for me.  (But, see P.S., below.)

I re-confirmed the error was repeatably reproducible.
Applied the patch, and was no longer able to reproduce the error.
Reverse-applied the patch, and the error instantly returned.

The patch does indeed do the right thing in this case.
Thank you!

Kris

P.S.  Was supposed to work from home today due to potentially worst snow 
in Boston in 35 years.  But I could not reproduce the error in this 
report on my server at home, despite many recompiles of related things 
into the wee hours.  I'm perplexed as to what the difference could be.  
Same OS, same libraries, at least for Apache and related.  Work system 
is Core-i7 and home is Athlon-II.  Did a diff between the output of 
Configure of both systems and it is identical.  (Certificates?)  I'll 
try pushing the binary package at work to home and see if that makes any 
difference.  Ergo, by virtue of the difficulty in reproducing this bug, 
it might not affect as many people as I first thought.


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


Re: [openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-08 Thread Dr. Stephen Henson
On Fri, Feb 08, 2013, Kris Karas via RT wrote:

 Stephen Henson via RT wrote:
  Please see if commit 32cc247 fixes this:
 
  http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247
 
 Confirmed!  Works for me.  (But, see P.S., below.)
 
 I re-confirmed the error was repeatably reproducible.
 Applied the patch, and was no longer able to reproduce the error.
 Reverse-applied the patch, and the error instantly returned.
 
 The patch does indeed do the right thing in this case.
 Thank you!
 
 Kris
 
 P.S.  Was supposed to work from home today due to potentially worst snow 
 in Boston in 35 years.  But I could not reproduce the error in this 
 report on my server at home, despite many recompiles of related things 
 into the wee hours.  I'm perplexed as to what the difference could be.  
 Same OS, same libraries, at least for Apache and related.  Work system 
 is Core-i7 and home is Athlon-II.  Did a diff between the output of 
 Configure of both systems and it is identical.  (Certificates?)  I'll 
 try pushing the binary package at work to home and see if that makes any 
 difference.  Ergo, by virtue of the difficulty in reproducing this bug, 
 it might not affect as many people as I first thought.
 

There are two separate cases.

One requires AES-NI (e.g. i7) which will get invalid data for any record,
but the connection will appear OK.

The second affects any platform when short records are transferred: e.g.
sending a single character with s_client/s_server. If that happens the
connection terminates with a fatal alert. If you transfer larger records (e.g.
web server) you'd only see that problem occasionally.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-07 Thread Stephen Henson via RT
On Thu Feb 07 00:43:10 2013, steve wrote:
 On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote:
 
  I haven't had a chance (yet?) to bisect the code to find the culprit,
  but I can take a stab at it if a developer doesn't know off the top of
  their head just where it might be.
 

 Stop gap measure for now is to revert commit 125093b59f3c


Please see if commit 32cc247 fixes this:

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247

It will also appear in the next snapshot of OpenSSL 1.0.1.

If it does and there are no more reports of serious problems in 1.0.1d we'll
roll another release.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

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


Re: [openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-07 Thread Brad House

On 02/07/2013 04:22 PM, Stephen Henson via RT wrote:

On Thu Feb 07 00:43:10 2013, steve wrote:

On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote:


I haven't had a chance (yet?) to bisect the code to find the culprit,
but I can take a stab at it if a developer doesn't know off the top of
their head just where it might be.



Stop gap measure for now is to revert commit 125093b59f3c



Please see if commit 32cc247 fixes this:

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247

It will also appear in the next snapshot of OpenSSL 1.0.1.

If it does and there are no more reports of serious problems in 1.0.1d we'll
roll another release.

Steve.


I can confirm, at least from initial testing, the issue is resolved.

Thanks for the quick turn around guys!

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


[openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-06 Thread Kris Karas via RT
A serious regression was introduced in 1.0.1d that corrupts the data 
stream under certain circumstances.

Firefox requests to an Apache server running on Linux/X86_64 with 
OpenSSL-1.0.1d result in 501 Server Error responses.  OpenSSL versions 
1.0.1c and earlier are not affected.  i686 (32 bit) versions are also 
not affected.

An excerpt from the Apache log with 1.0.1c, showing correct behavior:

10.1.2.3 - - [05/Feb/2013:23:06:59 -0500] GET / HTTP/1.1 200 203 - 
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0
10.1.2.3 - - [05/Feb/2013:23:30:39 -0500] GET / HTTP/1.1 304 - - 
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0

An excerpt from the Apache log with 1.0.1d, clearly showing the invalid 
request:

10.1.2.3 - - [05/Feb/2013:22:47:02 -0500] G\xedET / HTTP/1.1 501 932 
- Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0
10.1.2.3 - - [05/Feb/2013:23:04:03 -0500] GET / HTTP/1.1 501 932 - 
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0


A look at the ssl-request log from Apache is also interesting, as 
Firefox sees corruption (first log line) but Links (text-based web 
browser, second log line) does not.  This hints at it being cipher-specific:

10.1.2.3 TLSv1 ECDHE-RSA-AES256-SHA G\xedET / HTTP/1.1 932
10.1.2.3 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 GET / HTTP/1.1 203

I haven't had a chance (yet?) to bisect the code to find the culprit, 
but I can take a stab at it if a developer doesn't know off the top of 
their head just where it might be.

The OS here is Slackware-64.  Compiler is gcc-4.7.2, binutils 
2.23.51.0.6, glibc 2.15.
A portion of the output of configure is:

Configuring for linux-x86_64
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 
(skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-store[experimental] OPENSSL_NO_STORE (skip dir)
IsMK1MF=0
CC=gcc
CFLAG =-fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN 
-DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM
EX_LIBS   =-ldl
CPUID_OBJ =x86_64cpuid.o
BN_ASM=x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o 
modexp512-x86_64.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o 
aesni-x86_64.o aesni-sha1-x86_64.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC  =cmll-x86_64.o cmll_misc.o
MODES_OBJ =ghash-x86_64.o
ENGINES_OBJ   =
PROCESSOR =
RANLIB=/usr/bin/ranlib
ARFLAGS   =
PERL  =/usr/bin/perl
SIXTY_FOUR_BIT_LONG mode
DES_UNROLL used
DES_INT used
RC4_CHUNK is unsigned long


Best regards,
Kris Karas

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


[openssl.org #2975] [BUG] Regression in Openssl 1.0.1d x86_64: Corrupted data stream

2013-02-06 Thread Stephen Henson via RT
On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote:

 I haven't had a chance (yet?) to bisect the code to find the culprit,
 but I can take a stab at it if a developer doesn't know off the top of
 their head just where it might be.


Stop gap measure for now is to revert commit 125093b59f3c

We're looking into the proper fix.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

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