Hacker News new | past | comments | ask | show | jobs | submit login

> it uses was broken only once, and it was done by the Qubes founder

Well, not quite:

> "XSA-213 is a fatal, reliably exploitable bug in Xen," said the security team of Qubes OS, an operating system that isolates applications inside Xen virtual machines. "In the nearly eight-year history of the Qubes OS project, we have become aware of four bugs of this calibre: XSA-148, XSA-182, XSA-212 and now XSA-213."

https://www.csoonline.com/article/3193718/xen-hypervisor-fac...

> Qubes keys are signed by the master key which belongs to the main developers.

Right, and that master key is signed by nothing. There is no way provided to verify it.




> https://www.csoonline.com/article/3193718/xen-hypervisor-fac...

> May 3, 2017

I said Qubes 4+, which was released in 2018: https://www.qubes-os.org/news/2018/03/28/qubes-40/. All previous versions relied on software virtualization (and had much wider compatible hardware).

> Right, and that master key is signed by nothing. There is no way provided to verify it.

Sorry for my ignorance, how does one securely verify a master key not risking to compromise it?


Those with knowledge of what the master key is sign the master key, those with knowledge of those people and their keys sign those keys, and so on and so on until you have signed one of the keys in the set. Aka, "the web of trust".


The Qubes Master Signing Key is kept on air-gapped machine accessible only to the developers. It signs their keys and the fact that they are signed by it is already the evidence of its validity. It's set to never expire and so it is extremely sensitive. I don't see how you can make it better in terms of security.

https://www.qubes-os.org/security/verifying-signatures/#1-ge...


By making it so that people can securely receive it.

If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc.

Armed with a valid SSL cert, they MITM traffic. When a target downloads qubes they give them a tampered version, when a target downloads the master key, they give them a lookalike key.

The user can happily verify the tampered qubes with the lookalike key.

PGP proves nothing if you cannot verify that you have an authentic copy of the key.

Qubes gives some handwavy suggestions at how to check the key which do not work.

The first item "Use the PGP Web of Trust." cannot be done because the key isn't signed by anyone. The other suggestions are inapplicable or won't achieve anything if the target's network is being tampered with.

This is not some newfangled problem. PGP has the ability to sign keys for precisely this reason. The main Qubes developers should have personal PGP keys which they use to sign the master key. Their personal keys should be certified by other FOSS developers that they've met (maybe the master key too). Then people who are interested in obtaining high confidence in the key can inspect the chain from their own key to the qubes masterkey.

Obviously not everyone will perform careful validation, but if some do then substituting the key becomes riskier. Unfortunately not only is the key not verifiable at the moment, but the current situation is looks pretty similar to what an ongoing key replacement attack would look like.


Thank you for the interesting thoughts.

> If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc.

The malicious party would have to compromise a lot of websites for that: https://www.qubes-os.org/faq/#should-i-trust-this-website.

Apart from that, let's see what the developers will reply: https://qubes-os.discourse.group/t/there-is-no-way-to-valida....


Signatures should go from the devs keys to the master key, not the other way around.


There is no such requirement anywhere. You can check the key by other means: https://qubes-os.discourse.group/t/there-is-no-way-to-valida...


Any other method of verification makes zero sense, it is bizarre the Qubes folks would think otherwise.


Beyond being bizarre, it makes it look compromised.

(I'm not suggesting that it is-- it's just an extremely bad failure mode when you undermine your users ability to detect key substitution attacks by always looking like a key substitution is in progress).

Then again, it's not just them. OpenSSL did this previously too-- replaced their key and the only source for the new key was the same https site as the software, and the key was signed by nothing and it stayed this way for a month.

During which time most Linux distributions shipped the new update, which presumably means that they're not doing due diligence either. OpenSSL promptly fixed it after I reported that I couldn't validate their key.

Fedora itself now has a nearly non-verifyable key, unlike qubes they don't even have a master key that signs their release keys or sign new release keys with old ones. Presumably Qubes picked up their bad practices from Fedora.

It used to be that various developers at redhat would sign the fedora keys and post the signatures to the keyservers, but the DOS attacks on keyservers mean they can't do this anymore.


Can you please be more specific? How does it make Qubes look compromised? The Qubes website is absolutely not the only place to get the Master Key. See the discussion linked above: You can get the key from t-shirts, from qubes-os.org website, from Github, from the Qubes Discourse forum and other places. You can also find this key signed by different people.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: