search

openconnect / openconnect-gui

MOVED TO https://gitlab.com/openconnect/openconnect-gui
https://gitlab.com/openconnect/openconnect-gui
GNU General Public License v2.0
1.29k stars 239 forks source link

Add Strict Certificate Match #134

Open xamor opened 8 years ago

xamor commented 8 years ago

The OpenConnect Client allows connection to untrusted servers (e.g. certificate missmatch) there should be an option to block these connections like in the original anyconnect client (Remove the "connect anyway"-Button and disconnect). The button should be disabled by default and can be enabled manually in the configuration if needed.

horar commented 8 years ago

Original openconnect-gui client allow user to connect to insecure servers, but user is warned! about it. This can be implemented, but with improved warning message (#135) is something like 'nice to have'

horar commented 8 years ago

(sorry, wrong button)

nmav commented 8 years ago

What is the reason of this feature? What is the functionality or security advantages of this approach? The fact that anyconnect client has it, is not very compelling (to me at least).

xamor commented 8 years ago

You can ensure users will only connect to your servers and prevent them from connecting to malicious servers. In bigger organisations (like universities) most of the users will just click connect anyway if an error occurs and will not read the error message or they are not be able to understand the message. (We opened this issue on the gnome bugzilla as well).

xamor commented 8 years ago

https://bugzilla.gnome.org/show_bug.cgi?id=770880#c1

nmav commented 8 years ago

That could be if openconnect-gui was relying on PKIX. However openconnect is primarily trust on first use and PKIX is only used as fallback.

nmav commented 8 years ago

To add more to that. In VPN space, there is very little PKIX (i.e., the trusted CA list browsers and OS' bring) can do. On most servers you don't want to trust obscure companies in various places around the world to certify your server. It is way more secure to provide the fingerprint of the server to your users, or your CA certificate, rather than going via PKIX.

xamor commented 8 years ago

I agree to you, the best case is to create a private CA for VPN. But in the reality i think a lot of bigger organizations are using Certificates signed by a public CA for example most of the universities in germany are using Certificates signed by Deutsche Telekom Root CA 2

xamor commented 8 years ago

If i get your "okay" i can implement it and create a pull request.

nmav commented 8 years ago

So if I understand correctly, your proposal is to offer the choice to switch from "TOFU + PKIX" to "PKIX only". If Lubomir agrees too, I wouldn't object to an optional switch in advanced settings or so. One thing to spend some time thinking is how to offer this to an end-user as an option that can be understood (TOFU + PKIX is something we can understand but would mean nothing to typical VPN users).

xamor commented 8 years ago

Maybe the best option would be, to implement a PKIX only option and provide the posibility to modify the installer for PKIX only option. I don't know how this could be done on NSIS installers, for MSI installer you can use Orca to modify the installer in this way. So the enduser has no choice, and the distributor can provide a PKIX only version.

horar commented 7 years ago

yes, we can implement this as optional feature. The question is, if you want tweak one of:

My personal preference will be 3rd solutions (I'm just playing with Docker containers for building the app), what may allow with new cmake switches customize this feature or possible other e.g. about etc.

xamor commented 7 years ago

I think on binary level would be a good solution. So Organizations are able to compile and deliver their own PKIX Only version.