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

[Bill Smith]

Thanks for the info.  It turns out that we had customized the configure script 
but the person who did it didn't document it correctly.  Once I got that sorted 
out, I was able to build it correctly.

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Michael Wojcik
Sent: Friday, June 02, 2017 10:58 AM
To: openssl-users@openssl.org
Subject: 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

> 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 08/06/17 23:12, Neetish Pathak wrote:
> Thanks. 
> I had one query regarding the TLS 1.3 implementation on server side. I
> have a simple client server program with session resumption working with
> TLS 1.2. 
> When I use TLS 1.3, I see that server hello message has a malformed
> packet.

How do you know it is malformed? The format of the ServerHello message
has changed in TLSv1.3, so if you expect it to look like a TLSv1.2
ServerHello then you will be surprised.

> Though the SSL handshake is successful. I am not observing
> session resumption.
> I want to know what causes server hello to have a malformed packet.
> Also, is any extra configuration required for TLS 1.3 ?
> I am assuming TLS 1.3 can also use session Ids/ tickets for session
> resumption.

You probably want to read this blog post:

https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/

Session ids are not used in TLSv1.3 and session tickets work very
differently. Session resumption should work just fine but there are some
things to be aware of (discussed in the blog post).

Matt


> 
> Thanks
> Best Regards,
> Neetish
> 
> On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 08/06/17 01:26, Neetish Pathak wrote:
> > Hello All,
> >
> > I am new to the Openssl community.
> > I am using the latest version of Openssl (with TLS 1.3 enabled) for
> > performance benchmarking. I wanted to know if the session ticket support
> > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
> > needs to be explicitly enabled?
> 
> It is on by default.
> 
> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks.
I had one query regarding the TLS 1.3 implementation on server side. I have
a simple client server program with session resumption working with TLS
1.2.
When I use TLS 1.3, I see that server hello message has a malformed packet.
Though the SSL handshake is successful. I am not observing session
resumption.
I want to know what causes server hello to have a malformed packet. Also,
is any extra configuration required for TLS 1.3 ?
I am assuming TLS 1.3 can also use session Ids/ tickets for session
resumption.

Thanks
Best Regards,
Neetish

On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell  wrote:

>
>
> On 08/06/17 01:26, Neetish Pathak wrote:
> > Hello All,
> >
> > I am new to the Openssl community.
> > I am using the latest version of Openssl (with TLS 1.3 enabled) for
> > performance benchmarking. I wanted to know if the session ticket support
> > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
> > needs to be explicitly enabled?
>
> It is on by default.
>
> 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

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

[Jakob Bohm]

On 08/06/2017 20:26, Ludwig, Mark wrote:

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.


I know, that was (part of) the basis for my answer.

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

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] newer openSSL no longer produce libeay32 on Windows?

[Jakob Bohm]

On 08/06/2017 18:48, Baojun Wang wrote:
On windows platform, Some libraries (not openSSL) explicitly link with 
libeay32.dll, however, it seems openSSL 1.1+ only builds libssl & 
libcrypto (personally I prefer this, because it is consistent with 
other *nix platforms). What is the purpose of libeay32? Is it only for 
32-bit windows, and is it only part of older openSSL (0.9.8ish)?



libeay was the historic name for libcrypto back when OpenSSL
was SSLeay, the Windows port was late in implementing the name change.

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.

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] newer openSSL no longer produce libeay32 on Windows?

[Baojun Wang]

Hi list,

On windows platform, Some libraries (not openSSL) explicitly link with
libeay32.dll, however, it seems openSSL 1.1+ only builds libssl & libcrypto
(personally I prefer this, because it is consistent with other *nix
platforms). What is the purpose of libeay32? Is it only for 32-bit windows,
and is it only part of older openSSL (0.9.8ish)?

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?

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 08/06/17 01:26, Neetish Pathak wrote:
> Hello All,
> 
> I am new to the Openssl community.
> I am using the latest version of Openssl (with TLS 1.3 enabled) for
> performance benchmarking. I wanted to know if the session ticket support
> for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
> needs to be explicitly enabled?

It is on by default.

Matt

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