References: <20220803105631.77d1cc2c@ncopa-desktop.lan>
 <87iln2cxo3.fsf@ungleich.ch> <CM1BYFL1Z0CV.1N3D8RDVZGD68@sumire>
 <CM1CKNLBCLYI.24J4143ZN5GVQ@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 10:25:27 +0200
In-reply-to: <CM1CKNLBCLYI.24J4143ZN5GVQ@sumire>
Message-ID: <87lerx7r2v.fsf@ungleich.ch>
MIME-Version: 1.0
Content-Type: text/plain


Hey Alice,

thanks for investigating and maybe a bit background from my side to put
the issue into context:

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.

So in a nutshell, it is almost impossible to change the systems within a
reasonable amount of time. My best estimate would be that after raising
that ticket, it would require about 6-12 months to take effect, in case
the request is accepted. Why in case? Because majority of the staff is
using the proprietary, closed source binaries instead, which for the
glibc dependency, don't work on Alpine.

That said, I see the advantage of openssl3's RFC5746 requirement and in
an optimal world, applications such as openconnect would have a flag
like --allow-insecure-tls to trigger the acceptance of "insecure modes",
whatever that means at a point in time.

Thanks again for the quick research and I'll keep you updated.

Best regards,

Nico

"alice" <alice@ayaya.dev> writes:

> On Tue Aug 9, 2022 at 9:47 AM CEST, alice wrote:
>> On Mon Aug 8, 2022 at 9:59 PM CEST, Nico Schottelius wrote:
>> >
>> > Hey Nate,
>> >
>> > is it possible that this upgrade broken openconnect?
>>
>> the actual issue is that openssl3 does not allow insecure renegotiation.
>> see, for instance:
>> https://www.ibm.com/mysupport/s/question/0D50z000062ktWGCAY/why-ssl-handshake-fails-with-unsafe-legacy-renegotiation-disabled?language=en_US
>>
>> a quick look via sslscan at the domain indicates it is using tls1.1 and
>> tls1.2, and:
>>
>>  TLS Fallback SCSV:
>>  Server does not support TLS Fallback SCSV
>>
>>  TLS renegotiation:
>>  Session renegotiation not supported
>>
>>  Supported Server Cipher(s):
>>   Preferred TLSv1.2  112 bits  TLS_RSA_WITH_3DES_EDE_CBC_SHA
>>   Preferred TLSv1.1  112 bits  TLS_RSA_WITH_3DES_EDE_CBC_SHA
>>
>> i assume based on that it just has a quite old (to me, ancient) tls
>> stack, and openssl3 does not work with it. but this is (sadly) more of
>> an issue in the website than in openssl3. nevertheless, openssl1.1 does
>> allow this, so it works with 1.1..
>>
>> (offtopic: is 3des even secure anymore?)
>
> investigated a bit more: yes, openssl3 requires RFC5746 support.
>
> relevant documents:
> https://github.com/openssl/openssl/blob/fc5888ccb60f33b366972299f30b976c4dc12162/doc/man7/migration_guide.pod
>
> quote:
>
>  Secure renegotiation is now required by default for TLS connections
>   Support for RFC 5746 secure renegotiation is now required by default for
>   SSL or TLS connections to succeed. Applications that require the ability
>   to connect to legacy peers will need to explicitly set
>   SSL_OP_LEGACY_SERVER_CONNECT. Accordingly, SSL_OP_LEGACY_SERVER_CONNECT
>   is no longer set as part of SSL_OP_ALL.
>
>
> https://datatracker.ietf.org/doc/rfc5746/
>
> given that, i think you should request the owner of the website to
> update their hosting/server/etc, and we should swap openconnect back
> to openssl3, as it's not actually an openssl issue here.
>
> it also looks like openconnect could set SSL_OP_LEGACY_SERVER_CONNECT to
> bypass these checks, but that would have to be done upstream.
>
> they have also heard of it upstream, see:
> https://gitlab.com/openconnect/openconnect/-/issues/451
>
> and then the linked thread on fedora:
> https://ask.fedoraproject.org/t/openconnect-vpn-does-not-work-on-f36/22635/3
>
> where someone links to a github issue for a api client:
> https://github.com/Kong/insomnia/issues/4543
>
> where someone details a workaround by editing openssl.cnf:
> https://github.com/Kong/insomnia/issues/4543#issuecomment-1126771807
>
> that workaround lets you disable these checks yourself (insecure). for
> us, the file is in /etc/ssl/openssl.cnf , and i verified the workaround
> works. but i really don't recommend doing any of that, and getting the
> owner of the server to support non-ancient protocols instead.


--
Sustainable and modern Infrastructures by ungleich.ch