Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Unsworth]

I can’t dictate what cipher suite our customers will use, all have to work. It 
seems to me that for the time being I will have to stay with the 1.0.1 builds.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 21:09
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

This appears to be a different problem than the crash in SHA.  Since you're 
seeing a "bad record mac", it appears the TLS handshake has made it through the 
ChangeCipherSpec message.  Do you know which cipher suite is being negotiated?  
If it's AES, it may be worth trying a 3DES cipher suite.  If the issue is in 
the AES layer, one of the 3DES cipher suites should work.

By the way, have you run a 'make test' after building OpenSSL?  Are all the 
test suites passing?  If not, which one is failing?


On 04/15/2015 12:26 PM, John Unsworth wrote:
Still exactly the same crash. And even if these assembly code problems can be 
fixed there is still the negotiation error after compiling with no-asm.

4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record 
mac:s3_pkt.c:1456:SSL alert number 20
4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake 
failure:s23_lib.c:177:

John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 16:45
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

Looks like the crash is in SHA-512 this time, not SHA-1.  There's a separate 
perl script to generate that assembly code.  Try the 1.0.1 version of 
sha512-sparcv9.pl.

The output from your rand command is valid.  You can use the -base64 option if 
you want something more readable.



On 04/15/2015 11:13 AM, John Unsworth wrote:
That seems to have fixed the crash.

-bash-3.00$ ./openssl rand 64
zÔòMÉÜOvá¯@ét†Å­EÙ^±Q!þ\‰b_¨ëYŸÁµiT-&n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$

Not sure about the output though.

However negotiation causes a core:

-bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
CONNECTED(0004)
depth=0 CN = jusworth-lt4.eu.cp.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = jusworth-lt4.eu.cp.net
verify error:num=21:unable to verify the first certificate
verify return:1
Segmentation Fault (core dumped)
-bash-3.00$ pstack core
core 'core' of 12587:   ./openssl s_client -connect eos.es.cpth.ie:4250
000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050, 
64f98fa7) + 8
0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, 2f8ea0) + 1cc
000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, a42e0, 
2f8ae0) + 90
00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ) + 6c0
000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648
000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588
000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c
0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374
0001328c do_cmd   (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8
00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3d78) + 108

Regards,
John

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 15:10
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

How about the ./openssl sha1 command?  Does that bomb too?

It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the 1.0.1 
source into the 1.0.2 source.  Then clean, configure, compile and try again.  
There were changes to this file between 1.0.1 and 1.0.2.  Perhaps a bug was 
introduced.  I'm assuming this script generates the SHA source for your target 
platform.




On 04/15/2015 09:56 AM, John Unsworth wrote:
core 'core' of 24243:   ./openssl rand 64
000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8
00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c
00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138
00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88
00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8
0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8
00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108

Regards,
John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 13:31
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

Do you see the same stack trace when simply using the random number generator:

./open

[openssl-users] af_alg engine: digests work but ciphers do not?

[Barbe, Charles]

I'm wondering if anybody has any experience with the af_alg engine located here:

http://src.carnivore.it/users/common/af_alg/about/

I am able to compile the engine and can run commands such as:

 openssl speed md5 -engine af_alg

and I see that openssl has loaded the engine as indicated by this line in the 
output:

 engine "af_alg" set

and can enable dmesg logging on the linux driver for my particular hardware and 
see that the driver is being used as expected.

However, if I try to do a cipher instead of a digest, my driver is not used. 
For example, when I run:

openssl speed aes-256-cbc -engine af_alg

I see the engine get loaded but my dmesg logging indicates that the kernel 
driver was not used. And i get the same results for any of my supported ciphers.

I have followed all the instructions in the URL located above including 
modifying my openssl.conf to include the proper configuration of the supported 
ciphers for my hardware but to no avail. Here is what the top of my 
openssl.conf looks like:

#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME= .
RANDFILE= $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info:
#oid_file   = $ENV::HOME/.oid
oid_section = new_oids

openssl_conf = openssl_def

[openssl_def]
engines = openssl_engines

[openssl_engines]
af_alg = af_alg_engine

[af_alg_engine]
default_algorithms = ALL
CIPHERS=aes-128-cbc aes-192-cbc aes-256-cbc des-cbc des-ede3-cbc
DIGESTS=md4 md5 sha1 sha224 sha256 sha512

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions=
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.

For reference, I am running the following:

linux kernel v 3.19
openssl v 1.0.1m
running on a TI am3352

Any help on why digests seem to be working with the af_alg engine but ciphers 
do not would be much appreciated.


Charles A. Barbe
Senior Software Engineer
Allworx, a Windstream company
245 East Main St | Rochester NY | 14604
charles.ba...@allworx.com | 585.421.5565

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

This appears to be a different problem than the crash in SHA.  Since
you're seeing a "bad record mac", it appears the TLS handshake has made
it through the ChangeCipherSpec message.  Do you know which cipher suite
is being negotiated?  If it's AES, it may be worth trying a 3DES cipher
suite.  If the issue is in the AES layer, one of the 3DES cipher suites
should work.

By the way, have you run a 'make test' after building OpenSSL?  Are all
the test suites passing?  If not, which one is failing?



On 04/15/2015 12:26 PM, John Unsworth wrote:
>
> Still exactly the same crash. And even if these assembly code problems
> can be fixed there is still the negotiation error after compiling with
> no-asm.
>
>  
>
> 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad
> record mac:s3_pkt.c:1456:SSL alert number 20
>
> 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake
> failure:s23_lib.c:177:
>
>  
>
> John.
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *John Foley
> *Sent:* 15 April 2015 16:45
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
> broken
>
>  
>
> Looks like the crash is in SHA-512 this time, not SHA-1.  There's a
> separate perl script to generate that assembly code.  Try the 1.0.1
> version of sha512-sparcv9.pl.
>
> The output from your rand command is valid.  You can use the -base64
> option if you want something more readable.
>
>
> On 04/15/2015 11:13 AM, John Unsworth wrote:
>
> That seems to have fixed the crash.
>
>  
>
> -bash-3.00$ ./openssl rand 64
>
> zÔòMÉÜOvá¯@ét†Å�­EÙ^±Q!þ\‰b_¨ëYŸÁµiT-&n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$
>
>  
>
> Not sure about the output though.
>
>  
>
> However negotiation causes a core:
>
>  
>
> -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
>
> CONNECTED(0004)
>
> depth=0 CN = jusworth-lt4.eu.cp.net
>
> verify error:num=20:unable to get local issuer certificate
>
> verify return:1
>
> depth=0 CN = jusworth-lt4.eu.cp.net
>
> verify error:num=21:unable to verify the first certificate
>
> verify return:1
>
> Segmentation Fault (core dumped)
>
> -bash-3.00$ pstack core
>
> core 'core' of 12587:   ./openssl s_client -connect
> eos.es.cpth.ie:4250
>
> 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588,
> 30c050, 64f98fa7) + 8
>
> 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100,
> 2f8ea0) + 1cc
>
> 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10,
> a42e0, 2f8ae0) + 90
>
> 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ) + 6c0
>
> 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638)
> + 648
>
> 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588
>
> 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c
>
> 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374
>
> 0001328c do_cmd   (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8
>
> 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4
>
> 00012a08 _start   (0, 0, 0, 0, 0, 2b3d78) + 108
>
>  
>
> Regards,
>
> John
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
> *On Behalf Of *John Foley
> *Sent:* 15 April 2015 15:10
> *To:* openssl-users@openssl.org 
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
> is broken
>
>  
>
> How about the ./openssl sha1 command?  Does that bomb too?
>
> It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl
> from the 1.0.1 source into the 1.0.2 source.  Then clean,
> configure, compile and try again.  There were changes to this file
> between 1.0.1 and 1.0.2.  Perhaps a bug was introduced.  I'm
> assuming this script generates the SHA source for your target
> platform. 
>
>
>
> On 04/15/2015 09:56 AM, John Unsworth wrote:
>
> core 'core' of 24243:   ./openssl rand 64
>
> 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018,
> ffbfe01c, 44) + 8
>
> 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
>
> 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650,
> 2c0644) + 38c
>
> 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70,
> 13000) + 138
>
> 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88
>
> 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8
>
> 0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98)
> + b8
>
> 00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98,
> 2b4afc) + 3a4
>
> 00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108
>
>  
>
> Regards,
>
> John.
>
>  
>
> *From:*openssl-users
>  

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Carson Gaspar
> Sent: Wednesday, April 15, 2015 14:40
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken
> 
> On 4/15/15 4:59 AM, Jeffrey Walton wrote:
> 
> > Here's what one person was just saying about Sun's compiler on another
> > list. He maintains another crypto-toolkit:
> >
> >> ... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended
> >> to be a compiler so you had to use all sorts of trickery to determine
> whether
> >> there was a real compiler present or not).
> 
> Libel. Once Upon a Time, Sun shipped something called /usr/ucb/cc which
> was an abomination, but wouldn't be in any sane user's PATH. Oracle
> ships gcc (which compiles a language called gcc, which only vaguely
> resembles C, because the authors don't believe in the C standards), and
> also has the Solaris Studio compiler suite, which is an excellent C
> compiler (but doesn't know all of the bizarre dialects of gcc, e.g. 'a
> ?: b' *shudder*).
> 
> The real issue is usually inline assembly being in GNU format, which is
> incompatible with all others. Oracle's /usr/ccs/bin/as doesn't always
> understand all the GNUisms.

Thanks. I had resisted posting something similar. I was particularly irked by 
the context-less, hearsay claim that the Solaris C compiler isn't a conforming 
implementation. Oh yeah? How not?

Usually when I see someone complain about a C implementation, it's because they 
haven't bothered to check ISO 9899 and find out what C actually is.

I'll also note that I've been writing C code for numerous platforms (MS-DOS, 
all the incarnations of Windows, many UNIX variants, OS/400, z/OS...) for 
decades, and the Solaris compilers have *never* given me problems. That's more 
than I can say for the compilers from Microsoft, HP, and some other vendors. Or 
for GCC, even when beaten into "OK, I'll try really hard to pretend to be C" 
mode.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Unsworth]

Bug opened.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich
Sent: 14 April 2015 17:41
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

You could mail it to RT and then it will at least be logged and not forgotten.

But no response within four days isn't surprising.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[Carson Gaspar]

On 4/15/15 4:59 AM, Jeffrey Walton wrote:


Can you try with a different compiler? Is Clang available to you? (If
not, I can provide you with a script or recipe to build it).

Here's what one person was just saying about Sun's compiler on another
list. He maintains another crypto-toolkit:


... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended
to be a compiler so you had to use all sorts of trickery to determine whether
there was a real compiler present or not).


Libel. Once Upon a Time, Sun shipped something called /usr/ucb/cc which 
was an abomination, but wouldn't be in any sane user's PATH. Oracle 
ships gcc (which compiles a language called gcc, which only vaguely 
resembles C, because the authors don't believe in the C standards), and 
also has the Solaris Studio compiler suite, which is an excellent C 
compiler (but doesn't know all of the bizarre dialects of gcc, e.g. 'a 
?: b' *shudder*).


The real issue is usually inline assembly being in GNU format, which is 
incompatible with all others. Oracle's /usr/ccs/bin/as doesn't always 
understand all the GNUisms.


But none of this is relevant to the OP's issue.

--
Carson


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

[openssl-users] [openssl.org #3804] AutoReply: BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken

[The default queue via RT]

Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken", 
a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [openssl.org #3804].

Please include the string:

 [openssl.org #3804]

in the subject line of all future correspondence about this issue. To do so, 
you may reply to this message.

Thank you,
r...@openssl.org

-
I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 
32 bit. I want to upgrade but neither 1.0.2 nor 1.0.2a work.

Solaris 10
Solaris Studio 12.4

Make test log attached.

1 When building 1.0.2 using

./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden

openssl s_client crashes on start:

-bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
Segmentation Fault (core dumped)
-bash-3.00$ pstack core
core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250
000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8
00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530
00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c
00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138
00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88
0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94
0001328c do_cmd   (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8
00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3e78) + 108

2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation 
fails with an error:

4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record 
mac:s3_pkt.c:1456:SSL alert number 20
4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake 
failure:s23_lib.c:177:

This is against the server that is still running 1.0.1h and can be successfully 
connected with openssl s_client built with 1.0.1h.

The 64 bit build seems to work perfectly. The 32 bit builds that we use on 
Windows and Linux also work perfectly.

1.0.2a build fails in the same way. gcc build fails in the same way.

I have built 1.0.1m with asm and that works fine.

Regards,
John.

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

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Unsworth]

Still exactly the same crash. And even if these assembly code problems can be 
fixed there is still the negotiation error after compiling with no-asm.

4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record 
mac:s3_pkt.c:1456:SSL alert number 20
4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake 
failure:s23_lib.c:177:

John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 16:45
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

Looks like the crash is in SHA-512 this time, not SHA-1.  There's a separate 
perl script to generate that assembly code.  Try the 1.0.1 version of 
sha512-sparcv9.pl.

The output from your rand command is valid.  You can use the -base64 option if 
you want something more readable.


On 04/15/2015 11:13 AM, John Unsworth wrote:
That seems to have fixed the crash.

-bash-3.00$ ./openssl rand 64
zÔòMÉÜOvá¯@ét†Å­EÙ^±Q!þ\‰b_¨ëYŸÁµiT-&n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$

Not sure about the output though.

However negotiation causes a core:

-bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
CONNECTED(0004)
depth=0 CN = jusworth-lt4.eu.cp.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = jusworth-lt4.eu.cp.net
verify error:num=21:unable to verify the first certificate
verify return:1
Segmentation Fault (core dumped)
-bash-3.00$ pstack core
core 'core' of 12587:   ./openssl s_client -connect eos.es.cpth.ie:4250
000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050, 
64f98fa7) + 8
0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, 2f8ea0) + 1cc
000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, a42e0, 
2f8ae0) + 90
00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ) + 6c0
000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648
000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588
000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c
0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374
0001328c do_cmd   (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8
00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3d78) + 108

Regards,
John

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 15:10
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

How about the ./openssl sha1 command?  Does that bomb too?

It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the 1.0.1 
source into the 1.0.2 source.  Then clean, configure, compile and try again.  
There were changes to this file between 1.0.1 and 1.0.2.  Perhaps a bug was 
introduced.  I'm assuming this script generates the SHA source for your target 
platform.



On 04/15/2015 09:56 AM, John Unsworth wrote:
core 'core' of 24243:   ./openssl rand 64
000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8
00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c
00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138
00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88
00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8
0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8
00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108

Regards,
John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 13:31
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

Do you see the same stack trace when simply using the random number generator:

./openssl rand 64

What if you simply use SHA1:

./openssl sha1 




On 04/14/2015 12:17 PM, John Unsworth wrote:
Is no-one interested at all about this problem? Or do I need to send it to 
another place?

Regards,
John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Unsworth
Sent: 10 April 2015 14:54
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

I have compiled 1.0.1m in the same way and that works fine using asm.

John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Unsworth
Sent: 10 April 2015 12:21
To: openssl-users@openssl.org
Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 
32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems.

1 When building 1

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

Looks like the crash is in SHA-512 this time, not SHA-1.  There's a
separate perl script to generate that assembly code.  Try the 1.0.1
version of sha512-sparcv9.pl.

The output from your rand command is valid.  You can use the -base64
option if you want something more readable.



On 04/15/2015 11:13 AM, John Unsworth wrote:
>
> That seems to have fixed the crash.
>
>  
>
> -bash-3.00$ ./openssl rand 64
>
> zÔòMÉÜOvá¯@ét†Å�­EÙ^±Q!þ\‰b_¨ëYŸÁµiT-&n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$
>
>  
>
> Not sure about the output though.
>
>  
>
> However negotiation causes a core:
>
>  
>
> -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
>
> CONNECTED(0004)
>
> depth=0 CN = jusworth-lt4.eu.cp.net
>
> verify error:num=20:unable to get local issuer certificate
>
> verify return:1
>
> depth=0 CN = jusworth-lt4.eu.cp.net
>
> verify error:num=21:unable to verify the first certificate
>
> verify return:1
>
> Segmentation Fault (core dumped)
>
> -bash-3.00$ pstack core
>
> core 'core' of 12587:   ./openssl s_client -connect eos.es.cpth.ie:4250
>
> 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050,
> 64f98fa7) + 8
>
> 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100,
> 2f8ea0) + 1cc
>
> 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10,
> a42e0, 2f8ae0) + 90
>
> 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ) + 6c0
>
> 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648
>
> 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588
>
> 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c
>
> 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374
>
> 0001328c do_cmd   (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8
>
> 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4
>
> 00012a08 _start   (0, 0, 0, 0, 0, 2b3d78) + 108
>
>  
>
> Regards,
>
> John
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *John Foley
> *Sent:* 15 April 2015 15:10
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
> broken
>
>  
>
> How about the ./openssl sha1 command?  Does that bomb too?
>
> It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from
> the 1.0.1 source into the 1.0.2 source.  Then clean, configure,
> compile and try again.  There were changes to this file between 1.0.1
> and 1.0.2.  Perhaps a bug was introduced.  I'm assuming this script
> generates the SHA source for your target platform. 
>
>
> On 04/15/2015 09:56 AM, John Unsworth wrote:
>
> core 'core' of 24243:   ./openssl rand 64
>
> 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018,
> ffbfe01c, 44) + 8
>
> 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
>
> 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650,
> 2c0644) + 38c
>
> 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70,
> 13000) + 138
>
> 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88
>
> 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8
>
> 0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8
>
> 00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4
>
> 00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108
>
>  
>
> Regards,
>
> John.
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
> *On Behalf Of *John Foley
> *Sent:* 15 April 2015 13:31
> *To:* openssl-users@openssl.org 
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
> is broken
>
>  
>
> Do you see the same stack trace when simply using the random
> number generator:
>
> ./openssl rand 64
>
> What if you simply use SHA1:
>
> ./openssl sha1 
>
>
>
> On 04/14/2015 12:17 PM, John Unsworth wrote:
>
> Is no-one interested at all about this problem? Or do I need
> to send it to another place?
>
>  
>
> Regards,
>
> John.
>
>  
>
> *From:*openssl-users
> [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *John
> Unsworth
> *Sent:* 10 April 2015 14:54
> *To:* openssl-users@openssl.org 
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit
> build is broken
>
>  
>
> I have compiled 1.0.1m in the same way and that works fine
> using asm.
>
>  
>
> John.
>
>  
>
> *From:*openssl-users
> [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *John
> Unsworth
> *Sent:* 10 April 2015 12:21
> *To:* openssl-users@openssl.org 
> *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
> is broken
>
>  
>
> I have an application that runs 

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Unsworth]

That seems to have fixed the crash.

-bash-3.00$ ./openssl rand 64
zÔòMÉÜOvá¯@ét†Å­EÙ^±Q!þ\‰b_¨ëYŸÁµiT-&n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$

Not sure about the output though.

However negotiation causes a core:

-bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
CONNECTED(0004)
depth=0 CN = jusworth-lt4.eu.cp.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = jusworth-lt4.eu.cp.net
verify error:num=21:unable to verify the first certificate
verify return:1
Segmentation Fault (core dumped)
-bash-3.00$ pstack core
core 'core' of 12587:   ./openssl s_client -connect eos.es.cpth.ie:4250
000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050, 
64f98fa7) + 8
0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100, 2f8ea0) + 1cc
000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10, a42e0, 
2f8ae0) + 90
00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ) + 6c0
000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648
000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588
000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c
0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374
0001328c do_cmd   (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8
00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3d78) + 108

Regards,
John

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 15:10
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

How about the ./openssl sha1 command?  Does that bomb too?

It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the 1.0.1 
source into the 1.0.2 source.  Then clean, configure, compile and try again.  
There were changes to this file between 1.0.1 and 1.0.2.  Perhaps a bug was 
introduced.  I'm assuming this script generates the SHA source for your target 
platform.


On 04/15/2015 09:56 AM, John Unsworth wrote:
core 'core' of 24243:   ./openssl rand 64
000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8
00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c
00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138
00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88
00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8
0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8
00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108

Regards,
John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 13:31
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

Do you see the same stack trace when simply using the random number generator:

./openssl rand 64

What if you simply use SHA1:

./openssl sha1 



On 04/14/2015 12:17 PM, John Unsworth wrote:
Is no-one interested at all about this problem? Or do I need to send it to 
another place?

Regards,
John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Unsworth
Sent: 10 April 2015 14:54
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

I have compiled 1.0.1m in the same way and that works fine using asm.

John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Unsworth
Sent: 10 April 2015 12:21
To: openssl-users@openssl.org
Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 
32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems.

1 When building 1.0.2 using

./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden

openssl s_client crashes on start:

-bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
Segmentation Fault (core dumped)
-bash-3.00$ pstack core
core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250
000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8
00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530
00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c
00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138
00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88
0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94
0001328c do_cmd   (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8
00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3e78) + 108

2 So I then rebuilt addin

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

How about the ./openssl sha1 command?  Does that bomb too?

It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the
1.0.1 source into the 1.0.2 source.  Then clean, configure, compile and
try again.  There were changes to this file between 1.0.1 and 1.0.2. 
Perhaps a bug was introduced.  I'm assuming this script generates the
SHA source for your target platform. 



On 04/15/2015 09:56 AM, John Unsworth wrote:
>
> core 'core' of 24243:   ./openssl rand 64
>
> 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c,
> 44) + 8
>
> 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
>
> 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c
>
> 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138
>
> 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88
>
> 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8
>
> 0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8
>
> 00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4
>
> 00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108
>
>  
>
> Regards,
>
> John.
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *John Foley
> *Sent:* 15 April 2015 13:31
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
> broken
>
>  
>
> Do you see the same stack trace when simply using the random number
> generator:
>
> ./openssl rand 64
>
> What if you simply use SHA1:
>
> ./openssl sha1 
>
>
> On 04/14/2015 12:17 PM, John Unsworth wrote:
>
> Is no-one interested at all about this problem? Or do I need to
> send it to another place?
>
>  
>
> Regards,
>
> John.
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
> *On Behalf Of *John Unsworth
> *Sent:* 10 April 2015 14:54
> *To:* openssl-users@openssl.org 
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
> is broken
>
>  
>
> I have compiled 1.0.1m in the same way and that works fine using asm.
>
>  
>
> John.
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
> *On Behalf Of *John Unsworth
> *Sent:* 10 April 2015 12:21
> *To:* openssl-users@openssl.org 
> *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
> broken
>
>  
>
> I have an application that runs quite happily using OpenSSL 1.0.1h
> on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a
> cause problems.
>
>  
>
> 1 When building 1.0.2 using
>
>  
>
> ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32
> -xldscope=hidden
>
>  
>
> openssl s_client crashes on start:
>
>  
>
> -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
>
> Segmentation Fault (core dumped)
>
> -bash-3.00$ pstack core
>
> core 'core' of 468: ./openssl s_client -connect
> eos.es.cpth.ie:4250
>
> 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0,
> ffbfebc4, 44) + 8
>
> 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530
>
> 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630,
> 2c0624) + 38c
>
> 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50,
> 13000) + 138
>
> 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88
>
> 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94
>
> 0001328c do_cmd   (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8
>
> 00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4
>
> 00012a08 _start   (0, 0, 0, 0, 0, 2b3e78) + 108
>
>  
>
> 2 So I then rebuilt adding no-asm flag. It manages to connect but
> negotiation fails with an error:
>
>  
>
> 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert
> bad record mac:s3_pkt.c:1456:SSL alert number 20
>
> 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake
> failure:s23_lib.c:177:
>
>  
>
> This is against the server that is still running 1.0.1h and can be
> successfully connected with openssl built with 1.0.1h.
>
>  
>
> Note that the 64 bit build seems to work perfectly. Unfortunately
> for historical reasons we need to use the 32 bit version.
>
>  
>
> The 32 bit builds that we use on Windows and Linux also work
> perfectly. Is it something to do with byte order?
>
>  
>
> Regards,
>
> John.
>
>  
>
>  
>
>
>
>
> ___
>
> openssl-users mailing list
>
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>  
>
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Unsworth]

core 'core' of 24243:   ./openssl rand 64
000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c, 44) + 8
00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530
00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c
00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138
00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88
00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8
0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8
00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108

Regards,
John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Foley
Sent: 15 April 2015 13:31
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

Do you see the same stack trace when simply using the random number generator:

./openssl rand 64

What if you simply use SHA1:

./openssl sha1 


On 04/14/2015 12:17 PM, John Unsworth wrote:
Is no-one interested at all about this problem? Or do I need to send it to 
another place?

Regards,
John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Unsworth
Sent: 10 April 2015 14:54
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

I have compiled 1.0.1m in the same way and that works fine using asm.

John.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
John Unsworth
Sent: 10 April 2015 12:21
To: openssl-users@openssl.org
Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 
32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems.

1 When building 1.0.2 using

./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden

openssl s_client crashes on start:

-bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
Segmentation Fault (core dumped)
-bash-3.00$ pstack core
core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250
000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8
00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530
00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c
00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138
00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88
0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94
0001328c do_cmd   (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8
00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4
00012a08 _start   (0, 0, 0, 0, 0, 2b3e78) + 108

2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation 
fails with an error:

4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record 
mac:s3_pkt.c:1456:SSL alert number 20
4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake 
failure:s23_lib.c:177:

This is against the server that is still running 1.0.1h and can be successfully 
connected with openssl built with 1.0.1h.

Note that the 64 bit build seems to work perfectly. Unfortunately for 
historical reasons we need to use the 32 bit version.

The 32 bit builds that we use on Windows and Linux also work perfectly. Is it 
something to do with byte order?

Regards,
John.






___

openssl-users mailing list

To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Unsworth]

Thanks for the suggestion. I rebuilt with gcc and get just the same problem.

Regards,
John.

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Jeffrey Walton
Sent: 15 April 2015 12:59
To: OpenSSL Users List
Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

On Tue, Apr 14, 2015 at 12:17 PM, John Unsworth
 wrote:
> Is no-one interested at all about this problem? Or do I need to send it to
> another place?
>

Can you try with a different compiler? Is Clang available to you? (If
not, I can provide you with a script or recipe to build it).

Here's what one person was just saying about Sun's compiler on another
list. He maintains another crypto-toolkit:

> ... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended
> to be a compiler so you had to use all sorts of trickery to determine whether
> there was a real compiler present or not).

Otherwise, Rich's suggestion sounds like it might be the best that you
can hope for.

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

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

Do you see the same stack trace when simply using the random number
generator:

./openssl rand 64

What if you simply use SHA1:

./openssl sha1 



On 04/14/2015 12:17 PM, John Unsworth wrote:
>
> Is no-one interested at all about this problem? Or do I need to send
> it to another place?
>
>  
>
> Regards,
>
> John.
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *John Unsworth
> *Sent:* 10 April 2015 14:54
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
> broken
>
>  
>
> I have compiled 1.0.1m in the same way and that works fine using asm.
>
>  
>
> John.
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *John Unsworth
> *Sent:* 10 April 2015 12:21
> *To:* openssl-users@openssl.org
> *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken
>
>  
>
> I have an application that runs quite happily using OpenSSL 1.0.1h on
> Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause
> problems.
>
>  
>
> 1 When building 1.0.2 using
>
>  
>
> ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32
> -xldscope=hidden
>
>  
>
> openssl s_client crashes on start:
>
>  
>
> -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
>
> Segmentation Fault (core dumped)
>
> -bash-3.00$ pstack core
>
> core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250
>
> 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4,
> 44) + 8
>
> 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530
>
> 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c
>
> 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138
>
> 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88
>
> 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94
>
> 0001328c do_cmd   (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8
>
> 00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4
>
> 00012a08 _start   (0, 0, 0, 0, 0, 2b3e78) + 108
>
>  
>
> 2 So I then rebuilt adding no-asm flag. It manages to connect but
> negotiation fails with an error:
>
>  
>
> 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad
> record mac:s3_pkt.c:1456:SSL alert number 20
>
> 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake
> failure:s23_lib.c:177:
>
>  
>
> This is against the server that is still running 1.0.1h and can be
> successfully connected with openssl built with 1.0.1h.
>
>  
>
> Note that the 64 bit build seems to work perfectly. Unfortunately for
> historical reasons we need to use the 32 bit version.
>
>  
>
> The 32 bit builds that we use on Windows and Linux also work
> perfectly. Is it something to do with byte order?
>
>  
>
> Regards,
>
> John.
>
>  
>
>  
>
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[Jeffrey Walton]

On Tue, Apr 14, 2015 at 12:17 PM, John Unsworth
 wrote:
> Is no-one interested at all about this problem? Or do I need to send it to
> another place?
>

Can you try with a different compiler? Is Clang available to you? (If
not, I can provide you with a script or recipe to build it).

Here's what one person was just saying about Sun's compiler on another
list. He maintains another crypto-toolkit:

> ... ghastly C compilers (or, in Sun's case, a non-C compiler that pretended
> to be a compiler so you had to use all sorts of trickery to determine whether
> there was a real compiler present or not).

Otherwise, Rich's suggestion sounds like it might be the best that you
can hope for.

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

Re: [openssl-users] FIPS mode restrictions and DES

[Jeffrey Walton]

>> One point is that if this is a delivery for someone
>> subject to the FIPS-only procurementrequirement
>> imposed on various US Government related entities,
>> then whatever OS theyuse, MUST (by that requirement)
>> have already passed this for its password handling.
>
> This is *technically* true, in the narrow sense that supposedly any OS
> used in DoD should be CC certified and so forth. Should not must.
>
> In practice it is very common -- at FIPS 140-2 Level 1 -- for software
> *products* to use FIPS 140-2 validated crypto on non-certified,
> non-validated operating systems. Just take a look at Table 2 in the
> OpenSSL FIPS Object Module Security Policy:
>
>   http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf
>
> and note that of the 101 platforms ("OEs") appearing there, most of
> those operating systems are neither CC certified nor have any other FIPS
> 140-2 validated crypto. Keep in mind that at Level 1 the validation
> applies to the cryptographic module, not the calling application that
> uses that module nor the operating system that runs it.

Another example is the various frameworks that provide the TextEdit
boxes where passwords are entered. FIPS requires zeroization at level
1, and I guarantee none of those frameworks wipe the memory from the
TextEdit.

Hell, Apple has a secure allocator that does not even bother calling
the secure deleter. It calls the default deleter for some reason. See
the source code for libsecurity_utilities at [1,2,3].

And Apple really could have used zeroization:
http://www.cnet.com/news/mac-os-x-lion-reveals-passwords-in-sleep-mode/.
As this vulnerability shows, wiping secrets from memory is not a
theoretical defense.

[1] 
http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/SecKeychainItem.cpp
[2] 
http://www.opensource.apple.com/source/libsecurity_keychain/libsecurity_keychain-40768/lib/Item.cpp
[3] 
http://www.opensource.apple.com/source/libsecurity_utilities/libsecurity_utilities-38535/lib/alloc.cpp
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users