Hi!
I have pushed openssl3 to git master.
Majority of the main and community packages built fine in my x86_64 LXC.
I was able to build approx half of the testing packages as well, but
not all.
There might be some packages that needs fixes still and it might take
another day before community repo is done.
Sorry for the inconvenience.
-nc
Hey Nate,
is it possible that this upgrade broken openconnect?
Since an apk upgrade -a on edge I am facing this one:
--------------------------------------------------------------------------------
POST https://portal.somewhere.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to [....]:443
SSL negotiation with portal.techcorpapps.com
SSL connection failure
9069B3F2667F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:
Failed to open HTTPS connection to portal.techcorpapps.com
Failed to complete authentication
--------------------------------------------------------------------------------
Best,
Nico
Natanael Copa <ncopa@alpinelinux.org> writes:
> Hi!>> I have pushed openssl3 to git master.>> Majority of the main and community packages built fine in my x86_64 LXC.>> I was able to build approx half of the testing packages as well, but> not all.>> There might be some packages that needs fixes still and it might take> another day before community repo is done.>> Sorry for the inconvenience.>> -nc
--
Sustainable and modern Infrastructures by ungleich.ch
Hi Nico,
I had a similar issue with isync recently where it would compile fine
with OpenSSL 3 but ran into connection failures at run-time. I modified
the openconnect aport to use OpenSSL 1.1 for now. This should hopefully
fix your issue. If not, please open an issue in GitLab.
See: https://git.alpinelinux.org/aports/commit/?id=0141a80a906bc459670cd698dd452ee51a1b1f4a
Greetings,
Sören
Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
> > Hey Nate,> > is it possible that this upgrade broken openconnect?> > Since an apk upgrade -a on edge I am facing this one:> > --------------------------------------------------------------------------------> POST https://portal.somewhere.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux> Connected to [....]:443> SSL negotiation with portal.techcorpapps.com> SSL connection failure> 9069B3F2667F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:> Failed to open HTTPS connection to portal.techcorpapps.com> Failed to complete authentication> --------------------------------------------------------------------------------> > Best,> > Nico> > > Natanael Copa <ncopa@alpinelinux.org> writes:> > > Hi!> >> > I have pushed openssl3 to git master.> >> > Majority of the main and community packages built fine in my x86_64 LXC.> >> > I was able to build approx half of the testing packages as well, but> > not all.> >> > There might be some packages that needs fixes still and it might take> > another day before community repo is done.> >> > Sorry for the inconvenience.> >> > -nc> > > --> Sustainable and modern Infrastructures by ungleich.ch
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?)
> Since an apk upgrade -a on edge I am facing this one:>> --------------------------------------------------------------------------------> POST https://portal.somewhere.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux> Connected to [....]:443> SSL negotiation with portal.techcorpapps.com
fyi: you tried to hide the domain above but it's repeated here
> SSL connection failure> 9069B3F2667F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:> Failed to open HTTPS connection to portal.techcorpapps.com> Failed to complete authentication> -------------------------------------------------------------------------------->> Best,>> Nico>>> Natanael Copa <ncopa@alpinelinux.org> writes:>> > Hi!> >> > I have pushed openssl3 to git master.> >> > Majority of the main and community packages built fine in my x86_64 LXC.> >> > I was able to build approx half of the testing packages as well, but> > not all.> >> > There might be some packages that needs fixes still and it might take> > another day before community repo is done.> >> > Sorry for the inconvenience.> >> > -nc>>> --> Sustainable and modern Infrastructures by ungleich.ch
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.
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
Hey Sören,
thanks a lot for the quick fix. I have just upgraded to 9.01-r2 and it
indeed fixes the problem, much appreciated - I can get back to work!
Sunny greetings from Switzerland,
Nico
Sören Tempel <soeren@soeren-tempel.net> writes:
> Hi Nico,>> I had a similar issue with isync recently where it would compile fine> with OpenSSL 3 but ran into connection failures at run-time. I modified> the openconnect aport to use OpenSSL 1.1 for now. This should hopefully> fix your issue. If not, please open an issue in GitLab.>> See: https://git.alpinelinux.org/aports/commit/?id=0141a80a906bc459670cd698dd452ee51a1b1f4a>> Greetings,> Sören>> Nico Schottelius <nico.schottelius@ungleich.ch> wrote:>>>> Hey Nate,>>>> is it possible that this upgrade broken openconnect?>>>> Since an apk upgrade -a on edge I am facing this one:>>>> -------------------------------------------------------------------------------->> POST https://portal.somewhere.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux>> Connected to [....]:443>> SSL negotiation with portal.techcorpapps.com>> SSL connection failure>> 9069B3F2667F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:>> Failed to open HTTPS connection to portal.techcorpapps.com>> Failed to complete authentication>> -------------------------------------------------------------------------------->>>> Best,>>>> Nico>>>>>> Natanael Copa <ncopa@alpinelinux.org> writes:>>>> > Hi!>> >>> > I have pushed openssl3 to git master.>> >>> > Majority of the main and community packages built fine in my x86_64 LXC.>> >>> > I was able to build approx half of the testing packages as well, but>> > not all.>> >>> > There might be some packages that needs fixes still and it might take>> > another day before community repo is done.>> >>> > Sorry for the inconvenience.>> >>> > -nc>>>>>> -->> Sustainable and modern Infrastructures by ungleich.ch
--
Sustainable and modern Infrastructures by 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 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
On Tue Aug 9, 2022 at 10:34 AM CEST, Nico Schottelius wrote:
>> Hey Sören,>> thanks a lot for the quick fix. I have just upgraded to 9.01-r2 and it> indeed fixes the problem, much appreciated - I can get back to work!
note that the next upgrade to -r3 has this reverted again (back to
openssl3)- you would need to edit the openssl.cnf after that.
>> Sunny greetings from Switzerland,>> Nico>> Sören Tempel <soeren@soeren-tempel.net> writes:>> > Hi Nico,> >> > I had a similar issue with isync recently where it would compile fine> > with OpenSSL 3 but ran into connection failures at run-time. I modified> > the openconnect aport to use OpenSSL 1.1 for now. This should hopefully> > fix your issue. If not, please open an issue in GitLab.> >> > See: https://git.alpinelinux.org/aports/commit/?id=0141a80a906bc459670cd698dd452ee51a1b1f4a> >> > Greetings,> > Sören> >> > Nico Schottelius <nico.schottelius@ungleich.ch> wrote:> >>> >> Hey Nate,> >>> >> is it possible that this upgrade broken openconnect?> >>> >> Since an apk upgrade -a on edge I am facing this one:> >>> >> --------------------------------------------------------------------------------> >> POST https://portal.somewhere.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux> >> Connected to [....]:443> >> SSL negotiation with portal.techcorpapps.com> >> SSL connection failure> >> 9069B3F2667F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:ssl/statem/extensions.c:879:> >> Failed to open HTTPS connection to portal.techcorpapps.com> >> Failed to complete authentication> >> --------------------------------------------------------------------------------> >>> >> Best,> >>> >> Nico> >>> >>> >> Natanael Copa <ncopa@alpinelinux.org> writes:> >>> >> > Hi!> >> >> >> > I have pushed openssl3 to git master.> >> >> >> > Majority of the main and community packages built fine in my x86_64 LXC.> >> >> >> > I was able to build approx half of the testing packages as well, but> >> > not all.> >> >> >> > There might be some packages that needs fixes still and it might take> >> > another day before community repo is done.> >> >> >> > Sorry for the inconvenience.> >> >> >> > -nc> >>> >>> >> --> >> Sustainable and modern Infrastructures by ungleich.ch>>> --> Sustainable and modern Infrastructures by ungleich.ch
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
On Tue Aug 9, 2022 at 11:22 AM CEST, Nico Schottelius wrote:
>> 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:
you got me there; i actually only tested curl. my mistake.
>> 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?
seems some don't. i was naive..
however: `openconnect --allow-insecure-crypto` seems to work for me (no
more insecure renegotiation message).
>> Best regards,>> Nico>> --> Sustainable and modern Infrastructures by ungleich.ch
Hey Alice,
"alice" <alice@ayaya.dev> writes:
> On Tue Aug 9, 2022 at 11:22 AM CEST, Nico Schottelius wrote:>>>> I verified three times that the content is correct - is it possible that>> not every app linked against openssl actually loads the configuration>> file?> seems some don't. i was naive..
Same same ...
> however: `openconnect --allow-insecure-crypto` seems to work for me (no> more insecure renegotiation message).
... after suggesting apps should have that, the one app that fails does
actually have the i-am-sure-insecure-is-fine-with-me flag.
And as you said, it actually works.
Meanwhile, I have raised an issue with the VPN provider, but my
expectation is that it won't be fixed that soon.
Best regards,
Nico
--
Sustainable and modern Infrastructures by ungleich.ch