Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018, 13:10 Kurt Roeckx wrote: > On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > > Hello, > > > > What is the better way, for anyone running, by example, Apache or nginx > on > > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > > 1.3 ? > > > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > > > Recompile openssl dynamic library and replace system library ? We must be > > sure we don't broke the system > > > > Recompile Apache or NGinx with openssl statically linked ? probably > complex > > Note that you most likely need an update of both nginx/apache and > openssl. > Note that httpd 2.4 released does not yet support TLS 1.3, although it compiles against the new OpenSSL, YMMV. Within the next two httpd releases, we would expect OpenSSL 1.1.1 TLS 1.3 support to be GA. In the interim there is a working branch for 1.1.1 compatibility merges, and svn trunk already supports it, if you want to live on the bleeding edge. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On 09/11/2018 02:35 PM, Viktor Dukhovni wrote:
On Tue, Sep 11, 2018 at 02:28:12PM -0400, Dennis Clarke wrote:
It sounds like a downstream ELF header nightmare.
Actually, it works just fine. You link with the variant library,
and it happily coexists with any dependencies you may have that in
turn depend on the system TLS library. The variant SONAME and
symbol versions provide all the requisite isolation. You only
pay the cost of customization for the handful of packages you
want to have running against the non-default libraries.
Mildly interesting in giving it a try. However I have 1.1.1 running and
tested fine on Solaris 10 sparc without any interferance from the system
provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set
to /usr/local/lib for everything I have built.
One thing I've not tested, is isolation from system SSL libraries
that don't employ symbol versions. Debian has been doing symbol
versions for a long time, so I never needed to worry about that.
And OpenSSL 1.1.0 has symbol versions on most platforms.
I would assume that Solaris also has symbol versions for OpenSSL
1.0.x, but if it does not and that's the system's SSL library, then
the variant build might not happily coexist with indirect dependencies
in other shared libraries, haven't tried that. Regardless, you're
no worse off than with the default SONAME and symbol versions.
The GNU ld manual makes direct reference to ye old Solaris 2.5 as a sort
of template for the format used.
https://sourceware.org/binutils/docs/ld/VERSION.html
but you won't find the section headers ( SHT_GNU_versym, SHT_GNU_verdef,
and SHT_GNU_verneed ) in an ELF file on Solaris but SUNW_version has
been around forever ( I think I saw it in 1994 ? ) :
# elfdump -devl /usr/local/bin/openssl
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_SOLARISei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_EXEC
e_flags:[ EF_SPARCV9_TSO ]
e_entry: 0x100020200 e_ehsize: 64 e_shstrndx: 29
e_shoff: 0x194bd78 e_shentsize: 64 e_shnum: 31
e_phoff: 0x40 e_phentsize: 56 e_phnum: 5
Version Needed Section: .SUNW_version
index fileversion
[2] libssl.so.1.1 OPENSSL_1_1_0[ INFO ]
[3] OPENSSL_1_1_1
[4] libcrypto.so.1.1OPENSSL_1_1_0[ INFO ]
[5] OPENSSL_1_1_1
[6] libsocket.so.1 SUNW_0.7
[7] librt.so.1 SUNW_1.2
[8] SUNW_1.1 [ INFO ]
[9] libpthread.so.1 SUNW_1.2
[10] SUNW_0.9 [ INFO ]
[11] libc.so.1 SUNW_1.21.2
[12] SUNW_1.1 [ INFO ]
[13] SUNW_0.7 [ INFO ]
Dynamic Section: .dynamic
index tagvalue
[0] NEEDED0x86d5 libssl.so.1.1
[1] NEEDED0x86ff libcrypto.so.1.1
[2] NEEDED0x8710 libsocket.so.1
[3] NEEDED0x8774 libnsl.so.1
[4] NEEDED0x8780 libdl.so.1
[5] NEEDED0x8728 librt.so.1
[6] NEEDED0x8745 libpthread.so.1
[7] NEEDED0x875e libc.so.1
[8] INIT 0x100904ff8
[9] FINI 0x100905008
[10] RUNPATH 0x878b /usr/local/lib
[11] RPATH 0x878b /usr/local/lib
[12] HASH 0x10178
[13] STRTAB0x1e710
[14] STRSZ 0x899a
[15] SYMTAB0x13b08
[16] SYMENT0x18
[17] CHECKSUM 0x9857
[18] VERNEED 0x1000170b0
[19] VERNEEDNUM0x6
[20] PLTRELSZ 0x7e48
[21] PLTREL0x7
[22] JMPREL0x1000183b8
[23] RELA 0x100018028
[24] RELASZ0x81d8
[25] RELAENT 0x18
[26] DEBUG 0
[27] FLAGS 0 0
[28] FLAGS_1 0 0
[29] SUNW_STRPAD 0x200
[30] SUNW_LDMACH 0x2bEM_SPARCV9
[31] PLTGOT0x100a26700
[32-42] NULL 0
jupiter #
Anyways .. the whole mess started with Sun's versioning concepts and it
was Ulrich Drepper that did the first implementation in glibc 2.1 with
Eric Youngdale who also bolted in "symbol-level versioning with multiple
definitions of a symbol." :
https:/
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 02:28:12PM -0400, Dennis Clarke wrote: > >> It sounds like a downstream ELF header nightmare. > > > > Actually, it works just fine. You link with the variant library, > > and it happily coexists with any dependencies you may have that in > > turn depend on the system TLS library. The variant SONAME and > > symbol versions provide all the requisite isolation. You only > > pay the cost of customization for the handful of packages you > > want to have running against the non-default libraries. > > Mildly interesting in giving it a try. However I have 1.1.1 running and > tested fine on Solaris 10 sparc without any interferance from the system > provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set > to /usr/local/lib for everything I have built. One thing I've not tested, is isolation from system SSL libraries that don't employ symbol versions. Debian has been doing symbol versions for a long time, so I never needed to worry about that. And OpenSSL 1.1.0 has symbol versions on most platforms. I would assume that Solaris also has symbol versions for OpenSSL 1.0.x, but if it does not and that's the system's SSL library, then the variant build might not happily coexist with indirect dependencies in other shared libraries, haven't tried that. Regardless, you're no worse off than with the default SONAME and symbol versions. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
It sounds like a downstream ELF header nightmare. Actually, it works just fine. You link with the variant library, and it happily coexists with any dependencies you may have that in turn depend on the system TLS library. The variant SONAME and symbol versions provide all the requisite isolation. You only pay the cost of customization for the handful of packages you want to have running against the non-default libraries. Mildly interesting in giving it a try. However I have 1.1.1 running and tested fine on Solaris 10 sparc without any interferance from the system provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set to /usr/local/lib for everything I have built. Otherwise, you have to be sure to recompile the world ... Right. Recompile the "world" isn't what it once was and a decently fast system gets that done overnight. In any case https://www.tls13.net/ is running just fine and a whole slew of browsers ( and curl ) have hit it. Nothing from the Opera folks however. Makes me wonder about lynx/links text browsers too. Dennis -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 08:10:01PM +0200, Kurt Roeckx wrote: > On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > > Hello, > > > > What is the better way, for anyone running, by example, Apache or nginx on > > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > > 1.3 ? > > > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > > > Recompile openssl dynamic library and replace system library ? We must be > > sure we don't broke the system > > > > Recompile Apache or NGinx with openssl statically linked ? probably complex > > Note that you most likely need an update of both nginx/apache and > openssl. > > I will very likely make 1.1.1 available in Debian backports. I hope that > the nginx maintainer will also make a version that works with 1.1.1. Looking at stretch-backports, it already has an nginx version that is recent enough, so you would just need a new openssl. I can only do an openssl upload to backports after it has reached testing. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > Hello, > > What is the better way, for anyone running, by example, Apache or nginx on > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > 1.3 ? > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > Recompile openssl dynamic library and replace system library ? We must be > sure we don't broke the system > > Recompile Apache or NGinx with openssl statically linked ? probably complex Note that you most likely need an update of both nginx/apache and openssl. I will very likely make 1.1.1 available in Debian backports. I hope that the nginx maintainer will also make a version that works with 1.1.1. But this is most likely going to take a while. We first want to make things work properly in testing. In the mean time buillding things yourself seems like the easiest solution. If using Debian you can just take the versions of the packages currently in unstable and build them on stable. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On Tue, Sep 11, 2018 at 01:47:18PM -0400, Dennis Clarke wrote:
> >--- Configurations/10-main.conf
> >+++ Configurations/10-main.conf
> >
> >+"BSD-x86_64-opt" => {
> >+inherit_from => [ "BSD-x86_64" ],
> >+shlib_variant => "-opt",
> >+},
> >+
I guess this is a thread about Linux, and I gave a BSD example, but
there are no substative differences.
> It sounds like a downstream ELF header nightmare.
Actually, it works just fine. You link with the variant library,
and it happily coexists with any dependencies you may have that in
turn depend on the system TLS library. The variant SONAME and
symbol versions provide all the requisite isolation. You only
pay the cost of customization for the handful of packages you
want to have running against the non-default libraries.
This has been running in production on thousands of servers for
multiple years on Ubuntu (karmic, since retired), Debian wheezy,
jessie and stretch.
Otherwise, you have to be sure to recompile the world, to avoid
dependency conflicts where some system library use TLS, say for
LDAP lookups via an nsswitch module, and crashes because it wants
a differen OpenSSL version.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
On 09/11/2018 01:09 PM, Viktor Dukhovni wrote:
On Sep 11, 2018, at 10:59 AM, Juan Isoza wrote:
What is the better way, for anyone running, by example, Apache or nginx on a
popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ?
Waiting package update to have openssl 1.1.1 ? probably a lot of time
Roll you own. It works. Really really well in fact.
Recompile openssl dynamic library and replace system library ? We must be sure
we don't broke the system
Don't do that. That path leads to madness.
Recompile Apache or NGinx with openssl statically linked ? probably complex
You can install OpenSSL 1.1.1 in a non-default location, say:
./Configure --prefix=/usr/local/opt/openssl/1.1.1 BSD-x86_64-opt shared
with the "BSD-x86_64-opt" target inheriting from "BSD-x86_64":
--- Configurations/10-main.conf
+++ Configurations/10-main.conf
+"BSD-x86_64-opt" => {
+inherit_from => [ "BSD-x86_64" ],
+shlib_variant => "-opt",
+},
+
Integrating this into "ports" is an exercise for the reader...
It sounds like a downstream ELF header nightmare. Most likely better to
just isolate systems entirely and build the software stack dependencies
using standard locations and standard SONAME/RPATH/RUNPATH data. However
if someone wants to spin in tight circles battling lib resolution, well
gee, sounds like endless fun. Not for me .. thanks.
Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server
> On Sep 11, 2018, at 10:59 AM, Juan Isoza wrote:
>
> What is the better way, for anyone running, by example, Apache or nginx on a
> popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ?
>
> Waiting package update to have openssl 1.1.1 ? probably a lot of time
>
> Recompile openssl dynamic library and replace system library ? We must be
> sure we don't broke the system
>
> Recompile Apache or NGinx with openssl statically linked ? probably complex
You can install OpenSSL 1.1.1 in a non-default location, say:
./Configure --prefix=/usr/local/opt/openssl/1.1.1 BSD-x86_64-opt shared
with the "BSD-x86_64-opt" target inheriting from "BSD-x86_64":
--- Configurations/10-main.conf
+++ Configurations/10-main.conf
+"BSD-x86_64-opt" => {
+inherit_from => [ "BSD-x86_64" ],
+shlib_variant => "-opt",
+},
+
but also specifying 'shlib_variant => "-opt"', see Configurations/README:
shlib_variant => A "variant" identifier inserted between the base
shared library name and the extension. On "unixy"
platforms (BSD, Linux, Solaris, MacOS/X, ...) this
supports installation of custom OpenSSL libraries
that don't conflict with other builds of OpenSSL
installed on the system. The variant identifier
becomes part of the SONAME of the library and also
any symbol versions (symbol versions are not used or
needed with MacOS/X). For example, on a system
where a default build would normally create the SSL
shared library as 'libssl.so -> libssl.so.1.1' with
the value of the symlink as the SONAME, a target
definition that sets 'shlib_variant => "-abc"' will
create 'libssl.so -> libssl-abc.so.1.1', again with
an SONAME equal to the value of the symlink. The
symbol versions associated with the variant library
would then be 'OPENSSL_ABC_' rather than
the default 'OPENSSL_'. The string inserted
into symbol versions is obtained by mapping all
letters in the "variant" identifier to upper case
and all non-alphanumeric characters to '_'.
The resulting libraries have a non-default SONAME:
$ readelf -d *.so | grep SONAME
0x000e SONAME Library soname:
[libcrypto-opt.so.1.1]
0x000e SONAME Library soname: [libssl-opt.so.1.1]
And non-default symbol versions:
$ objdump -T libssl.so | grep SSL_CTX_new
000338c0 gDF .text 03b3 OPENSSL_OPT_1_1_0
SSL_CTX_new
$ objdump -T libcrypto.so | grep X509_new
001d7be0 gDF .text 0011 OPENSSL_OPT_1_1_0 X509_new
All that remains is to link Apache, Nginx, ... with these libraries instead:
CFLAGS+="-I/usr/local/opt/openssl/1.1.1/include"
LDFLAGS+="-L/usr/local/opt/openssl/1.1.1/lib
-Wl,-rpath,/usr/local/opt/openssl/1.1.1/lib"
Integrating this into "ports" is an exercise for the reader...
--
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
