MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 09 Aug 2022 11:02:22 +0200
Message-Id: <CM1DK3ZAE2Y8.39QF72R3QZIXW@sumire>
Subject: Re: OpenSSL 3 pushed to git master
From: "alice" <alice@ayaya.dev>
To: "Nico Schottelius" <nico.schottelius@ungleich.ch>
Cc: "Natanael Copa" <ncopa@alpinelinux.org>,
 <~alpine/devel@lists.alpinelinux.org>
References: <20220803105631.77d1cc2c@ncopa-desktop.lan>
 <87iln2cxo3.fsf@ungleich.ch> <CM1BYFL1Z0CV.1N3D8RDVZGD68@sumire>
 <CM1CKNLBCLYI.24J4143ZN5GVQ@sumire> <87lerx7r2v.fsf@ungleich.ch>
In-Reply-To: <87lerx7r2v.fsf@ungleich.ch>

On Tue Aug 9, 2022 at 10:25 AM CEST, Nico Schottelius wrote:
>
> 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.
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)

>
> 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.
yeah, i agree. that would have to be added into openconnect in some
fashion, so someone should query it upstream. (seems simple, a flag to
add SSL_OP_LEGACY_SERVER_CONNECT into whatever uses it)

also note that workaround from the github issue does work- if you feel
like editing the system openssl.cnf, that allows you to connect (i
double checked). note it has a lot of lines to edit (took me a few tries
to see them all).

>
> 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 renegotiatio=
n.
> >> see, for instance:
> >> https://www.ibm.com/mysupport/s/question/0D50z000062ktWGCAY/why-ssl-ha=
ndshake-fails-with-unsafe-legacy-renegotiation-disabled?language=3Den_US
> >>
> >> a quick look via sslscan at the domain indicates it is using tls1.1 an=
d
> >> 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 doe=
s
> >> 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/fc5888ccb60f33b366972299f30b976=
c4dc12162/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 abil=
ity
> >   to connect to legacy peers will need to explicitly set
> >   SSL_OP_LEGACY_SERVER_CONNECT. Accordingly, SSL_OP_LEGACY_SERVER_CONNE=
CT
> >   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 t=
o
> > 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/22=
635/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