Re: LibreSSL Linux portability and OpenBSD security

[Joel Sing]

On Saturday 10 February 2018 11:09:04 Kevin Chadwick wrote:
> On Sat, 10 Feb 2018 16:24:38 +1100
> 
> > > Just in case some libressl dev doesn't want read the full thread in
> > > the Alpine list, they want also a workaround for the lack of time_t
> > > for 32bits platforms on Linux.
> > 
> > We've already addressed this - a notafter that exceeds 2038 is
> > clamped to 2038 on system that only has 32-bit time_t - see r1.65 of
> > src/lib/libcrypto/x509/x509_vfy.c:
> > 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c
> > .diff?r1=1.64=1.65
>
> Natanael had already found that but William says TAI64n is required to
> be conformant. Perhaps you will understand where he is coming
> from or whether he has an unspoken agenda? His original email did not
> seem to be a fair representation of facts though.

Conformant with what exactly? I do not recall seeing anything regarding TAI64N 
in TLS/X509 RFCs, where everything is handled in ASN.1 GENERALIZEDTIME or 
UTCTIME.
 
> I can't see how this (assuming this is the TAI64N in question) helps but
> I assume I am missing something.
> 
> https://cr.yp.to/daemontools/tai64n.html
> 
> "Beware that most gettimeofday implementations are not Y2038-compliant."

Re: LibreSSL Linux portability and OpenBSD security

[Kevin Chadwick]

On Sat, 10 Feb 2018 16:24:38 +1100


> > Just in case some libressl dev doesn't want read the full thread in
> > the Alpine list, they want also a workaround for the lack of time_t
> > for 32bits platforms on Linux.  
> 
> We've already addressed this - a notafter that exceeds 2038 is
> clamped to 2038 on system that only has 32-bit time_t - see r1.65 of 
> src/lib/libcrypto/x509/x509_vfy.c:
> 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c.diff?r1=1.64=1.65

Natanael had already found that but William says TAI64n is required to
be conformant. Perhaps you will understand where he is coming
from or whether he has an unspoken agenda? His original email did not
seem to be a fair representation of facts though.

I can't see how this (assuming this is the TAI64N in question) helps but
I assume I am missing something.

https://cr.yp.to/daemontools/tai64n.html

"Beware that most gettimeofday implementations are not Y2038-compliant."

Re: LibreSSL Linux portability and OpenBSD security

[Joel Sing]

On Saturday 10 February 2018 00:05:27 Juan Francisco Cantero Hurtado wrote:
[snip]
> Just in case some libressl dev doesn't want read the full thread in the
> Alpine list, they want also a workaround for the lack of time_t for
> 32bits platforms on Linux.

We've already addressed this - a notafter that exceeds 2038 is clamped to 2038 
on system that only has 32-bit time_t - see r1.65 of 
src/lib/libcrypto/x509/x509_vfy.c:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_vfy.c.diff?r1=1.64=1.65

> FYI: Adelie is a downstream distro of Alpine which wants to support
> "old" platforms. https://adelielinux.org/info.html#platforms

Re: LibreSSL Linux portability and OpenBSD security

[Theo de Raadt]

> It isn't just this.  Qt 5.10 introduces new dependency on OpenSSL 1.1
> APIs for improved security, and LibreSSL does not implement those APIs
> at all.

The 1.1 API does not improve security.

If anything, the new API requires to you repeat the same or similar
arguments to many functions, and in many ways the API is much more
fragile.  Also, more memory allocation and free is required, and as a
result quite a few software upgrades to 1.1 API have had memory leaks,
as well as use-after-free and double-free bugs.

A very large patch for converting openssh to 1.1 was provided by folk
who very much know the API, and it had several stupid and quite
dangerous mistakes of that sort.

Don't believe all the promises you hear.

Re: LibreSSL Linux portability and OpenBSD security

[Stuart Henderson]

On 2018-02-09, A. Wilcox <awil...@adelielinux.org> wrote:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --DCcmjS5tsvvgDBhgH7OD8mW309G9dT8Dp
> From: "A. Wilcox" <awil...@adelielinux.org>
> To: misc@openbsd.org
> Message-ID: <b265c12d-d9b3-f0c0-73df-8f0ec7e83...@adelielinux.org>
> Subject: Re: LibreSSL Linux portability and OpenBSD security
> References: <slrnp7rnrq.205u@naiad.spacehopper.org>
> In-Reply-To: <slrnp7rnrq.205u@naiad.spacehopper.org>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
>
> On 02/09/18 11:48, Stuart Henderson wrote:
>> I don't understand that, Cryptography is OK with LibreSSL. There have
>> been some problems at various times but they were either patched locally
>> or fixed upstream - we're a couple of point releases behind the latest
>> at the moment with no libressl-related patches - and I'd very surprised
>> if latest upstream had problems at the moment.
>
> cryptography 1.9 (2017-05-29) adds support for LibreSSL 2.5.x.  The
> package in question requires <=1.8.2 due to API changes in 1.9.
>
> You are correct that current versions of py-cryptography work correctly
> with LibreSSL, and I was quoted out of context.  I specifically noted in
> a different email that the problem was *older* versions of cryptography.
>  It'd be much better if Taiga and Mailman3 would just upgrade their
> requirements, but that would break systems where pyca isn't at the 2.x
> API level yet, so they are hesitant to do so.

Ah thanks, yes the older one needed a patch, that one was relatively simple
as far as libressl patches go, we had this:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/py-cryptography/patches/Attic/patch-src__cffi_src_openssl_x509_vfy_py?rev=1.3=text/x-cvsweb-markup

(though we don't have Mailman3 or Taiga in ports, so I don't know if those
in particular will work with it).

More recently I've been banging my head against things with a mixture
of OPENSSL_VERSION_NUMBER 0x101000... ifdefs, some of which need changing
to exclude LibreSSL, but others of which need keeping. These have been
getting more complicated than previously (and obviously going to see
more of this as other programs switch to supporting OpenSSL 1.1 API).

>>> compatibility in LibreSSL?  It would be good for packages that require
>>> LibreSSL (libressl-dev) to be buildable even if openssl-dev is installed
>>> (preventing something like the above Python situation).
>> 
>> No, there wouldn't be anything left without the OpenSSL-compatible-ish
>> code.
>> 
>> The big problem is if you have programs/libraries using OpenSSL
>> they can't be linked with programs/libraries using LibreSSL.
>> (Likewise, things using OpenSSL 1.0 can't be linked with things
>> using 1.1). Many of the symbol names are the same so would conflict.
>
> I was more asking if headers for libtls could be installed at the same
> time as actual OpenSSL headers.  This would allow me to build and test
> different backends (i.e., software that can use either OpenSSL 1.1 or
> libtls from LibreSSL) without needing to switch to chroot.  But I see
> now why this would be impossible, so thank you for clearing that up.

For simpler things it would be quite nice to have either a version of
libtls that's been ported to OpenSSL 1.1, or a version with the
libssl/libcrypto symbols renamed.

Though looking at the programs which _actually_ use libtls at present,
they aren't going to be pulling in other libraries that might use
OpenSSL, so just installing to paths which aren't usually searched might
be enough.

Re: LibreSSL Linux portability and OpenBSD security

[Juan Francisco Cantero Hurtado]

On Fri, Feb 09, 2018 at 12:58:30PM +, Kevin Chadwick wrote:
> I assume you know far more than me and A.Wilcox from the Alpine list
> but this was mentioned. They are planning to revert to OpenSSL next
> week.
> 
> I don't use Alpine, though it is possibly my preferred Linux, just
> thought I would mention it.
> 
> To be honest, I don't even know if facilitating wider adoption of
> LibreSSL hurts or benefits OpenBSD security in the end.
> 
> The last paragraph (taken from a separate mail), may be interesting?
> 
> I have no idea what debian etc. are doing.
> 
> http://lists.alpinelinux.org/alpine-devel/6079.html
> _
> 
> awilcox on ciall /usr/src/alpine-aports $ find . -name
> '*libressl*.patch' | sort
> ./community/asio/libressl.patch
> ./community/cargo/openssl-fix-libressl-cmsh-detection.patch
> ./community/cargo/openssl-libressl263-compat.patch
> ./community/erlang/0011-fix-libressl-build.patch
> ./community/freerdp/libressl-2.5.patch
> ./community/gsoap/libressl.patch
> ./community/heirloom-mailx/libressl.patch
> ./community/isync/libressl-compat.patch
> ./community/john/libressl.patch
> ./community/mongodb-tools/libressl.patch
> ./community/pgbouncer/libressl-2.5.patch
> ./community/qt5-qtbase/libressl-compat.patch
> ./community/retawq/libressl.patch
> ./community/rethinkdb/libressl-all.patch
> ./community/stunnel/stunnel-libressl.patch
> ./community/xchat/libressl.patch
> ./community/yadifa/libressl-compat.patch
> ./main/boost/libressl.patch
> ./main/elinks/libressl-2.5.patch
> ./main/fetchmail/libressl.patch
> ./main/freeswitch/sofia-sip-libressl.patch
> ./main/haproxy/fix-libressl-2.5.patch
> ./main/hexchat/libressl.patch
> ./main/hostapd/libressl-compat.patch
> ./main/krb5/libressl.patch
> ./main/ldns/1.6.17-libressl.patch
> ./main/libevent/libressl.patch
> ./main/libgit2/libressl.patch
> ./main/lua-cqueues/libressl-2.5.patch
> ./main/mosquitto/libressl.patch
> ./main/neon/fix-libressl.patch
> ./main/open-isns/libressl.patch
> ./main/openldap/libressl.patch
> ./main/opensmtpd/libressl-compat.patch
> ./main/openvswitch/libressl-compat.patch
> ./main/opusfile/libressl.patch
> ./main/partimage/libressl.patch
> ./main/perl-crypt-ssleay/libressl.patch
> ./main/postfix/libressl.patch
> ./main/python3/libressl.patch
> ./main/qt/qtcore-4.8.5-libressl.patch
> ./main/serf/libressl.patch
> ./main/spice-gtk/libressl.patch
> ./main/spice/libressl.patch
> ./main/strongswan/libressl.patch
> ./main/tlsdate/libressl-no-sslv3.patch
> ./main/tlsdate/libressl-sslstate.patch
> ./main/transmission/libressl.patch
> ./main/wpa_supplicant/libressl.patch
> ./main/xrdp/libressl-support.patch
> ./testing/bobcat/libressl-compatibility.patch
> ./testing/ejabberd/libressl.patch
> ./testing/imapfilter/libressl.patch
> ./testing/libimobiledevice/01-libressl.patch
> ./testing/litespeed/libressl.patch
> ./testing/megatools/libressl.patch
> ./testing/openconnect/openconnect-7.08-libressl251.patch
> ./testing/prayer/libressl.patch
> ./testing/proftpd/libressl.patch
> ./testing/tarantool/tests-libressl-compat.patch
> ./testing/x11vnc/libressl.patch
> 
> 
> It isn't just this.  Qt 5.10 introduces new dependency on OpenSSL 1.1
> APIs for improved security, and LibreSSL does not implement those APIs
> at all.
> 
> Also, as mentioned in my other email, one pain point is something like
> mailman or taiga, which require Python Cryptography package version 1.7.
>  This version requires OpenSSL APIs that LibreSSL removed.  That'd be
> fine, since it could be built against OpenSSL instead, however!
> libressl-dev and openssl-dev conflict, and python-dev installs
> libressl-dev because Python is built against LibreSSL.  That means you
> can't actually build OpenSSL-requiring Python packages at all.
> 
> I'd imagine similar issues would be had with Ruby, Perl, Node, and all
> the rest.  Certainly any Qt application that needs OpenSSL APIs (like
> Kleopatra, KDE's key management utility) won't be buildable as well.
> 
> One question I do have is: is there a way to disable the OpenSSL
> compatibility in LibreSSL?  It would be good for packages that require
> LibreSSL (libressl-dev) to be buildable even if openssl-dev is installed
> (preventing something like the above Python situation).
> 

Just in case some libressl dev doesn't want read the full thread in the
Alpine list, they want also a workaround for the lack of time_t for
32bits platforms on Linux.

FYI: Adelie is a downstream distro of Alpine which wants to support
"old" platforms. https://adelielinux.org/info.html#platforms


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: LibreSSL Linux portability and OpenBSD security

[A. Wilcox]

On 02/09/18 11:48, Stuart Henderson wrote:
> I don't understand that, Cryptography is OK with LibreSSL. There have
> been some problems at various times but they were either patched locally
> or fixed upstream - we're a couple of point releases behind the latest
> at the moment with no libressl-related patches - and I'd very surprised
> if latest upstream had problems at the moment.

cryptography 1.9 (2017-05-29) adds support for LibreSSL 2.5.x.  The
package in question requires <=1.8.2 due to API changes in 1.9.

You are correct that current versions of py-cryptography work correctly
with LibreSSL, and I was quoted out of context.  I specifically noted in
a different email that the problem was *older* versions of cryptography.
 It'd be much better if Taiga and Mailman3 would just upgrade their
requirements, but that would break systems where pyca isn't at the 2.x
API level yet, so they are hesitant to do so.

>> One question I do have is: is there a way to disable the OpenSSL
>> compatibility in LibreSSL?  It would be good for packages that require
>> LibreSSL (libressl-dev) to be buildable even if openssl-dev is installed
>> (preventing something like the above Python situation).
> 
> No, there wouldn't be anything left without the OpenSSL-compatible-ish
> code.
> 
> The big problem is if you have programs/libraries using OpenSSL
> they can't be linked with programs/libraries using LibreSSL.
> (Likewise, things using OpenSSL 1.0 can't be linked with things
> using 1.1). Many of the symbol names are the same so would conflict.

I was more asking if headers for libtls could be installed at the same
time as actual OpenSSL headers.  This would allow me to build and test
different backends (i.e., software that can use either OpenSSL 1.1 or
libtls from LibreSSL) without needing to switch to chroot.  But I see
now why this would be impossible, so thank you for clearing that up.

All the best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org



signature.asc
Description: OpenPGP digital signature

Re: LibreSSL Linux portability and OpenBSD security

[Allan Streib]

Kevin Chadwick  writes:

> I wish libressl could keep the 32 bit time_t workaround til linux
> kernel had fixed the problem instead of knowingly break things. Now I
> don't see we have much of an option since 32 bit linux is basically
> not supported by libressl at this point.

Contortions in the code to provide backwards support for various
obsolete platforms is part of what got OpenSSL into such a mess in the
first place.

Allan

Re: LibreSSL Linux portability and OpenBSD security

[Kevin Chadwick]

Thanks for the information Stu.

Unfortunately I am not sure it will help in the end.
Their project leader Natanael stated the following.



The fact that libressl developers are not willing to workaround 32 bit
linux time_t is the deal breaker for me. I am not happy to switch back
to openssl. I have been fairly happy with libressl and been willing to
sacrifice pretty much work for the extra security benefits libressl has
given, but the situation we are in now is that we have to choose
between:

- replace linux kernel with some other kernel
- do not support CAs with expiry date past year 2038
- drop 32 bit support
- replace libressl

I wish libressl could keep the 32 bit time_t workaround til linux
kernel had fixed the problem instead of knowingly break things. Now I
don't see we have much of an option since 32 bit linux is basically not
supported by libressl at this point.

Re: LibreSSL Linux portability and OpenBSD security

[Stuart Henderson]

On 2018-02-09, Kevin Chadwick  wrote:
> It isn't just this.  Qt 5.10 introduces new dependency on OpenSSL 1.1
> APIs for improved security, and LibreSSL does not implement those APIs
> at all.

btw I haven't looked at Qt but some ports are already held back in OpenBSD 
because it's just getting too painful to manage the changes they've made 
to support openssl 1.1 api...

> Also, as mentioned in my other email, one pain point is something like
> mailman or taiga, which require Python Cryptography package version 1.7.
>  This version requires OpenSSL APIs that LibreSSL removed.

I don't understand that, Cryptography is OK with LibreSSL. There have
been some problems at various times but they were either patched locally
or fixed upstream - we're a couple of point releases behind the latest
at the moment with no libressl-related patches - and I'd very surprised
if latest upstream had problems at the moment.

The problem in your other email is internal SSL functions in Python
(maintained by a redhat dev in Python core), not Cryptography
(https://cryptography.io/, maintained separately).

> One question I do have is: is there a way to disable the OpenSSL
> compatibility in LibreSSL?  It would be good for packages that require
> LibreSSL (libressl-dev) to be buildable even if openssl-dev is installed
> (preventing something like the above Python situation).

No, there wouldn't be anything left without the OpenSSL-compatible-ish
code.

The big problem is if you have programs/libraries using OpenSSL
they can't be linked with programs/libraries using LibreSSL.
(Likewise, things using OpenSSL 1.0 can't be linked with things
using 1.1). Many of the symbol names are the same so would conflict.