Summary: | spice-gtk / remote-viewer SSL verification behavior | ||
---|---|---|---|
Product: | Spice | Reporter: | Christophe Fergeau <teuf> |
Component: | spice-gtk | Assignee: | Spice Bug List <spice-bugs> |
Status: | RESOLVED MOVED | QA Contact: | |
Severity: | major | ||
Priority: | high | CC: | f.gruenbichler, teuf |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Christophe Fergeau
2016-02-09 13:57:55 UTC
I think we have 2 options here, 1) either just accept the intermediate CA as valid and do not fail if the only issue is that its "end" CA cert is invalid 2) or when the "end" CA cert is invalid, look up in the system truststore and see if this makes the whole chain valid. In order to match existing behaviour when the passed-in CA goes down to the root chain, we have to validate the certificate presented by the server using only the intermediate CA, and if all goes well, finish the validation using the system truststore. 1) is probably easier, and more consistent with what is currently done. I suspect 2) is slightly more correct, but could be wrong. Original reporter here. For our use case, either 1 or 2 is probably fine, but I would prefer version 1 because there are no (potentially failing) dependencies on the user's or OS trust store. Version 2 seems to be stricter, but IMHO only limits the possible valid configurations without any security benefit. If an attacker is able to modify the configuration file and changes the ca parameter (e.g., for MITM purposes), they can currently already include their root certificate and pass all checks. If the attacker cannot change the configuration file, I see no reason to require an explicit pinning of the root in addition to the intermediate certificate. OTOH, I might have missed a different setup where this distinction is relevant. Requiring a trusted root certificate if there is no ca(-file) parameter seems reasonable. Please go for option 1. I have been waiting for getting spice working on proxmox again since 2016. (In reply to Asger Stig Holten from comment #3) > Please go for option 1. I have been waiting for getting spice working on > proxmox again since 2016. we worked around this Spice issue by splitting the certificates used for the web interface and those used for Spice. if Spice is not working for you on PVE, please open a thread on the PVE support forum. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org'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.freedesktop.org/spice/spice-gtk/issues/30. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.