[openssl.org #3076] openssl 1.0.1e outdated manuals

2013-06-18 Thread Doru Georgescu via RT
openssl 1.0.1e's man 3 ecdsa is two times outdated and horribly misleading. 
Since it was written the API changed and then EC_KEY was buried into the inner 
headers of the library such that key-group (it should have been eckey-group, 
I guess) can no longer be accessed directly like in the manual example. When I 
searched openssl ecdsa on google I found stackoverflow answers only and it took 
me a long time to put together the snippets of information and understand how 
to use openssl ecdsa correctly, in spite of the manual example. Only after I 
did that I started to google for specific functions in the API and I finally 
found wiki.openssl.org, which is pretty good. Please substitute the man ecdsa 
(and other unhappy manuals) in openssl 1.0.1e with a link to wiki.openssl.org 
to make many openssl beginners happy. 

Thank you. 

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


Re: [openssl.org #3076] openssl 1.0.1e outdated manuals

2013-06-18 Thread Matt Caswell
On 18 June 2013 08:11, Doru Georgescu via RT r...@openssl.org wrote:
 openssl 1.0.1e's man 3 ecdsa is two times outdated and horribly misleading. 
 Since it was written the API changed and then EC_KEY was buried into the 
 inner headers of the library such that key-group (it should have been 
 eckey-group, I guess) can no longer be accessed directly like in the manual 
 example. When I searched openssl ecdsa on google I found stackoverflow 
 answers only and it took me a long time to put together the snippets of 
 information and understand how to use openssl ecdsa correctly, in spite of 
 the manual example. Only after I did that I started to google for specific 
 functions in the API and I finally found wiki.openssl.org, which is pretty 
 good. Please substitute the man ecdsa (and other unhappy manuals) in openssl 
 1.0.1e with a link to wiki.openssl.org to make many openssl beginners happy.


Hi Doru

I recently wrote and had accepted some manual pages on the usage of
EC_KEY (only in the git master at the moment). See:

http://wiki.openssl.org/index.php/Manual:EC_KEY_new(3)

With regards to other manual pages it is now possible to make updates
and fixes directly on the wiki (as long as you are comfortable with
POD syntax). Periodically I will be submitting as a patch to the
project containing any updates made on the wiki. Alternatively you can
use the Talk page associated with each man page to raise any
specific concerns.


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


Re: [openssl.org #3074] On PA-RISC, OPENSSL_cleanse() causes crash when called from outside libcrypto, patch included

2013-06-18 Thread Andy Polyakov via RT
Hi, and thanks for report!

 I got a strange bug report claiming that openssl md5 was dumping core on
 old parisc hardware.  Sure enough, it was generating the correct result
 but then crashing:
 
   $ openssl md5 /dev/null
   MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e
   Segmentation fault (core dumped)

It's perplexing that it went unnoticed for this long. Is it possible
that problem was compensated for in specific linker patch-level or
something? I mean linker can generate trampoline code that does the
right thing or simply replace the instruction under specific
circumstances...

 The debugger wasn't much help, but through trial and error I narrowed it
 down to the single call to OPENSSL_cleanse() in apps/dgst.c.  I then spent
 a few frustrating hours learning the minutia of how parisc assembly works.
 
 It turns out the problem is rather subtle.  The implementation of
 crypto/pariscid.pl returns to its caller with this instruction:
 
 bv  ($rp)
 
 That would work if it were a function statically linked into bin/openssl.
 However, when returning to a function in a different segment you must use
 the bve instruction (Branch Vectored _External_) or it will crash as
 as the branch completes.  By the way, bve($rp) is known simply as ret
 when disassembling.

Replacing all bv's with bve's would break 32-bit builds, because bve is
2.0 instruction. Could you verify
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=02450ec69dda7815ba1e7bd74eb30f0ae1eb3042
that replaces bv only when build targets 64-bit mode? Once it's
verified, it goes down to 1.0.x.


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


Re: [openssl.org #3076] openssl 1.0.1e outdated manuals

2013-06-18 Thread Matt Caswell
On 18 June 2013 09:42, Matt Caswell fr...@baggins.org wrote:
 With regards to other manual pages it is now possible to make updates
 and fixes directly on the wiki (as long as you are comfortable with
 POD syntax). Periodically I will be submitting as a patch to the
 project containing any updates made on the wiki. Alternatively you can
 use the Talk page associated with each man page to raise any
 specific concerns.

I should have mentioned that I wrote some guidelines on submitting man
page updates through the wiki here:
http://wiki.openssl.org/index.php/Guidelines_for_Manual_Page_Authors

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


Re: MONTMUL performance: t4 engine vs inlined t4

2013-06-18 Thread Andy Polyakov
Misaki,

 The measurement I sent yesterday for OpenSSL (with inlined T4
 instruction support) was not quite accurate.
 Some of the T4 specific code you committed was not enabled when we
 tested, and I realized that __sparc__ was not defined on our system.
 Thus, I changed #if defined(__sparc__) to #if defined(__sparc).
 Now, we are seeing better number with OpenSSL.

   signverifysign/s verify/s
 rsa 1024 bits 0.000351s 0.24s   2852.9  42311.0
 rsa 2048 bits 0.001258s 0.47s795.1  21128.6
 rsa 4096 bits 0.006240s 0.000395s160.3   2533.3
 
 Which is virtually identical to Linux results. So one mystery solved.
 I'll commit the fix at some later point.
 
 which is still slower than our t4 engine for 1k and 2k bit RSA sign:
   signverifysign/s verify/s
 rsa 1024 bits 0.000237s 0.28s   4221.9  36119.8
 rsa 2048 bits 0.000876s 0.75s   1141.7  13285.6
 rsa 4096 bits 0.006341s 0.002139s157.7467.5
 
 As mentioned the problem seems to be multi-layer and we are moving in
 right direction.

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4ddacd9921f48013b5cd011e4b93b294c14db1c2
improves RSA sign performance by 20-30%:

rsa 1024 bits 0.000256s 0.16s   3904.4  61411.9
rsa 2048 bits 0.000946s 0.29s   1056.8  34292.7
rsa 4096 bits 0.005061s 0.000340s197.6   2940.5

This is still slower than your code, but conclusion we have to draw is
that it's intentional. In sense that the discrepancy is accounted to the
fact that OpenSSL implements counter-measures against cache-timing
attack, and takes rather conservative approach. It remains to be seen if
platform-specific and faster counter-measure will be suggested at later
point. Meanwhile, please double-check on Solaris.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10

2013-06-18 Thread Andy Polyakov via RT
 For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker
 script and no longer a symlink. This breaks the config check on i386 for
 what binary format to use when building with ASM support. The current
 config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X
 file to run file(1) against. For FreeBSD the real libc.so is in
 /lib/libc.so.X.
 
 Because the proper libc.so is not found, a.out format is chosen when
 using ASM and the build fails.
 
 With patch:
 Operating system: i386-pc-freebsd8.3
 Configuring for BSD-x86-elf
 [...]
 Build passes.
 
 
 I have 2 proposed patches which solve the problem. Only 1 is needed.
 
 1. Use file(1) against /bin/sh for all BSD platforms. I believe this
 will be more portable long-term. It will determine the binary type,
 regardless of where libc.so is or how it is setup. Note that -L is used
 to follow symlink incase someone symlinks /bin/sh to something else.
 
   http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-bin-sh.diff
 
 2. Or just include /lib/libc.so.* in the search path to run file(1)
 against. I prefer #1 as it is possible that /usr/lib/libc.so is
 symlinked to a libc.ld script, which cause file(1) to return 'ASCII' and
 the config falls back on a.out.
 
   http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-lib-libc.diff

We have to remember that those lines serve several BSD flavours and
preferred choice should be least invasive, i.e. #2. But before we
proceed could you answer couple of questions? Is it possible to run
32-bit x86 binaries on x86_64 FreeBSD system? Compile 32-bit program?
How multi-lib is handled, i.e. where are 32- and 64-bit shared libraries
reside? Well, this is unlikely to affect the decision, I'm simply using
the opportunity to learn something that can affect future decisions. Thanks.



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


Re: [openssl.org #3072] Strange behaviour when talking to microsoft exchange

2013-06-18 Thread Kurt Roeckx via RT
On Tue, Jun 18, 2013 at 12:30:58AM -0400, Dave Thompson wrote:
 
 Looking at your state_debug.log (which tries 1.2) I see:
 read/write preliminary SMTP as normal
 write ClientHello: offer 1.2
 read ServerHello: agree 1.0 DES-CBC3-SHA
 rest of handshake normal
 
 Aside: I notice your build (here and in no-1.2) doesn't offer IDEA,
 so I'll guess it was built by longtime anti-patent person.

This is tested on Debian where it was disabled many years ago and
never re-enabled.  I see no reason to enable it anymore.

 Then we have:
  250 OK
  214-This server supports the following commands:
  214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT
 VRFY
 These appear to be leftover (in mbuf) from the preliminary phase.

No, this is most likely a logging problem.  
What happens is that I get:
250 OK

I send: HELP\r\n

I get as reply:
214-This server supports the following commands:
214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT VRFY

And after that the connection breaks.

 I suggest trying the default=1.2 with -cipher RC4-MD5; if that works 
 try RC4-SHA with default=1.2 and also -no_tls1_2 and/or exact -tls1.
 Conversely try -no_tls1_2 and/or -tls1 with -cipher DES-CBC-SHA .

Using -cipher RC4-MD5 or -cipher RC4-SHA I get that as cipher
and have connection that stays working.

Using -no_tls1_2 -cipher DES-CBC-SHA I get the broken connection
after the HELP.

My conclussions:
- One of the 2 sides doesn't implement DES-CBC-SHA/DES-CBC3-SHA properly
- The server seems to act weird in changing between RC4-MD5 and
  DES-CBC3-SHA.


Kurt


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


Regarding SSL cert generation

2013-06-18 Thread Ajith Mamachan
Hi

When I generated the cert thru openssl, It not starting with BEGIN
CERTIFICATE,
rather with

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4 (0x4)
Signature Algorithm: sha1WithRSAEncryption

This  creates problem in importing the cert to my server.
Anyone knows , whether the format is different or not?Anyone please explain

Thanks,
Ajith


Re: Apple are, apparently, dicks...

2013-06-18 Thread Rob Stradling

On 14/06/13 14:16, Ben Laurie wrote:

On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote:

snip

Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral
component of OSX.


https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html
seems to suggest it is a library.


Ben, what else needs to happen before this patch is either committed or 
rejected?


Thanks.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


parallel make broken

2013-06-18 Thread Richard Weinberger

Hi!

While building openssl-1.0.1e I noticed that the parallel build
is broken.
If I try to build openssl with make -j N where N is  1 the build fails
due to unresolved symbols.

E.g:
make[2]: Entering directory 
`/home/rw/work/vpnbox/v2/maker/_build/openssl/openssl-1.0.1e/apps'
make[2]: Warnung: Kein Jobserver verfügbar: -j1 wird gesetzt. »+« zur 
Ursprungsregel
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -O3 
-fomit-frame-pointer -Wall   -c -o rand_win.o rand_win.c

req.o: In function `genpkey_cb':
req.c:(.text+0x1e): undefined reference to `EVP_PKEY_CTX_get_app_data'
req.c:(.text+0x30): undefined reference to `EVP_PKEY_CTX_get_keygen_info'
req.c:(.text+0x51): undefined reference to `BIO_write'
req.c:(.text+0x71): undefined reference to `BIO_ctrl'
req.o: In function `do_X509_sign':
req.c:(.text+0xd0): undefined reference to `EVP_MD_CTX_init'
req.c:(.text+0xe4): undefined reference to `EVP_MD_CTX_init'
req.c:(.text+0x110): undefined reference to `EVP_DigestSignInit'
req.c:(.text+0x128): undefined reference to `sk_value'

make -j 1 on the other hand build perfectly fine.
I found this patch on the net:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/files/openssl-1.0.1-parallel-build.patch
With it applied openssl builds fine in parallel.

Is this a known issue?
I'm wondering why this patch is not mainline...

Thanks,
//richard

P.s: Please CC me, I'm not subscribed.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


RE: [openssl.org #3072] Strange behaviour when talking to microsoft exchange

2013-06-18 Thread Dave Thompson
 From: owner-openssl-...@openssl.org On Behalf Of Kurt Roeckx via RT
 Sent: Tuesday, 18 June, 2013 12:30

 On Tue, Jun 18, 2013 at 12:30:58AM -0400, Dave Thompson wrote:
  
  Looking at your state_debug.log (which tries 1.2) I see:
  read/write preliminary SMTP as normal
  write ClientHello: offer 1.2
  read ServerHello: agree 1.0 DES-CBC3-SHA
  rest of handshake normal
  
  Aside: I notice your build (here and in no-1.2) doesn't offer IDEA,
  so I'll guess it was built by longtime anti-patent person.
 
 This is tested on Debian where it was disabled many years ago and
 never re-enabled.  I see no reason to enable it anymore.
 
Okay. A little unusual, but okay.

  Then we have:
   250 OK
   214-This server supports the following commands:
   214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH 
 TURN ETRN BDAT
  VRFY
  These appear to be leftover (in mbuf) from the preliminary phase.
 
 No, this is most likely a logging problem.  
 What happens is that I get:
 250 OK
 
 I send: HELP\r\n
 
 I get as reply:
 214-This server supports the following commands:
 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH 
 TURN ETRN BDAT VRFY
 
But this appeared before the -debug display of the outgoing 
(1+1) messages or any incoming messages? I agree that looks 
like a logging problem, which worries me because then I can't 
be entirely certain of the other stuff in the log.

 And after that the connection breaks.
 
  I suggest trying the default=1.2 with -cipher RC4-MD5; if 
 that works 
  try RC4-SHA with default=1.2 and also -no_tls1_2 and/or exact -tls1.
  Conversely try -no_tls1_2 and/or -tls1 with -cipher DES-CBC-SHA .
 
Oops! I meant DES-CBC3-SHA; never use any single-DES mode.
(Openssl probably should have named them 3DES-CBC or even 
3DES-EDE-CBC like other folks did, it makes more sense to have the 
encryption primitive all in one place. Oh well, too late now.)
 
 Using -cipher RC4-MD5 or -cipher RC4-SHA I get that as cipher
 and have connection that stays working.
 
 Using -no_tls1_2 -cipher DES-CBC-SHA I get the broken connection
 after the HELP.
 
So if RC4 works regardless after any handshake and DES-CBC3 fails ditto ...
 
 My conclussions:
 - One of the 2 sides doesn't implement 
 DES-CBC-SHA/DES-CBC3-SHA properly

... I think you're right and I suspect the other side because 
openssl interoperates with lots of folks -- unless there's 
something badly off in your build of openssl. Can you 
connect with DES-CBC3-SHA to usual suspects like google?
I think commandline nowadays picks up engines from openssl.cnf 
even if you don't explicitly ask -- do you have any configured?
If you didn't build from source, can you try that?

 - The server seems to act weird in changing between RC4-MD5 and
   DES-CBC3-SHA.
 
That is kinda weird, though not in itself improper. It it 
(correctly!) implements both, and the client offers both 
(and openssl s_client by default offers nearly everything) 
it is allowed to choose between them.


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


Re: parallel make broken

2013-06-18 Thread Mike Frysinger
On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote:
 While building openssl-1.0.1e I noticed that the parallel build
 is broken.

yes, it's pretty much always been broken

 I found this patch on the net:
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/fi
 les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine
 in parallel.

heh, you've found me!  the referenced ticket says it's been merged, but it 
doesn't seem that way (at least for the latest branch).  the feedback loop 
w/the rt tracker has been kind of bad, so i lose incentive to fix keep posting 
patches.

the other thing you should do is to run:
make -j1 depend
make -jN
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [openssl.org #3072] Strange behaviour when talking to microsoft exchange

2013-06-18 Thread Kurt Roeckx
On Tue, Jun 18, 2013 at 05:25:06PM -0400, Dave Thompson wrote:
  My conclussions:
  - One of the 2 sides doesn't implement 
  DES-CBC-SHA/DES-CBC3-SHA properly
 
 ... I think you're right and I suspect the other side because 
 openssl interoperates with lots of folks -- unless there's 
 something badly off in your build of openssl. Can you 
 connect with DES-CBC3-SHA to usual suspects like google?

With google I get:
Protocol  : TLSv1.2
Cipher: DES-CBC3-SHA

(Or by default)
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES128-GCM-SHA256

Both of course work as expected.

 I think commandline nowadays picks up engines from openssl.cnf 
 even if you don't explicitly ask -- do you have any configured?

There are no engines configured.

 If you didn't build from source, can you try that?

Enable engines?  Which ones?

PS: Are you unable to reproduce this?  I can reproduce this with
various sites including things like smtp.live.com.


Kurt

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


Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10

2013-06-18 Thread Bryan Drewery
On 6/18/2013 4:47 AM, Andy Polyakov via RT wrote:
 For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker
 script and no longer a symlink. This breaks the config check on i386 for
 what binary format to use when building with ASM support. The current
 config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X
 file to run file(1) against. For FreeBSD the real libc.so is in
 /lib/libc.so.X.

 Because the proper libc.so is not found, a.out format is chosen when
 using ASM and the build fails.

 With patch:
 Operating system: i386-pc-freebsd8.3
 Configuring for BSD-x86-elf
 [...]
 Build passes.


 I have 2 proposed patches which solve the problem. Only 1 is needed.

 1. Use file(1) against /bin/sh for all BSD platforms. I believe this
 will be more portable long-term. It will determine the binary type,
 regardless of where libc.so is or how it is setup. Note that -L is used
 to follow symlink incase someone symlinks /bin/sh to something else.

   http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-bin-sh.diff

 2. Or just include /lib/libc.so.* in the search path to run file(1)
 against. I prefer #1 as it is possible that /usr/lib/libc.so is
 symlinked to a libc.ld script, which cause file(1) to return 'ASCII' and
 the config falls back on a.out.

   http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-lib-libc.diff
 
 We have to remember that those lines serve several BSD flavours and
 preferred choice should be least invasive,

Right. The entire script is running through /bin/sh, so it is guaranteed
to be there. I really have no preference on which, if either, is taken.

 i.e. #2. But before we
 proceed could you answer couple of questions? Is it possible to run
 32-bit x86 binaries on x86_64 FreeBSD system? 

Yes

 Compile 32-bit program?

Yes

 How multi-lib is handled, i.e. where are 32- and 64-bit shared libraries
 reside? Well, this is unlikely to affect the decision, I'm simply using
 the opportunity to learn something that can affect future decisions. Thanks.
 

We have 32bit compat libraries in /usr/lib32 on 64bit hosts.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature


Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10

2013-06-18 Thread Bryan Drewery via RT
On 6/18/2013 4:47 AM, Andy Polyakov via RT wrote:
 For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker
 script and no longer a symlink. This breaks the config check on i386 for
 what binary format to use when building with ASM support. The current
 config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X
 file to run file(1) against. For FreeBSD the real libc.so is in
 /lib/libc.so.X.

 Because the proper libc.so is not found, a.out format is chosen when
 using ASM and the build fails.

 With patch:
 Operating system: i386-pc-freebsd8.3
 Configuring for BSD-x86-elf
 [...]
 Build passes.


 I have 2 proposed patches which solve the problem. Only 1 is needed.

 1. Use file(1) against /bin/sh for all BSD platforms. I believe this
 will be more portable long-term. It will determine the binary type,
 regardless of where libc.so is or how it is setup. Note that -L is used
 to follow symlink incase someone symlinks /bin/sh to something else.

   http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-bin-sh.diff

 2. Or just include /lib/libc.so.* in the search path to run file(1)
 against. I prefer #1 as it is possible that /usr/lib/libc.so is
 symlinked to a libc.ld script, which cause file(1) to return 'ASCII' and
 the config falls back on a.out.

   http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-lib-libc.diff
 
 We have to remember that those lines serve several BSD flavours and
 preferred choice should be least invasive,

Right. The entire script is running through /bin/sh, so it is guaranteed
to be there. I really have no preference on which, if either, is taken.

 i.e. #2. But before we
 proceed could you answer couple of questions? Is it possible to run
 32-bit x86 binaries on x86_64 FreeBSD system? 

Yes

 Compile 32-bit program?

Yes

 How multi-lib is handled, i.e. where are 32- and 64-bit shared libraries
 reside? Well, this is unlikely to affect the decision, I'm simply using
 the opportunity to learn something that can affect future decisions. Thanks.
 

We have 32bit compat libraries in /usr/lib32 on 64bit hosts.


-- 
Regards,
Bryan Drewery




signature.asc
Description: PGP signature


RE: [openssl.org #3072] Strange behaviour when talking to microsoft exchange

2013-06-18 Thread Dave Thompson
 From: owner-openssl-...@openssl.org On Behalf Of Kurt Roeckx
 Sent: Tuesday, 18 June, 2013 18:50

 On Tue, Jun 18, 2013 at 05:25:06PM -0400, Dave Thompson wrote:
   My conclussions:
   - One of the 2 sides doesn't implement 
   DES-CBC-SHA/DES-CBC3-SHA properly
  
  ... I think you're right and I suspect the other side because 
  openssl interoperates with lots of folks -- unless there's 
  something badly off in your build of openssl. Can you 
  connect with DES-CBC3-SHA to usual suspects like google?
 
 With google I get:
 Protocol  : TLSv1.2
 Cipher: DES-CBC3-SHA
 
 (Or by default)
 Protocol  : TLSv1.2
 Cipher: ECDHE-RSA-AES128-GCM-SHA256
 
 Both of course work as expected.
 
And is able to send and receive data? I forgot to ask that.
For an https server send GET / HTTP/1.0\r\n\r\n (I feed 
from a file or echo| since it's hard to type that in) and 
look for HTTP headers (followed by something HTMLish).
If so, your openssl is doing DES-CBC3 right; see below.

  I think commandline nowadays picks up engines from openssl.cnf 
  even if you don't explicitly ask -- do you have any configured?
 
 There are no engines configured.
 
(That was just in case you got the cipher implementation 
from someplace other than openssl itself.)

  If you didn't build from source, can you try that?
 
 Enable engines?  Which ones?
 
I didn't mean engines, I meant build from source, to be sure 
you're running as-distributed code for the affected cipher. 
But if you can communicate with e.g. google that's enough.

 PS: Are you unable to reproduce this?  I can reproduce this with
 various sites including things like smtp.live.com.
 
I can't reproduce any starttls smtp; I suspecvt our provider 
has done something to port 25 probably on the theory they're 
fighting spam. I get banner which is clearly masked and 
EHLO/250 response which is clearly altered, and STARTTLS 
is rejected with various 5xx. If you have a server that 
handles clear+STARTTLS on a different port I can try it.

I can do *https* 443 DES-CBC3 fine in 1.0.1e, and others.

One logical but unpleasant theory is that s_client starttls 
code clobbers something that screws up DES-CBC3 but not RC4.
That would be quite a pain to debug. It's a little work, but 
what I would try first is a simplified replacement for s_client, 
without the bells and whistles especially nonblocking, like:
  // add error checking to taste
  ctx=SSL_CTX_new()
  // set verify_locations, ciphers, etc, as desired
  ssl=SSL_new(ctx)
  ipaddr=gethostaddr(whatever)
  s=socket()
  connect(s,iapddr_and_port)
  bio=push bufferBIO on socketBIO for s // easier to manage
  BIO_gets for 220
  BIO_puts EHLO...\r\n
  BIO_gets until 250-no-hyphen looking for STARTTLS
  BIO_puts STARTTLS\r\n
  BIO_gets for 220
  SSL_set_bio(ssl,bio,bio)
  SSL_connect
  SSL_write AUTH...\r\n // or whatever
  SSL_read and look for valid lines
  // continue until done

If that works, the problem is pretty definitely s_client.
If that fails, and on more than one or a few servers, 
I don't know what to think. 


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