Re: [openssl-users] Any advice/recommendation for watching TLS version negotiation

[Ludwig, Mark]

> From: Wall, Stephen, Monday, November 28, 2016 6:52 AM
> 
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> > Behalf Of Ludwig, Mark
> >
> > A customer claims to have configured the web (app) server to only allow
> > TLS 1.2
> > (by disallowing up through TLS 1.1), and says that the client code
> > (which we
> > know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS
> > 1.1.  We
> > are setting up a similar environment internally to diagnose what's
> > happening,
> > and I wonder if anyone has any advice on the "best" tool for "watching"
> > the TLS
> > version negotiation when the connection is being established.
> 
> I've typically used Wireshark for this type of thing.  If you are using RSA 
> and have
> a copy of the server key, you can also examine the encrypted channel content.

Yes, thanks, a colleague today enlightened me that Wireshark will read the 
captured data from snoop.  Voila!

I didn't bother to get the key -- not sure it's RSA -- because I'm not 
interested 
in the encrypted data.  I only want to see the TLS handshake, which Wireshark 
decodes nicely.

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

[openssl-users] Any advice/recommendation for watching TLS version negotiation

[Ludwig, Mark]

Greetings,

We have embedded OpenSSL 1.0.2j in our application order to securely
communicate with a Java Servlet engine (such as Tomcat).  Our application uses
SSLv23_method(), so I expect it to negotiate up through TLS 1.2 (right?).

A customer claims to have configured the web (app) server to only allow TLS 1.2
(by disallowing up through TLS 1.1), and says that the client code (which we
know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS 1.1.  We
are setting up a similar environment internally to diagnose what's happening,
and I wonder if anyone has any advice on the "best" tool for "watching" the TLS
version negotiation when the connection is being established.

The client environment is Solaris 10.  I'm obtaining the necessary privileges
to use the snoop command.  Does anyone have any do's or don'ts for using snoop?

Thanks in advance!

Mark Ludwig

Siemens Product Lifecycle Management Software Inc.
Communications and Government Affairs
Product Lifecycle Management
Lifecycle Coll
5939 Rice Creek Parkway
Shoreview, MN  55126 United States 
Tel.  :+1 (651) 855-6140
Fax  :+1 (651) 855-6280
ludwig.m...@siemens.com 
www.siemens.com/plm 

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

Re: [openssl-users] Return type of SSL_ctrl

[Ludwig, Mark]

> From: Salz, Rich, Wednesday, November 30, 2016 9:38 AM
> 
> > We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and
> > noticed that the SSL functions based on SSL_ctrl() changed from returning
> > type int to returning type long.
> 
> The "proper" answer is to not use long, but rather sized types, which we are
> slowly moving toward.

Funny you should mention this, because this topic arose
internally after someone decided to change the return type
of SSL_ctrl() to intprt_t.  I have no idea why, since as far
as I can tell, all of the return values would fit in a
32-bit integer; thus my question about why it was changed to
long, which is either 32 bits or 64 bits, depending on
platform.  I suspect it was the use of long that tricked someone 
into thinking it might be holding a pointer, and thus led to the 
change to intptr_t, so it would fit on Windows.  (Blind/stupid
global replacement.)

(Does OpenSSL support any platform in which type int is 16 bits?)

Thanks,
Mark

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

[openssl-users] Return type of SSL_ctrl

[Ludwig, Mark]

Greetings,

We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and noticed 
that the SSL 
functions based on SSL_ctrl() changed from returning type int to returning type 
long.

It's not clear why this is necessary, by spot-checking the documented numerical 
domain of the 
return values of the SSL functions (macros) deriving from SSL_ctrl().  Why was 
this done?

(I don't see mention of this in the CHANGES file.)

Thanks,

Mark Ludwig

Siemens Product Lifecycle Management Software Inc.
Communications and Government Affairs
Product Lifecycle Management
Lifecycle Coll
5939 Rice Creek Parkway
Shoreview, MN  55126 United States 
Tel.  :+1 (651) 855-6140
Fax  :+1 (651) 855-6280
ludwig.m...@siemens.com 
www.siemens.com/plm 

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

Re: [openssl-users] newer openSSL no longer produce libeay32 on Windows?

[Ludwig, Mark]

> From: Jakob Bohm, Thursday, June 08, 2017 12:32 PM
> 
> On 08/06/2017 18:48, Baojun Wang wrote:
> > Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well
> > as libcrypto-1_1-x64.dll, this could be painful for application who
> > has to specify openssl dependency, for example now I have to choose
> > ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a
> > more idiomatic way to make linking on windows (not only 64-bit)
> > easier, do you have any idea?
> Traditionally, Windows (like Unix) uses the same file name for
> 32 and 64 bits, but puts them in different directories.  If
> they need to be in the same directory for some applications,
> the traditional solution is to insert "32" or "64" on its own,
> while still using the same file name for different architectures
> with the same bitness.  For example a compile for 32 bit MIPS
> (supported by older Windows releases) or 32 bit ARM (supported
> by newer releases) would have the same name as for 32 bit x86.
> Similar for the 4 64 bit architectures supported at various
> times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM).
> 
> Microsoft did some crazy experiments with a directory scheme
> called SxS for versioned DLLs, its badly done and should be
> avoided if possible.

The side-by-side (SxS) stuff has its place, but to use it
effectively requires using a "manifest" to identify the
dependencies explicitly.  I also don't recommend it for
general use.

Regarding the "32" suffix, you'll see that throughout
Windows itself, on modern 64-bit versions, because the "32"
dates back to the 1990s when Windows was trying to grow out
of being a 16-bit DOS program (WIN.EXE) into a 32-bit
"operating system" (Windows NT).  Many people are
misdirected with the term "Win32" into thinking that means
32-bit when it really only means "not 16-bit."  Anything
labeled "Win32" could be either 32-bit or 64-bit.

I haven't started working with OpenSSL 1.1.n, but in OpenSSL
1.0.2, all 64-bit builds produce identically-named binaries
such as libeay32.lib and libeay32.dll in the "out32"
directory.

Hope this helps,
Mark

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

Re: [openssl-users] Help compiling on HPUX

[Ludwig, Mark]

> From: Michael Wojcik, Wednesday, November 08, 2017 7:03 AM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Help compiling on HPUX
> 
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Dan Freed
> > Sent: Tuesday, November 07, 2017 19:14
> > To: openssl-users@openssl.org
> > Subject: [openssl-users] Help compiling on HPUX
> 
> > I see that there are a few posts about compiling openssl on HP-UX, so I’m
> hopeful that someone can help me out.
> 
> My initial suspect is the assembly modules. I suggest configuring with no-asm,
> and if that works and you really want the assembly code for performance, then
> investigate further.
> 
> Another possibility is optimization. We had issues building OpenSSL for HP-UX
> (PA-RISC and Itanium) with +O4, which is what Configure specifies for at least
> some HP-UX builds. We backed it off to +O1 (by editing Configure; we actually
> use our own Configure script, and merge in changes from the official one each
> time we update to a new OpenSSL release).

Dan, you did not specify the platform.  I have not built on RISC since OpenSSL 
0.9.8.
I have built OpenSSL 1.0.2k on Itanium as follows.  I mostly agree with 
Michael, 
but have not backed off optimization quite as far.  Note that my use cases do 
not
include encrypting/decrypting large payloads, so can get away with reduced
performance to get correct results (i.e., pass the tests).

I had to edit util/selftest.pl for the compiler's identification output
and because the ar(1) command will not accept /dev/null as an input file.

I also eliminated a lot of the tests in test/cms-tests, because we do not use 
the 
modules being tested.  (They were failing.)  I can believe these might work 
with 
lower optimization such as Michael recommends.

Below is the Configure output.  Hope this helps.

Configuring for hpux64-ia64-cc
no-asm  [option]   OPENSSL_NO_ASM
no-dso  [option]  
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp  [default]  OPENSSL_NO_GMP (skip dir)
no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-rfc3779  [default]  OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl2 [default]  OPENSSL_NO_SSL2 (skip dir)
no-store[experimental] OPENSSL_NO_STORE (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
no-zlib [default] 
no-zlib-dynamic [default] 
IsMK1MF=0
CC=cc
CFLAG =+Z -DOPENSSL_PIC -DOPENSSL_THREADS  -Ae +DD64 +O3 +Olit=all -z 
-DB_ENDIAN -D_REENTRANT
EX_LIBS   =-ldl
CPUID_OBJ =mem_clr.o
BN_ASM=bn_asm.o
EC_ASM=
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes_core.o aes_cbc.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4_enc.o rc4_skey.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =
RMD160_OBJ_ASM=
CMLL_ENC  =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ =
ENGINES_OBJ   =
PROCESSOR =
RANLIB=/usr/ccs/bin/ranlib
ARFLAGS   =
PERL  =/usr/local/smd/bin/perl
SIXTY_FOUR_BIT_LONG mode
DES_RISC1 used
DES_UNROLL used
DES_INT used
RC4_INDEX mode
RC4_CHUNK is undefined
MD2 uses uchar

> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
> --
> 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] ar : File format not recognized

[Ludwig, Mark]

> From: Bill Kurland, Tuesday, April 17, 2018 4:19 PM
> 
> I'm trying to build openssl-1.1.0h on AIX 6.1 with the ultimate goal of 
> building the IO::Socket::SSL perl module.
> 
> make fails when creating libcrypto.a and libssl.a because, it seems, the *.o 
> files are in a format not recognized by ar
> 
> I've passed "-Wl,-baix5coff64-rs6000" in config. I've also set 
> LDFLAGS="-Wl,-rpath=/usr/local/openssl/lib -Wl,-baix5coff64-rs6000" though I 
> don't see how that would have an effect on this problem.
> 
> I get the same result when I try to run ar command shown in the make output 
> from the command line:
> ar r ../test2.sh
> 
> where test2.sh contains all the *.o files in crypto
> 
> Every source I can find seems to indicate that gcc should just 'know' what 
> the correct file format is. Am I missing something? Well, obviously I'm 
> missing something. Can anyone point out what?
> 
> Thanks

Not sure this will help, because I built v1.0.2 (haven't gotten to v1.1.0 yet) 
using the AIX compiler rather than gcc, but the AIX archiver (ar) has a -X 
option that specifies how many bits.

For example, your example might work as:

 ar -X 64 r LIBNAME.a ../test2.sh

(At least, I assume you're building 64-bit binaries based on seeing "coff64" 
above.)
(I also assume you omitted the library name in e-mail.)

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

RE: Reg solaris support for openssl 1.1.1b

[Ludwig, Mark]

> From: Dennis Clarke, Friday, March 15, 2019 8:33 AM
> 
> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> > My guess is that your binary is loading the system's shared libraries.
> > To find out whether this is the case, try
> >
> >     ldd bin/openssl
> >
> > If my assumption is correct, you might have to set the LD_LIBRARY_PATH
> > explicitely.
> 
> Actually LD_LIBRARY_PATH is evil.
> 
> The correct way to do this is to compile with a RUNPATH set in the
> output ELF files.

Assuming you are in control of the destination systems' library locations, 
RUNPATH is desirable.

For an ISV, LD_LIBRARY_PATH is a necessary evil for application-delivered 
libraries.

> Building on Solaris is a real pain.

Compared with what?  This is how all Unices/*nix's work.

Best,
Mark Ludwig

Re: [openssl-users] OpenSSL 3.0 and FIPS Update

[Ludwig, Mark]

+1 on the point: firm expiration date without firm replacement date ... really?!

We have to hope that the firm expiration date will actually move if the 
replacement isn't ready before then ... and that doesn't begin to account for 
the calendar time to get the new one certified

Thanks,
Mark Ludwig

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Jakob Bohm via openssl-users
Sent: Thursday, February 14, 2019 10:34 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL 3.0 and FIPS Update

On 13/02/2019 20:12, Matt Caswell wrote:
>
> On 13/02/2019 17:32, Jakob Bohm via openssl-users wrote:
>> On 13/02/2019 12:26, Matt Caswell wrote:
>>> Please see my blog post for an OpenSSL 3.0 and FIPS Update:
>>>
>>> https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
>>>
>>> Matt
>> Given this announcement, a few questions arise:
>>
>> - How will a FIPS provider in the main tarball ensure compliance
>>   with the strict code delivery and non-change requirements of the
>>   CMVP (what was previously satisfied by distributing physical
>>   copies of the FIPS canister source code, and sites compiling this
>>   in a highly controlled environment to produce a golden canister)?
> My understanding is that physical distribution is no longer a requirement.
And the other things in that question?

Integrity of validated source code when other parts of the tarball
get regular changes?

Building the validated source code in a controlled environment
separate from the full tarball?

(If there are answers in the FIPS 3.0.0 draft spec, they need repeating).

>> - Will there be a reasonable transition period where users of the
>>   old FIPS-validated module can transition to the new module (meaning
>>   that both modules are validated and usable with a supported
>>   FIPS-capable OpenSSL library)?  I imagine that applications relying
>>   on the existing FIPS canister will need some time to quality test
>>   their code with all the API changes from OpenSSL 1.0.x to OpenSSL
>>   3.0.x .  OS distributions will also need some time to roll out the
>>   resulting feature updates to end users.
> The old FIPS module will remain validated for some time to come, so both the 
> old
> and new modules will be validated at the same time for a while. 1.0.2 will go
> EOL at the end of this year. The intention is that 3.0 will be available 
> before
> that. It's not yet clear exactly when 3.0 will become available and what the
> overlap with 1.0.2 will be so I don't have an answer at this stage for
> transition period.
>
> Matt
>
So right now, FIPS-validated users are left hanging, with no date to
get a 3.0.0 code drop to start porting and a looming deadline for the
1.0.x API.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-- 
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 1.1.1b tests fail on Solaris - solution and possible fix

[Ludwig, Mark]

Thanks, from someone else who builds no-shared and will need this mod.

From: openssl-users  On Behalf Of John 
Unsworth
Sent: Thursday, May 16, 2019 5:47 AM
To: openssl-users@openssl.org
Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

In the absence of any steer from openssl gurus we will proceed by removing the 
#pragmas in safestack.h and lhash.h while we build the no-shared libraries on 
solaris. Hopefully someone will come up with a proper fix at some point.

Regards,
John

From: openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
On Behalf Of John Unsworth
Sent: 15 May 2019 21:08
To: openssl-users@openssl.org
Subject: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

>> Issue #pragma weak for a symbol only in the files that define that symbol, 
>> not in the ones that merely reference it.
The problem is that those pragmas are in .h files. They contain inline 
functions that use those symbols. The pragmas were added because of problems 
with apps that used the .h files (hard to avoid since they are basic crypto 
header files) but did not link with libcrypto.so. That library was explicitly 
loaded by the app, but the app would not start because of the missing symbols.

See issues 6912 and 8102.

Regards,
John.

-Original Message-
From: openssl-users 
mailto:openssl-users-boun...@openssl.org>> 
On Behalf Of Jakob Bohm via openssl-users
Sent: 15 May 2019 16:11
To: openssl-users@openssl.org
Subject: Re: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

Alternative suggestion (from my understanding of the documentation quoted
below):

Issue #pragma weak for a symbol only in the files that define that symbol, not 
in the ones that merely reference it.

The hoped effect would be:

1. Object files that merely reference a symbol will contain regular UNDEF
   entries
2. Object files that do define such a symbol will contain a WEAK defined
   entry
3. When seeing the UNDEF entries, the linker will look for an actual
   definition
4. If finding multiple WEAK defined entries, the linker will not complain,
   just use the first found.

I suspect the specified linker semantics of not trying to satisfy "WEAK UNDEF" 
entries would be suitable for optional link-time selected callbacks or data 
where a referencing library do runtime tests to see if the library- using 
program has provided a definition or not.  For example, it could be used for a 
symbol holding a list of global C++ constructors/destructors with libc code 
invoking that list if present without requiring dummy lists in programs without.

The .so case mentioned probably works "by chance" because libssl.so references 
non-weak libcrypto.so symbols, forcing the definition to be included in the 
runtime process anyway.

On 14/05/2019 11:29, John Unsworth wrote:
> Because of the #pragma weak directive the functions are defined multiple 
> times in both libcrypto.a and libssl.a:
>
> libcrypto.a
>
> Many UNDEF:
> ct_log.o
> [47]|   0|   0|FUNC |WEAK |0|UNDEF  
> |OPENSSL_sk_new_null
> ... and more
>
> One definition from stack.c as you'd expect:
> stack.o
> [33]  |1232|  20|FUNC |WEAK |2|2  
> |OPENSSL_sk_new_null
>
> libssl.a has multiple instances also, all UNDEF:
> d1_srtp.o
> [43]  |   0|   0|FUNC |WEAK |0|UNDEF  
> |OPENSSL_sk_new_null
> s3_lib.o
> [107] |   0|   0|FUNC |WEAK |0|UNDEF  
> |OPENSSL_sk_new_null
> and so on.
>
>  From the linker docs:
> B.2.17.1 #pragma weak name
> In the form #pragma weak name, the directive makes name a weak symbol. The 
> linker will not complain if it does not find a symbol definition for name. It 
> also does not complain about multiple weak definitions of the symbol. The 
> linker simply takes the first one it encounters.
>
> So when linking with libcrypto.a and libssl.a the first definition is taken 
> which is UNDEF in both cases leading to the error.
> This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o 
> the first files included. It could also be fixed by not defining those 
> pragmas when compiling stack.c, lh_stats.c and lhash.c because they will then 
> be GLOB instead of WEAK and will override all the WEAK definitions.
>
> However there is no suitable fix for libssl.a because those files are not 
> part of that library.
>
> Doing that means that executables that link libcrypto.a before libssl.s are 
> built correctly. However if the link is libssl.a followed by libcrypto.a the 
> UNDEF symbols from libssl.a are still used.
>
> In the shared libraries I see:
>
> libcrypto.so only instance:
> [3537]| 2409672|  20|FUNC |LOCL |2|10 
> |OPENSSL_sk_new_null
>
> Shared libssl.so also one instance:
> [2091]|   0|   0|FUNC