qubes-os.org SSL

[adrelanos]

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.

[7v5w7go9ub0o]

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. ...."

[Joanna Rutkowska]

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.

[adrelanos]

Joanna Rutkowska:

> 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.

I think that's how most websites do it. Unless they can afford own
buildings and security officers.

> 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.

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.

> 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).

Also the wiki is security sensitive. Someone could spoof "download this
version rather than ..." or malicious instructions.

[Joanna Rutkowska]

On 08/27/12 21:38, adrelanos wrote:
> Joanna Rutkowska:
>> > 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.
> I think that's how most websites do it. Unless they can afford own
> buildings and security officers.
>
>> > 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.
> 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.
>

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.

> Only a minority of people cares to verify fingerprints manually. How
> many depends on your target audience.
>
>> > 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).
> Also the wiki is security sensitive. Someone could spoof "download this
> version rather than ..." or malicious instructions.

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.

[Joanna Rutkowska]

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.

[Franz]

On Mon, Aug 27, 2012 at 4:38 PM, adrelanos <adre...@riseup.net> wrote:

Joanna Rutkowska:

> 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.

I think that's how most websites do it. Unless they can afford own
buildings and security officers.

> 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.

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.

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

[Joanna Rutkowska]

On 08/27/12 23:08, Franz wrote:
>
>
> On Mon, Aug 27, 2012 at 4:38 PM, adrelanos <adre...@riseup.net
> <mailto:adre...@riseup.net>> wrote:
>
> Joanna Rutkowska:
> > What is a problem (and the reason we still don't have SSL on

> > 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.

[Joanna Rutkowska]

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.

[Franz]

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

[Alex Dubois]

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