| qubes-os.org SSL | adrelanos | 27/08/12 06:53 | https://wiki.qubes-os.org/trac/ticket/203
Why not get a certificate for *.qubes-os.org and allow SSL on whole site? Perhaps not the downloads. Then we could use a nice https everywhere rule. Startssl.com also offers free certificates. You could see if their root certificate is in enough devices. They are inside modern browsers but maybe not in IE 6 or old mobile devices. |
| Re: [qubes-devel] qubes-os.org SSL | 7v5w7go9ub0o | 27/08/12 09:26 | If not present, one could import a copy from Startssl.
<http://www.startssl.com/?app=25#11> "....11.) After clicking on [Authenticate] I get a "Page not found" error with Internet Explorer. Either the client certificate is not installed into the browser you are using or the security settings prevent it. Make sure that either TLS 1.0 or SSL 3.0 is enabled (but not SSL 2.0). It may also be that on older systems the StartCom CA root is missing. We suggest to update your system via Windows Update or install the Update for Root Certificates. You can also import the CA root manually from here or from here. ...." |
| Re: [qubes-devel] qubes-os.org SSL | Joanna Rutkowska | 27/08/12 11:46 | The price of a certificate is generally not a problem.
What is a problem (and the reason we still don't have SSL on qubes-os.org) is that I _really_ don't like an idea of putting a private SSL key on the _untrusted_ web server. So far, we have managed to avoid the need to trust our servers thanks to use of digital signatures, on git, rpm packages, and ISOs. Now, I'm afraid that once we moved on toward an wholly-SSLed site, then nobody will bother anymore to e.g. verify ISO signatures, or to try to verify our signing keys in any other way (e.g. googling fingerprints on mailing lists, etc). And this is not good, because, again, we don't own our servers, and generally don't trust them for a number of reasons. So, I'm still thinking whether it's such a good idea to really have it, whether to have it for the whole *.qubes-os.org, or just the keys.qubes-os.org (and, so, still require to somehow manually and consciously verify the ISOs) and the wiki (which is not security sensitive). joanna. |
| Re: [qubes-devel] qubes-os.org SSL | adrelanos | 27/08/12 12:38 | Joanna Rutkowska:
> What is a problem (and the reason we still don't have SSL onI think that's how most websites do it. Unless they can afford own buildings and security officers. Ironically, you will have much more healthy users, if you have SSL everywhere. It does not protect against malicious server but it's useful in hotspots, behind proxy servers, etc. Only a minority of people cares to verify fingerprints manually. How many depends on your target audience. Also the wiki is security sensitive. Someone could spoof "download this version rather than ..." or malicious instructions. |
| On Server security (waas: Re: [qubes-devel] qubes-os.org SSL) | Joanna Rutkowska | 27/08/12 12:58 | On 08/27/12 21:38, adrelanos wrote:The point is that one doesn't download an ISO with a new OS to install every day, and when one does it, I think it's not unreasonable to expect that this person will invest some 15 minutes of Internet research to validate signature and the fingerprints... Again, ISO download is the only thing that requires this. Updates are automatically verified already, and SSL cert is not needed for this. Well, for this kind of "attack" there is really no workaround. We could buy the most expensive EV certs for qubes-os.org, spend a good deal of time hardening all our services, such as wiki, etc, and still somebody might register qubes.org or qube-os.org that would look similar and distribute some malware from there. (Actually qubes.org is already registered by someone, as is the qube-os.org ;) So, no, wiki is not security sensitive, as none of our servers is. When one day somebody vandalizes our wiki server (or git, or web) we would only be angry that we might have lost up to a few days of unbackuped tickets/wiki edits. I said vandalized, because other types of compromises of our wiki or web servers would be... rather irrelevant for us, as there is really no sensitive data to steal from those public servers. The only problem might be the CPU time/network bandwith rip off (e.g. if they used our servers as part of a botnet), but I have hope in networking skills of the AWS security team to block such incidents on time (or, at least, to not charge ITL for such bandwidth use!) I guess the message I'm trying to convey now is: server security is so 90's! ;) As usual, there are exceptions to this rule, but not for an open source project like Qubes OS. joanna. |
| Re: On Server security (waas: Re: [qubes-devel] qubes-os.org SSL) | Joanna Rutkowska | 27/08/12 13:06 | To finish the thought: As I already wrote somewhere once, I believe that
people trust _servers_ way too often and way too much, and this is a mistake. We should look for methods/technologies to minimize the amount of external computer systems we trust. iCloud, Google services, etc, are all well known examples, as are things such as Fedora build servers (which we trust in Qubes OS, but which I'd rather not in the future). joanna. |
| Re: [qubes-devel] qubes-os.org SSL | Francesco | 27/08/12 14:08 | Well, I do not know others, but since the beginning, that is beta1, I never tried to verify fingerprints, just because it appeared too much complicated and requiring time to study it and have little time available. I estimated the risk was low enough form me to take it. I estimated Qubes was little known enough to be out of the radars of hackers. Also supposed there are lots of super-expert people on this forum who will alert if something wrong is happening with Qubes. I may be wrong of course, but live with risk and am used to accept a certain level of it. Best Franz |
| Re: [qubes-devel] qubes-os.org SSL | Joanna Rutkowska | 27/08/12 14:20 | On 08/27/12 23:08, Franz wrote: > <mailto:adre...@riseup.net>> wrote:> > qubes-os.org <http://qubes-os.org>) is that I _really_ don't like This is a wrong thinking -- Qubes might be perfectly ok, yet somebody might have compromised your home router and infecting whatever ISO you're downloading on the fly. Or somebody might have compromised Amazon S3 server from where we serve the ISO and over which we have absolutely no control. Or perhaps NSA might have come to Amazon and asked to compromise Qubes OS ISO -- after all it's expected that Qubes might be used by people who _really_ value security and privacy, so a good target perhaps. We, the Qubes OS project, only take responsibility for the code we signed, no more, no less. joanna. |
| Re: [qubes-devel] qubes-os.org SSL | Joanna Rutkowska | 27/08/12 15:18 | And then again, as we serve the ISO from Amazon S3 anyway, the only
potential gain if we started using SSL for *.qubes-os.org would be that... you would get a somehow more convenient way to download and verify our keys(*), which, however, you decided to ignore anyway... On a side note, I found it rather surprising that you, apparently, decided to spend a few hours installing and playing with Qubes OS, yet you didn't want to invest another 5-10 minutes on downloading and verifying the keys, and 3 secs on actually verifying the downloaded ISO...? (*) A more convenient way, yet not necessarily more secure, because, again, the SSL private key would be on the untrusted server, and so somebody having access to the server (Amazon, NSA, a smart hacker, etc) might use it to _selectively_ present false keys for select users (to whom they might also present compromised ISOs). Ok, ok, I admit, such an attack would be difficult to conduct in practice, and potentially easy to disclose if somebody bothered to verify the keys via 3rd party source, such as e.g. the mailing list (**), or download it from a key server. But then again, if there are such reasonable ways to verify the keys, why bother to use SSL cert for keys.qubes-os.org? Or, a Another potential attack would be the already mentioned registration of a similarly looking domain name -- again the cert doesn't solve this. (**) E.g. (and this is actually HTTPSed this time!): https://groups.google.com/d/msg/qubes-devel/RqR9WPxICwg/kaQwknZPDHkJ joanna. |
| Re: [qubes-devel] qubes-os.org SSL | Francesco | 28/08/12 17:44 | You are certainly perfectly right Joanna no doubt about that. But not everybody using Qubes is a top level expert. Quite the contrary. If you plan to make any money out of it selling to lawyers, investors and general professionals, they are very busy people with very little time for computer problems and generally much less expert than I am. Well up to date I was unable to prepare a working USB Qubes installer within Qubes or even with the help of other OSs. Also I was unable to burn a DVD within Qubes beta2 to prepare the DVD installer of rc1. So i had to burn the DVD with a standard Ubuntu that might be security compromised. So it seems fingerprints verification is high-level, when I lack even the basic. A very simple solution would be you to sell nice small Usb installers of the final version Release 1 for perhaps $99, explaining the security risks involved downloading and installing it without all perfect security details . You may even write that you will prepare them only after there is a real request. I would be very glad to buy one Joanna. Perhaps this is premature and there will not be enough request to make it meaningful, but in the future it will be also a way to begin open a little channel to support the project. The usb installer may also include some exclusive little gadget program or something not normally included in the standard download. Best Franz |
| Re: [qubes-devel] qubes-os.org SSL | Alex Dubois | 30/08/12 13:07 | Https is useful to protect an http session. As here http is only used as distribution, I see Johanna point also as you I was surprised. After reflection it seems the right decision for key and download site. There is however a lot of info on this web server that is certainly public but where some level of integrity would be good and ssl would be a reasonable fit (rather than signing every page or document). Alx |