help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam

[Ankur Sinha]

Hi folks,

Could someone with sufficient OpenSSL knowledge please take a look at
this post?

https://ask.fedoraproject.org/t/cannot-connect-to-eduroam-on-f36-due-to-o...

I'd managed to debug another one related to Eduroam and come up with a
workaround, but this is a new one that I'm not going to be able to
figure out any time soon:

https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-univers...

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Dmitry Belyavskiy]

Dear Ankur,

Your solution looks like not a workaround but a recommended solution.
You can find more information in Clemens Lang's blog post here:
https://www.redhat.com/en/blog/legacy-cryptography-fedora-36-and-red-hat-...
This blog post also contains links to two relevant bugs.

Hope this helps.

On Thu, Jun 30, 2022 at 9:59 AM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; wrote:

>  Hi folks,
>
>  Could someone with sufficient OpenSSL knowledge please take a look at
>  this post?
>
>
>
> https://ask.fedoraproject.org/t/cannot-connect-to-eduroam-on-f36-due-to-o...
>
>  I'd managed to debug another one related to Eduroam and come up with a
>  workaround, but this is a new one that I'm not going to be able to
>  figure out any time soon:
>
>
>
> https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-univers...
>
>  --
>  Thanks,
>  Regards,
>  Ankur Sinha "FranciscoD" (He / Him / His) |
>  https://fedoraproject.org/wiki/User:Ankursinha
>  Time zone: Europe/London
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  

-- 
Dmitry Belyavskiy

[Kevin Kofler]

Ankur Sinha wrote:
>  Could someone with sufficient OpenSSL knowledge please take a look
> at
>  this post?
>  
>
> https://ask.fedoraproject.org/t/cannot-connect-to-eduroam-on-f36-due-to-o...
>  
>  I'd managed to debug another one related to Eduroam and come up with a
>  workaround, but this is a new one that I'm not going to be able to
>  figure out any time soon:
>  
>
> https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-univers...
If the default crypto policies fail with the world's largest WiFi network, 
then surely they are too strict to be useful in practice and need to be 
relaxed.

        Kevin Kofler

[Matti Pulkkinen]

to, 2022-06-30 kello 11:54 +0200, Kevin Kofler via devel kirjoitti:
>  If the default crypto policies fail with the world's largest
> WiFi
>  network, 
>  then surely they are too strict to be useful in practice and need to
>  be 
>  relaxed.
>   
I'm not a developer but I just wanted to chime in here and mention that
while Eduroam is a very widespread network, different institutions can
configure it in different ways. I have had no difficulty connecting to
Eduroam in my home institution with F36.

-- 
Terveisin / Regards,
Matti Pulkkinen

[Clemens Lang]

Hi,

Kevin Kofler via devel <devel(a)lists.fedoraproject.org&gt; wrote:

>  If the default crypto policies fail with the world's largest WiFi
> network,
>  then surely they are too strict to be useful in practice and need to be
>  relaxed. 
It may be the world’s largest WiFi network, but authentication is delegated
to the various institutions. The TLS server that handles authentication is
probably run by this user’s university IT department, and their server does
not support modern TLS.

I hope you’re not suggesting we keep the defaults insecure because there are
some institutions out there that don’t support modern standards.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat

[Kevin Kofler]

Clemens Lang wrote:
>  I hope you’re not suggesting we keep the defaults insecure because
> there
>  are some institutions out there that don’t support modern standards. 
Sorry, but I am. The defaults need to work out there in the real world. If 
legacy standards are still widespread, they need to be supported out of the 
box, without having to jump through hoops. Users want to be able to connect 
to their WPA* WiFi networks, view their HTTPS websites, etc. They do not 
care whether those use the latest, most secure versions of the standard or 
not. (In fact, most users do not even care that encryption is used at all, 
they only use encryption at all because the other end forces them to, i.e., 
because the WiFi network requires it, or the website uses HTTP to HTTPS 
redirection and/or HSTS, etc.)

        Kevin Kofler

[Alexander Sosedkin]

Quoting Kevin Kofler via devel (2022-06-30 13:16:55)
>  Clemens Lang wrote:
>  > I hope you’re not suggesting we keep the defaults insecure because there
>  > are some institutions out there that don’t support modern standards.
>
>  Sorry, but I am.
>  The defaults need to work out there in the real world. 
Your model lacks the driver for deprecating anything for good,
in neither defaults nor the real world.

>  If legacy standards are still widespread,
>  they need to be supported out of the box, 
Yes.

>  without having to jump through hoops. 
No, or nothing ever moves on, squarely because

>  Users want to be able to connect to their WPA* WiFi networks,
>  view their HTTPS websites, etc.
>  They do not care whether those use the latest,
>  most secure versions of the standard or not.

[Kevin Kofler]

Alexander Sosedkin wrote:
> > without having to jump through hoops.
>  
>  No, or nothing ever moves on, squarely because
>  
> > Users want to be able to connect to their WPA* WiFi networks,
> > view their HTTPS websites, etc.
> > They do not care whether those use the latest,
> > most secure versions of the standard or not. 
You are making two doubtful assumptions:

1. That the users will bother reporting their issues to the server 
administrators at all. I would expect them to just blame Fedora for it and 
move to a different operating system that just works, or at most to apply a 
local workaround (what I called "jump through hoops", e.g., changing the 
system crypto policy to LEGACY and/or loading the legacy provider with its 
legacy algorithms into OpenSSL) and then forget about it.

2. That the server administrators will actually care about complaints from 
non-Windows users, assuming they even read user complaints at all to begin 
with, and that they will be willing to switch to newer (more secure) 
algorithms that may break compatibility with some ancient operating systems 
that other users might still use.

I do not believe that Fedora actually has any levy to get server 
administrators to upgrade their setups. We have to work with whatever 
obsolete junk is out there.

        Kevin Kofler

[Alexander Sosedkin]

Quoting Kevin Kofler via devel (2022-06-30 14:15:04)
>  You are making two doubtful assumptions:
>
>  1. That the users will bother reporting their issues to the server
>  administrators at all. I would expect them to just blame Fedora for it and
>  move to a different operating system that just works, or at most to apply a
>  local workaround (what I called "jump through hoops", e.g., changing the
>  system crypto policy to LEGACY and/or loading the legacy provider with its
>  legacy algorithms into OpenSSL) and then forget about it. 
>  2. That the server administrators will actually care about complaints
> from
>  non-Windows users, assuming they even read user complaints at all to begin
>  with, and that they will be willing to switch to newer (more secure)
>  algorithms that may break compatibility with some ancient operating systems
>  that other users might still use. 
I agree with your statements
but I do not make the assumptions you prescribe to me.
I'm painfully aware that progress doesn't happen magically
when we break something in Fedora.
Hoops are a horrible propellant of progress,
but still the best one we have.

>  I do not believe that Fedora actually has any levy to get server
>  administrators to upgrade their setups.
>  We have to work with whatever obsolete junk is out there. 
Is Fedora supposed to be a locomotive of secure defaults?
In an attempt to slow down devolving into opinion-vs-opinion,
let me back mine with https://docs.fedoraproject.org/en-US/project:

>  Four Foundations: First
>
>  We are committed to innovation.
>
>  We are not content to let others do all the heavy lifting on our behalf;
>  we provide the latest in stable and robust, useful,
>  and powerful free software in our Fedora distribution.
>
>  At any point in time, the latest Fedora platform
>  shows the future direction of the operating system
>  as it is experienced by everyone from the home desktop user
>  to the enterprise business customer.
>  Our rapid release cycle
>  is a major enabling factor in our ability to innovate.
>
>  We recognize that there is also a place for long-term stability in the
>  Linux ecosystem, and that there are a variety of community-oriented
>  and business-oriented Linux distributions available to serve that need.
>  However, the Fedora Project’s goal of advancing free software dictates
>  that the Fedora Project itself pursue a strategy
>  that preserves the forward momentum of our technical,
>  collateral, and community-building progress.
>  Fedora always aims to provide the future, first. 
In terms of cryptographic defaults, Fedora even lags behind RHEL,
so requests to slow down even further don't elicit much support from me.
If one day this page replaces "First" with, say,
"Compatibility: we have to work with whatever obsolete junk is out there,
security comes second", I will concede.
But today, I think the current pace of
deprecations *in the default configuration*
doesn't just align with Fedora's goals, it's slower than it should be.

Non-default configurations are a different beast altogether,
and the users' feet-shooting freedom is something we should defend, yes.
But the defaults have to march on unabated.

[Richard W.M. Jones]

On Thu, Jun 30, 2022 at 03:23:34PM +0000, Alexander Sosedkin wrote:
>  Quoting Kevin Kofler via devel (2022-06-30 14:15:04)
>  > You are making two doubtful assumptions:
>  >
>  > 1. That the users will bother reporting their issues to the server
>  > administrators at all. I would expect them to just blame Fedora for it and
>  > move to a different operating system that just works, or at most to apply a
>  > local workaround (what I called "jump through hoops", e.g., changing the
>  > system crypto policy to LEGACY and/or loading the legacy provider with its
>  > legacy algorithms into OpenSSL) and then forget about it.
>  
>  > 2. That the server administrators will actually care about complaints from
>  > non-Windows users, assuming they even read user complaints at all to begin
>  > with, and that they will be willing to switch to newer (more secure)
>  > algorithms that may break compatibility with some ancient operating systems
>  > that other users might still use.
>  
>  I agree with your statements
>  but I do not make the assumptions you prescribe to me.
>  I'm painfully aware that progress doesn't happen magically
>  when we break something in Fedora.
>  Hoops are a horrible propellant of progress,
>  but still the best one we have. 
Practically what would help is an easier way to reduce security for
only specific sites + protocols.  It's very easy right now to set the
whole system to LEGACY, and much harder to set legacy for a specific
site + protocol.  (In fact I have no idea how to go about it for this
particular case we're talking about.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

[Petr Pisar]

V Thu, Jun 30, 2022 at 10:46:27PM +0100, Richard W.M. Jones napsal(a):
>  Practically what would help is an easier way to reduce security for
>  only specific sites + protocols.  It's very easy right now to set the
>  whole system to LEGACY, and much harder to set legacy for a specific
>  site + protocol.  (In fact I have no idea how to go about it for this
>  particular case we're talking about.)
>   
Cryptopolicy would work as a soft limit. Cryptolibraries would return
a distinct error INSECURE instead of UNKNOWN. Applications on the INSECURE
error would offer a user to override the cryptopolicy soft limit.

At the end cryptolibraries many times keep implementing the weak algorithms
because the algorithms might be strong enough for a different purpose (like
a digest vs. an HMAC), or the cryptopolicy gives a different security level
to different purposes (creating vs. verifying a signature), or because the
user is not interested in the cryptographical guarantees at all, he only wants
to unwrap the wanted data (e.g. reading an ancient digitally-signed message).

For the first and the last case cryptolibraries already provide a mean for
applications to convey an intent for, or a use of the algorithm. It's
"only"
necessary to augment API of the libraries to support the intent parameter
everywhere.

Now cryptopeople will argue that users will learn to click "connect anyway"
all the time. Well, there will be users like that. But not everbody is like
that. I'd rather use a device which I can control than me to be controlled by
the device.

-- Petr

[Ankur Sinha]

Thanks Clemens for commenting on the Ask Fedora post. Hopefully that'll
help the user and others.

I understand the idea behind deprecating things---otherwise they never
improve---but I also note that while individual users may be pushed to
update etc., the same does not apply to institutions.

When I "solved" my issue, it took me about a while to figure out[1].
Then I gave IT all the info and received a "thank you, we'll look into
it when we upgrade our systems next". So, they'll have their own plans
and constrains, they are slow moving bodies, and we users can do very
little to force them to do pretty much anything. They're certainly not
going to align to Fedora community release cycles---they tend to be
Windows based institutions in general

So, as always, if a middle ground can be found, that's all we can strive
for. Once the new issue is solved on Ask Fedora, it'll hopefully become
another resource that users can easily find.

[1]
https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-univers...

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London