References: <20220803105631.77d1cc2c@ncopa-desktop.lan>
 <87iln2cxo3.fsf@ungleich.ch> <CM1BYFL1Z0CV.1N3D8RDVZGD68@sumire>
 <CM1CKNLBCLYI.24J4143ZN5GVQ@sumire> <87lerx7r2v.fsf@ungleich.ch>
 <CM1DK3ZAE2Y8.39QF72R3QZIXW@sumire>
User-agent: mu4e 1.7.27; emacs 28.1
From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: alice <alice@ayaya.dev>
Cc: Nico Schottelius <nico.schottelius@ungleich.ch>, Natanael Copa
 <ncopa@alpinelinux.org>, ~alpine/devel@lists.alpinelinux.org
Subject: Re: OpenSSL 3 pushed to git master
Date: Tue, 09 Aug 2022 11:22:37 +0200
In-reply-to: <CM1DK3ZAE2Y8.39QF72R3QZIXW@sumire>
Message-ID: <87k07h5wx1.fsf@ungleich.ch>
MIME-Version: 1.0
Content-Type: text/plain


Hey Alice,

"alice" <alice@ayaya.dev> writes:

> On Tue Aug 9, 2022 at 10:25 AM CEST, Nico Schottelius wrote:
>> I am using openconnect to connect to "highly secure" networks
>> that. Highly secure means: corporate managed, specific access and
>> traffic policies, 2FA. It however does not mean: up-to-date software or
>> Open Source Software. It's rather the opposite: these are proprietary,
>> closed source systems with upgrade cycles of "only if need be", usually
>> done if there is a CVE out there.
> certainly, i'm aware of the general background, and guessed as much :) i
> just don't think it's a good idea for other people to be affected by
> such things, and to keep 'openssl downgraded' or 'insecure defaults
> enabled' just because someone is connecting to some corporate service
> (which doesn't pay us for support)

You have a very good point here, if it only affects one user, then it's
not worth handling it. However, if there is not more coming up, it might
be sensible not to break a lot of users. In regards to the
openssl.cnf workaround, it seems not to work for me:

Using

--------------------------------------------------------------------------------
[openssl_init]
# providers = provider_sect  # commented out

# added
ssl_conf = ssl_sect

# added
[ssl_sect]
system_default = system_default_sect

# added
[system_default_sect]
Options = UnsafeLegacyRenegotiation

# List of providers to load
[provider_sect]
default = default_sect

--------------------------------------------------------------------------------

Running openconnect gives the same error:

--------------------------------------------------------------------------------
90F96C15467F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:
--------------------------------------------------------------------------------

Which makes sense, given that running openconnect does not load that
openssl configuration file:

--------------------------------------------------------------------------------
strace -f -e open -o opentrace  openconnect --protocol=gp ....

nb3:~# grep /etc opentrace
12508 open("/etc/ld-musl-x86_64.path", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
12508 open("/etc/hosts", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 6
12508 open("/etc/resolv.conf", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 6
12508 open("/etc/ssl/cert.pem", O_RDONLY|O_LARGEFILE) = 7
nb3:~# grep -c openssl.cnf opentrace
0

--------------------------------------------------------------------------------

I verified three times that the content is correct - is it possible that
not every app linked against openssl actually loads the configuration
file?

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch