Bug 401611 - [RFE] [Openconnect] CA certificate is not ensured for openconnect VPNs
Summary: [RFE] [Openconnect] CA certificate is not ensured for openconnect VPNs
Status: REPORTED
Alias: None
Product: plasma-nm
Classification: Plasma
Component: applet (show other bugs)
Version: 5.13.5
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Jan Grulich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-01 17:21 UTC by Oliver Freyermuth
Modified: 2020-11-20 02:27 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Freyermuth 2018-12-01 17:21:30 UTC
SUMMARY
My VPN provider recently changed their certificate and I got no alert at all. 
I have configured a CA certificate in the plasma-nm applet, and it is passed to openconnect. 
However, since "--no-system-trust" is not passed, openconnect trusts *any* certificate ignoring that. So any user hijacking a trusted CA can present a certificate and the client is not alerting the user. There's also no alert for a certificate change. 

STEPS TO REPRODUCE
1. Create a new openconnect VPN connection and specify a CA file not matching the VPN's CA. 
2. Have the VPN's CA be trusted by the system. 
3. Connect. 

OBSERVED RESULT
No alert. 

EXPECTED RESULT
Be alerted if the CA is changed / does not match what is specified explicitly as CA certificate. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: kernel 4.18.3 / 5.13.5
KDE Frameworks Version: 5.50.0
Qt Version: 5.11.1

ADDITIONAL INFORMATION
A solution would be to pass:
--no-system-trust
to openconnect if a CA certificate is specified. 
Alternatively, to expose that flag via a checkbox which is by default checked if a CA certificate is provided.
Comment 1 Oliver Freyermuth 2018-12-01 17:29:43 UTC
I've also reported this against NetworkManager itself:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/87
since that setting seems not to be exposed, so plasma-nm can not pick it up (yet).
Comment 2 Justin Zobel 2020-11-19 22:23:31 UTC
(In reply to o.freyermuth from comment #1)
> I've also reported this against NetworkManager itself:
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/87
> since that setting seems not to be exposed, so plasma-nm can not pick it up
> (yet).

Now that https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/87 has been fixed is this issue still relevant?

Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I'm setting status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.
Comment 3 Oliver Freyermuth 2020-11-20 02:27:27 UTC
> Now that https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/87 has been fixed is this issue still relevant?

The linked issue is not fixed, it only has been closed. If you check the two comments on it, you'll find it has been redirected by upstream to yet another bug tracker, and the actual new upstream issue is this one:
https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/14

This one has seen zero activity by upstream developers in the past year (but already got an upvote, likely by another affected user), and the issue is still present.