After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678644 - self-signed https certificate handling
self-signed https certificate handling
Status: RESOLVED OBSOLETE
Product: gnome-boxes
Classification: Applications
Component: ovirt
unspecified
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks: 696727
 
 
Reported: 2012-06-22 17:27 UTC by Christophe Fergeau
Modified: 2018-01-11 09:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christophe Fergeau 2012-06-22 17:27:27 UTC
I've been working on code which makes https connections to a remote broker (ovirt). It's not unusual that this remote broker uses a self signed certificate. Such a certificate does not give us any guarantee about the identity of the remote server, the self signed certificate might have been self signed by an attacker who is trying to run a man-in-the-middle attack.
Warning the user about this and trying to get him not to connect to the remote server is not user-friendly at all, witness the firefox dialog for this situation.

So no idea what we should do here, design input would be great!
Comment 1 Zeeshan Ali 2014-10-15 00:01:01 UTC
I'm very sure designers would say we shouldn't do this but this opinion is shared by security experts like Stef Walter. He presented a very nice talk at GUADEC 2013 where he explained with good examples why user should not be given this decision.

Having said that, I recall Stef told me that Firefox's dialog would be OK if it wasn't letting user save the certificate permanently. I'll point Stef at this bug to get his opinion.
Comment 2 Stef Walter 2014-10-15 02:27:50 UTC
On my phone ... If the remote cert is.self.signed you should display it in the dialog that is configuring the new connection. The information that the user has.selrcted a specific cert should be part of the connection info alozng with things like host namep and port. If the cert later changes, the connection should fail and not.be uncermoniously prompted in the course of other tasks.
Comment 3 Christophe Fergeau 2014-10-23 08:09:42 UTC
I don't think this is ovirt specific, this could probably happen with qemu+tls:// connections too (though this is probably not handled at all at the moment).
Comment 4 Zeeshan Ali 2014-10-23 12:02:44 UTC
(In reply to comment #3)
> I don't think this is ovirt specific, this could probably happen with
> qemu+tls:// connections too (though this is probably not handled at all at the
> moment).

Thats true, even if it was supported I don't think qemu+tls is a very usual usecase. Since we are thinking about moving handling of brokers to GOA, I wonder if GOA already handles this?
Comment 5 GNOME Infrastructure Team 2018-01-11 09:53:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/8.