MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 09 Aug 2022 10:16:03 +0200
Message-Id: <CM1CKNLBCLYI.24J4143ZN5GVQ@sumire>
Cc: <~alpine/devel@lists.alpinelinux.org>
Subject: Re: OpenSSL 3 pushed to git master
From: "alice" <alice@ayaya.dev>
To: "alice" <alice@ayaya.dev>, "Nico Schottelius"
 <nico.schottelius@ungleich.ch>, "Natanael Copa" <ncopa@alpinelinux.org>
References: <20220803105631.77d1cc2c@ncopa-desktop.lan>
 <87iln2cxo3.fsf@ungleich.ch> <CM1BYFL1Z0CV.1N3D8RDVZGD68@sumire>
In-Reply-To: <CM1BYFL1Z0CV.1N3D8RDVZGD68@sumire>

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-hands=
hake-fails-with-unsafe-legacy-renegotiation-disabled?language=3Den_US
>
> a quick look via sslscan at the domain indicates it is using tls1.1 and
> tls1.2, and:=20
>
>  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/fc5888ccb60f33b366972299f30b976c4dc=
12162/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.