Re: [openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb 2013"?

[Porter, Andrew]

If that version string was printed by a Linux system-provided "openssl" command 
you'd be best off downloading the system-specific source packages. To make your 
best guess at building it manually yourself from original source:

(a) your old OpenSSL source here:

https://www.openssl.org/source/old/1.0.1/

(b) that string doesn't tell you which exact FIPS module source, the current 
version is here:

https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz

(c) The FIPS-140 User Guide here, which covers how to build first the FIPS 
module and then fips-enabled OpenSSL:

https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

Andrew

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Joe 
Flowers
Sent: Friday, June 02, 2017 14:37
To: openssl-users@openssl.org
Subject: [openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb 2013"?

Hello Everyone,

Will someone tell me where the source code is to build this version of openssl, 
please?

"OpenSSL 1.0.1e-fips 11 Feb 2013"


Thanks!

Joe
-

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

[openssl-users] Source code to build "OpenSSL 1.0.1e-fips 11 Feb 2013"?

[Joe Flowers]

Hello Everyone,

Will someone tell me where the source code is to build this version of
openssl, please?

"OpenSSL 1.0.1e-fips 11 Feb 2013"


Thanks!

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Dennis Clarke
> Sent: Friday, June 02, 2017 10:28
> 
>  Simply remove the CHANGES file from the source release.
> 
>  Since it clearly is not a "CHANGES" list nor is it useful.

It may not be useful to you. It's useful to me, and I suspect I'm not the only 
one.

Not everyone shares your preferences and prejudices.

Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] -fPIC option missing for crypto/bn/x86_64-gcc.c and some other files in 1.0.2l that exists in 1.0.1m & 1.1.0c

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Bill Smith
> Sent: Friday, June 02, 2017 08:11
> 
> Looking at the openssl build output, sure enough, it's missing -fPIC.

This is one of the reasons why we use our own Configure script for OpenSSL. 
When we update to a new OpenSSL release, we diff its Configure against the one 
from the previous release, and decide whether we need to make corresponding 
edits to our own Configure. We also document what we've changed in our own 
Configure.

It looks like you're building OpenSSL into archive libraries that you then 
intend to link statically into your own shared objects. That's what my teams do 
as well. OpenSSL's Configure wants to either build OpenSSL itself as shared 
objects, or build archive libraries that aren't suitable for use in shared 
objects (i.e. lack -fPIC or whatever the local toolchain's equivalent is). At 
least that's the way it was back when we forked Configure in some 1.0.1 
release, and we've continued to use our own Configure since.

It's not ideal, but in practice updating our Configure when we get a new 
OpenSSL 1.0.2 release has been trivial - it hardly takes any more time than 
downloading the tarball and checking the signature, and certainly much less 
than building and testing on all of the platforms we support.

And OpenSSL is still far less trouble for us than, say, OpenLDAP.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Dennis Clarke]

On 06/02/2017 10:36 AM, Salz, Rich via openssl-users wrote:

Dennis,

Feel free to not read any documentation you find superfluous :)


I'll simply leave this here as an example of truely fine CHANGES docs :

https://lists.freedesktop.org/archives/xorg/2017-June/058761.html

Dennis Clarke

ps: that is what people generally expect to see in CHANGES but the
 openssl folks may disagree of course.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL version 1.0.2l published

[Dennis Clarke]

you are the first person to raise this issue that I can recall in over 20 years.



I'll just go back to my server cave then.

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Salz, Rich via openssl-users]

Dennis,

Feel free to not read any documentation you find superfluous :)

Too much information is not something people often say about OpenSSL.  We 
believe many people find the current file useful.  To wit, you are the first 
person to raise this issue that I can recall in over 20 years.

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Salz, Rich via openssl-users]

> Appending a note that, for a full change log, [DO THIS], would probably be
> well received.

https://github.com/openssl/openssl/pull/3606

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Dennis Clarke]

Sure, would "Major changes" be sufficient?  This is essentially
a RELEASE_NOTES file, not a comprehensive change log, which is
subsumed by git.


Exactly.  Lots of us have been trained by much experience that a file
named CHANGES contains *all* of the changes, while a file named
RELEASE_NOTES includes selected changes of particular significance.
It's confusing to call a release-notes file CHANGES.

Appending a note that, for a full change log, [DO THIS], would probably
be well received.




Simply remove the CHANGES file from the source release.

Since it clearly is not a "CHANGES" list nor is it useful.

I feel rather strongly that a source release of production grade
quality should come with reasonable documentation. That means within the
area of good judgement and reason. So a file in the production grade
source tarball that has a "CHANGES" file which clearly lists nothing of
any real value should be removed.  Perhaps there is a very long standing
tradition, not so much a de facto standard, however an expectation that
the source tarball to be used for a production grade release should have
certain little features in it. A file that says "INSTALL" which actually
does document ways to perform an out of the box[1] compile, testsuite
and then install.  That can be removed entirely also and replaced with a
note that says "see the internet".  How about the LICENSE or README?
These are archaic, ancient old dusty concepts and they go way way back
to the days of Apollo workstations or Sun deskside monsters.  Why do we
still bother with the install of the manpages?  Are those needed?  Who
actually ever runs "man SSL_CTX_free" and then reads the manpage?  It
really doesn't have much to say.  Just tell the user or the package
maintainer to go get it themselves somewhere.  Also what is that great
awful long thing CHANGES.SSLeay?  Toss that out the airlock.

This is what is needed, a trivial one line replacement :

sedna$ cat ACKNOWLEDGMENTS
Please https://www.openssl.org/community/thanks.html for the current
acknowledgements.

I guess I'm being foolish to think that the source release is the
absolute reference standard. It is the "published" actual source as well
as the essential docs for it.  Perhaps expectations of that nature are
just twenty or thirty year old concepts because we have the internet at
our fingertips and the real data is out there .. somewhere. Go find it.

Dennis Clarke

[1] out of the box?  sorry, my age is showing. Perhaps "git pull" ?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL version 1.0.2l published

[Mark H. Wood]

On Thu, Jun 01, 2017 at 09:18:26PM -0400, Viktor Dukhovni wrote:
> 
> > On Jun 1, 2017, at 10:54 AM, Wouter Verhelst  
> > wrote:
> > 
> > It might be useful to make that point at the start of the CHANGES file,
> > then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy
> > [date]". While that doesn't claim to be complete, the simple word
> > "CHANGES" invokes the idea of a changelog, which should be complete --
> > and this file is not. If it's not meant to be, fine -- but then it
> > doesn't hurt to say so, and it would alleviate some confusion.
> 
> Sure, would "Major changes" be sufficient?  This is essentially
> a RELEASE_NOTES file, not a comprehensive change log, which is
> subsumed by git.

Exactly.  Lots of us have been trained by much experience that a file
named CHANGES contains *all* of the changes, while a file named
RELEASE_NOTES includes selected changes of particular significance.
It's confusing to call a release-notes file CHANGES.

Appending a note that, for a full change log, [DO THIS], would probably
be well received.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] -fPIC option missing for crypto/bn/x86_64-gcc.c and some other files in 1.0.2l that exists in 1.0.1m & 1.1.0c

[Bill Smith]

Hi, 
I'm building OpenSSL 1.0.2l on Centos Linux 5.4.  When linking the libcrypto.a 
library against my application, I'm getting the error:

/usr/bin/ld: /vobs_prgs/src/openssl/linuxx86_64/lib/libcrypto.a(x86_64-gcc.o): 
relocation R_X86_64_32 against 'a local symbol' can not be used when making a 
shared object; recompile with -fPIC


Looking at the openssl build output, sure enough, it's missing -fPIC.

gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -O3 
-Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -c -o x86_64-gcc.o asm/x86_64-gcc.c

If I compare compilation output with 1.0.1m, I see that -fPIC is included.  
Ditto for 1.1.0c.

I look at the configure output for 1.0.2l and see -fPIC is missing for CFLAG:

IsMK1MF=0
CC=gcc
CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 
-DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM

The configure output for 1.0.1m has -fPIC for CFLAG:
IsMK1MF=0
CC=gcc
CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_LINUX-SHARED -m64 
-fvisibility=hidden -fPIC -DPIC -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int 
-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


What is the correct way for me to add the -fPIC option so that 
crypto/bn/x86_64-gcc.c is compiled with it?  Thanks!








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

Re: [openssl-users] ECDSA and ECDH

[Salz, Rich via openssl-users]

> with a host device which will be ported with FIPS compliant OpenSSL library.  
> Our embedded device will be using ECDSA (FIPS 186-3)  and ECDH (FIPS 
> SP800-56A) by calling APIs of ATECC508A SDK.  Is there any compatibility 
> issue?  

There shouldn't be.  But interop is a hard thing, and a single bug on either 
side can break compatibility.  You really won't know until you test it.  

> 1. Whether a digest signed using openssl library can be verified in our 
> embedded module and vice-versa .

As I said, it should work.

> 2. We understand that, OpenSSL doesn’t have FIPS 140-2 certification for 
> ECDH. If we use ECDH, whether we can claim our system to be FIPS 140-2 
> compliant?

You should be careful what you say.  If you claim to be certified, that would 
be lying ...


> ---Disclaimer-- This e-mail contains PRIVILEGED 
> AND CONFIDENTIAL INFORMATION

Please get your company policy changed.  Posting a big block disclaimer like 
this, when writing to a public mailing list, is very obnoxious.

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

Re: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e?

[Matt Caswell]

On 01/06/17 18:16, Siyuan Xiang wrote:
> Hi Matt,
> 
> I tried the following command, it failed.  following is my command. 
> 
> ./config enable-weak-ssl-ciphers --prefix=/opt
> make
> make DESTDIR=/path/to/dir INSTALL
> 
> $ ./openssl version
> OpenSSL 1.1.0e  16 Feb 2017
> 
> ./openssl s_client -cipher "RC4-MD5:@SECLEVEL=0"
> 
> error setting cipher list
> 140369010624144:error:140E6118:SSL
> routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1337:
> 
> 
> ./openssl ciphers "RC4-MD5:@SECLEVEL=0"
> Error in cipher list
> 140458428679936:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no
> cipher match:ssl/ssl_lib.c:2018:

That's very strange. Those exact same commands work fine for me. Are you
sure you are picking up the version of 1.1.0e compiled with
enable-weak-ssl-ciphers and not some other previous compilation of 1.1.0e?

Matt


> 
> However, after I change  SSL_CTX_set_XXX function
> orders, TLS_RSA_WITH_RC4_128_MD5 do appear in client hello cipher list.
> 
> SSL_CTX_set_security_level(ctx, 0);
> SSL_CTX_set_cipher_list(ctx, "ALL:RC4-MD5");
> 
> Regards,
> Siyuan
> ---
> 
> On Thu, Jun 1, 2017 at 2:41 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 31/05/17 21:22, Siyuan Xiang wrote:
> > Hi all,
> >
> > I have a legacy server only accept TLS_RSA_WITH_RC4_128_MD5 cipher.
> >
> > I have a client using openssl 1.1.0e. It doesn't include
> > TLS_RSA_WITH_RC4_128_MD5.
> > I have recompiled the openssl using  enable-weak-ssl-ciphers, but it
> > doesn't work
> > but  TLS_RSA_WITH_RC4_128_SHA  is in client hello message.
> >
> > It looks like all MD5 related ciphers are removed.  I tried to
> > use SSL_CTX_set_security_level to
> > set level to 0. but it doesn't work.
> >
> > Do you have any idea how to enable TLS_RSA_WITH_RC4_128_MD5?
> 
> How have you configured your ciphersuite list? I can get this to work in
> 1.1.0 using s_server and s_client.
> 
> Having built with "enable-weak-ssl-ciphers" I start up s_server like
> this:
> 
> $ openssl s_server -cipher "RC4-MD5:@SECLEVEL=0"
> 
> And then run s_client like this:
> 
> $ openssl s_client -cipher "RC4-MD5:@SECLEVEL=0"
> 
> The connection is successful and uses the RC4-MD5 ciphersuite (aka
> TLS_RSA_WITH_RC4_128_MD5).
> 
> Matt
> --
> 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

[openssl-users] ECDSA and ECDH

[Manoj Ramachandran]

Hi,

We are planning to designing an embedded device integrating ATECC508A module 
for PKI support. The embedded device is planned to communicate with a host 
device which will be ported with FIPS compliant OpenSSL library.  Our embedded 
device will be using ECDSA (FIPS 186-3)  and ECDH (FIPS SP800-56A) by calling 
APIs of ATECC508A SDK.  Is there any compatibility issue?


1.   Whether a digest signed using openssl library can be verified in our 
embedded module and vice-versa .

2.   We understand that, OpenSSL doesn't have FIPS 140-2 certification for 
ECDH. If we use ECDH, whether we can claim our system to be FIPS 140-2 
compliant?


Regards,
Manoj
---Disclaimer-- This e-mail contains PRIVILEGED AND 
CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If 
you are not the intended recipient, please notify the sender by e-mail and 
delete the original message. Opinions, conclusions and other information in 
this transmission that do not relate to the official business of QuEST Global 
and/or its subsidiaries, shall be understood as neither given nor endorsed by 
it. Any statements made herein that are tantamount to contractual obligations, 
promises, claims or commitments shall not be binding on the Company unless 
followed by written confirmation by an authorized signatory of the Company. 
---
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL version 1.0.2l published

[Wouter Verhelst]

On 02-06-17 03:18, Viktor Dukhovni wrote:
> 
>> On Jun 1, 2017, at 10:54 AM, Wouter Verhelst  
>> wrote:
>>
>> It might be useful to make that point at the start of the CHANGES file,
>> then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy
>> [date]". While that doesn't claim to be complete, the simple word
>> "CHANGES" invokes the idea of a changelog, which should be complete --
>> and this file is not. If it's not meant to be, fine -- but then it
>> doesn't hurt to say so, and it would alleviate some confusion.
> 
> Sure, would "Major changes" be sufficient?  This is essentially
> a RELEASE_NOTES file, not a comprehensive change log, which is
> subsumed by git.

Something like that, yes.

Alternatively, a note saying "and a number of changes too small to be
noted here, please see the git log for details" at the end of every
changelog would work too (and give a hint to users where to go for more
details).

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