Migrating to openssl 1.1.1 in real life linux server

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrating to openssl 1.1.1 in real life linux server

Juan Isoza
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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Viktor Dukhovni


> On Sep 11, 2018, at 10:59 AM, Juan Isoza <[hidden email]> 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_<version>' rather than
                           the default 'OPENSSL_<version>'. 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
   0x000000000000000e SONAME               Library soname: [libcrypto-opt.so.1.1]
   0x000000000000000e SONAME               Library soname: [libssl-opt.so.1.1]

And non-default symbol versions:

  $ objdump -T libssl.so | grep SSL_CTX_new
  00000000000338c0 g    DF .text  00000000000003b3  OPENSSL_OPT_1_1_0 SSL_CTX_new

  $ objdump -T libcrypto.so | grep X509_new
  00000000001d7be0 g    DF .text  0000000000000011  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
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Dennis Clarke-2
On 09/11/2018 01:09 PM, Viktor Dukhovni wrote:
>
>
>> On Sep 11, 2018, at 10:59 AM, Juan Isoza <[hidden email]> 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",
>    +    },
>    +
>
<snip>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Viktor Dukhovni
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
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Kurt Roeckx
In reply to this post by Juan Isoza
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
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Kurt Roeckx
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
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Dennis Clarke-2
In reply to this post by Viktor Dukhovni

>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Viktor Dukhovni
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
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

Dennis Clarke-2
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_SOLARIS    ei_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  file                        version
        [2]  libssl.so.1.1               OPENSSL_1_1_0        [ INFO ]
        [3]                              OPENSSL_1_1_1
        [4]  libcrypto.so.1.1            OPENSSL_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  tag                value
        [0]  NEEDED            0x86d5              libssl.so.1.1
        [1]  NEEDED            0x86ff              libcrypto.so.1.1
        [2]  NEEDED            0x8710              libsocket.so.1
        [3]  NEEDED            0x8774              libnsl.so.1
        [4]  NEEDED            0x8780              libdl.so.1
        [5]  NEEDED            0x8728              librt.so.1
        [6]  NEEDED            0x8745              libpthread.so.1
        [7]  NEEDED            0x875e              libc.so.1
        [8]  INIT              0x100904ff8
        [9]  FINI              0x100905008
       [10]  RUNPATH           0x878b              /usr/local/lib
       [11]  RPATH             0x878b              /usr/local/lib
       [12]  HASH              0x100000178
       [13]  STRTAB            0x10000e710
       [14]  STRSZ             0x899a
       [15]  SYMTAB            0x100003b08
       [16]  SYMENT            0x18
       [17]  CHECKSUM          0x9857
       [18]  VERNEED           0x1000170b0
       [19]  VERNEEDNUM        0x6
       [20]  PLTRELSZ          0x7e48
       [21]  PLTREL            0x7
       [22]  JMPREL            0x1000183b8
       [23]  RELA              0x100018028
       [24]  RELASZ            0x81d8
       [25]  RELAENT           0x18
       [26]  DEBUG             0
       [27]  FLAGS             0                   0
       [28]  FLAGS_1           0                   0
       [29]  SUNW_STRPAD       0x200
       [30]  SUNW_LDMACH       0x2b                EM_SPARCV9
       [31]  PLTGOT            0x100a26700
    [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://www.akkadia.org/drepper/symbol-versioning

As for the sections that GNU ld type tools are looking for .. nope .. no
such things in ye Solaris implementation.  I'll take a gander at FreeBSD
which does use the GNU tools.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Migrating to openssl 1.1.1 in real life linux server

wrowe
In reply to this post by Kurt Roeckx
On Tue, Sep 11, 2018, 13:10 Kurt Roeckx <[hidden email]> 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