HTTPS for qubes-os.org?

[Micah Lee]

I think qubes-os.org should use HTTPS, and with all the best practices
too: HTTP should redirect to HTTPS, perfect forward secrecy, good
ciphersuites, set the HSTS header. It's easy-ish to configure and takes
minimal work to maintain.

Additionally, I also think it would be great if the iso files could also
be downloaded over HTTPS.

There's prominent instructions on how to verify digital signatures [1]
linked from the download page, but even so I think if Qubes catches on
and gets a much larger user base, most users won't actually do this
step. It's likely that most users already skip this step.

Also, the verification instructions are also served over HTTP. An active
attacker could change the fingerprints on that page to malicious ones,
and there's no way to detect this. Users need to actually view mailing
list archives (that are linked from there) to see the fingerprints over
HTTPS (on Google's servers).

Additionally, if the potential user is using, say, Windows, and they're
trying to securely get a copy of the Qubes iso (and by extension a copy
of gnupg from gpg4win.com, which also doesn't support HTTPS) so that
they can verify the signature, good luck [2].

HTTPS obviously has many problems (and shouldn't replace publishing
sigs), like trusting an untrustworthy bucket of certificate authorities,
but it's much better than no security at all, and it makes attacks
significantly more expensive and difficult to pull off, and out of reach
of many attackers.

All the cool kids force HTTPS for their security software :). [3,4,5]

[1] http://qubes-os.org/trac/wiki/VerifyingSignatures
[2]
http://noncombatant.org/2014/03/03/downloading-software-safely-is-nearly-impossible/
[3] https://www.torproject.org/
[4] https://tails.boum.org/
[5] https://pressfreedomfoundation.org/securedrop

--
Micah Lee

[Joanna Rutkowska]

There are several major problems with using HTTPS for qubes-os.org and
iso download:

1) HTTPS/SSL Public CA trust infrastructure is far from ideal so to
say... There are way too many well known CAs that each browser trusts by
default, and it is expected that an attacker would be able to relatively
easy get/steal a signed cert from one of those many "trusted" CAs. As we
all known that happened many times in the past.

2) But, even if #1 was not a problem: we still don't (want to) trust our
cloud operator (and the cert private key must be on the server, and the
operator can always, at the very least, sniff our servers memory without
leaving any traces). This specifically considers a government-backed
attackers.

3) And even if #1 and #2 were not problems: we don't want to host ISO
images on our own (hosted) sever(s) because of high bandwith costs, and
that is why we use sf.net to distribute ISOs.

So, I'm concerned that HTTPS might only offer an illusion of trust,
surely much less than digital signatures we use could offer [*]. Having
that said, I just recently re-opened a ticket [1] to get cert for the
wiki server. But as the ticket says this is mostly for "aesthetic
reasons" and would not apply to ISO download (yet fingerprints will be
listed on a HTTPS wiki site -- again, still not sure if this a good or
bad idea...)

Curious to hear your thoughts on addressing the above mentioned
problems, specifically by "all the cool kids" you mentioned? :)

joanna.

[*] Currently the biggest hole in trust chain for Qubes OS are all the
packages we get from Fedora (and a few other software we download "in
raw" format such as e.g. kernel and xen). However all this is digitally
signed [**] so at least we could always pinpoint where the breach came from.

[**] Not actually true. A few sources for KDE is not digitally signed,
because the KDE project doesn't understand why signing is good, as well
as some software components we use to build Xen. In that case we keep
hashes of those components in our repos, and the hashes were obtained by
just downloading the component "by a fair amount of parties" via "a fair
amount of internet connections" :) See e.g. [2]

[1] https://wiki.qubes-os.org/trac/ticket/203

[2]
http://git.qubes-os.org/?p=joanna/desktop-linux-kde.git;a=blob;f=kde-baseapps/sources-4.9.5;h=7cd127e8a0f098a9428f7bee1bf45c87c5b7500c;hb=HEAD

[J.M. Porup]

On Thu, Apr 10, 2014, at 5:30, Joanna Rutkowska wrote:
> On 04/10/14 01:26, Micah Lee wrote:
> > I think qubes-os.org should use HTTPS, and with all the best practices
> > too: HTTP should redirect to HTTPS, perfect forward secrecy, good
> > ciphersuites, set the HSTS header. It's easy-ish to configure and takes
> > minimal work to maintain.
>

> There are several major problems with using HTTPS for qubes-os.org and
> iso download:

It occurs to me that Micah's question is really about a larger issue.
If everybody used Qubes (or something like it) for better endpoint
security, that would be a Really Good Thing (TM).

Qubes is reaching a point in its maturity where wider adoption
is now (or will soon be) possible.

At the moment Qubes = Secure OS for Paranoid Geeks.

How can we make Qubes = Secure OS for Everyone -- without sacrificing
any of Qubes's security goals?

This enters the realm of politics and marketing. How you answer
this question will determine technical design decisions going
forward.

my $0.02

j

[Joanna Rutkowska]

Let's make one thing clear: Qubes OS R2, despite being probably a very
secure desktop OS, perhaps even the most secure general-purpose desktop
OS that can run 3rd part apps and most drivers, is still not ready for
most mainstream users. It requires too much security consciousness and
discipline IMO. More things need to be automated in order for the
"normal people" to be able to use it meaningfully.

We will get there, sooner or later, but we need to always keep in mind
that for Qubes OS the security always goes first. This is because the
only reason for Qubes OS to exist is SECURITY. If Qubes OS was to
provide only "slightly" more security than any of the mainstream OSes
(Linux, OSX, Windows), then there is simply no reason for it to exist.

Hiding/automating Qubes OS (difficult) mechanisms from the (average)
user in a _meaningful_ way is difficult and will take time. Just like
making a good automatic transmission for a car, which doesn't sacrifice
performance for ease of use is difficult (today we finally have them).
The way to get there for Qubes, I believe, is through commercial
products based on Qubes Odyssey Framework. And this is what we're
focusing on now.

And BTW: I think it is potentially dangerous to advertise Qubes OS R2 as
a "ultimately secure OS for the masses", because it is easy to create a
false sense of security among people: "I'm using Qubes OS, I don't need
to care about anything!". We should stress that Qubes OS is only a tool,
not a magic box that you "plug into your network and forget". It's a
powerful tool, but also a complex tool that requires some thought.

joanna.

[Joanna Rutkowska]

This is not to imply that we shouldn't have articles about Qubes OS in
the more mainstream media. Qubes surely needs some publicity. It's just
that care should be exercised not to describe it as a magical security
panacea.

joanna.

[J.M. Porup]

On Thu, Apr 10, 2014, at 15:49, Joanna Rutkowska wrote:
> This is not to imply that we shouldn't have articles about Qubes OS in
> the more mainstream media. Qubes surely needs some publicity. It's just
> that care should be exercised not to describe it as a magical security
> panacea.

I agree.

I like the automatic transmission metaphor, by the way. May
I borrow that? :)

j

[Joanna Rutkowska]

Be my guest :)

j.

[cprise]

Per my suggestion some months ago, there is an alternative for https...
Use a self-signed cert and suggest that users store the cert in their
browsers (and check the fingerprint). I think you should do this for
qubes-os.org anyway, even if using https for iso downloads isn't
realistic (I would think the latter hinges on whether sf.net subdomains
can be used with a custom cert).

Is this easier for iso downloaders? Maybe not. If there is a simple GPG
GUI out there, that could be less trouble for everyone involved.

> 2) But, even if #1 was not a problem: we still don't (want to) trust our
> cloud operator (and the cert private key must be on the server, and the
> operator can always, at the very least, sniff our servers memory without
> leaving any traces). This specifically considers a government-backed
> attackers.

If this is a reference to the heartbleed bug in openssl, hopefully this
was only a temporary situation... although from what I've read the
breach wasn't very serious in practice because of the way the same
address space keeps getting re-allocated to the same programs on systems
like Linux. Also its said to be limited to the address space of a given
process, so just using Firefox in a Qubes vm is (to me) a very small
threat. (For servers its a much more serious issue.)

> 3) And even if #1 and #2 were not problems: we don't want to host ISO
> images on our own (hosted) sever(s) because of high bandwith costs, and
> that is why we use sf.net to distribute ISOs.

Has ITL looked at the savings from including only a minimal network
install of Fedora on the ISO?

>
> So, I'm concerned that HTTPS might only offer an illusion of trust,
> surely much less than digital signatures we use could offer [*]. Having
> that said, I just recently re-opened a ticket [1] to get cert for the
> wiki server. But as the ticket says this is mostly for "aesthetic
> reasons" and would not apply to ISO download (yet fingerprints will be
> listed on a HTTPS wiki site -- again, still not sure if this a good or
> bad idea...)

Again, I think you should consider self-signed. Its not the easiest, but
neither can it fall into the 'illusion' category.

[Joanna Rutkowska]

On 04/10/14 21:20, cprise wrote:
>> 2) But, even if #1 was not a problem: we still don't (want to) trust our
>> cloud operator (and the cert private key must be on the server, and the
>> operator can always, at the very least, sniff our servers memory without
>> leaving any traces). This specifically considers a government-backed
>> attackers.
>
> If this is a reference to the heartbleed bug in openssl, hopefully this
> was only a temporary situation... although from what I've read the
> breach wasn't very serious in practice because of the way the same
> address space keeps getting re-allocated to the same programs on systems
> like Linux. Also its said to be limited to the address space of a given
> process, so just using Firefox in a Qubes vm is (to me) a very small
> threat. (For servers its a much more serious issue.)
>

No, it's a reference to the simple fact that whoever owns the physical
server (cloud operator), as well as whoever controls the actual admin
domain (so, also the cloud operator) can read all the other VMs memory
at will. Unnoticed by the users/owners of the VMs. No vulnerability is
needed for that.

joanna.

[Micah Lee]

On 04/10/14 01:30, Joanna Rutkowska wrote:
> There are several major problems with using HTTPS for qubes-os.org and
> iso download:
>
> 1) HTTPS/SSL Public CA trust infrastructure is far from ideal so to
> say... There are way too many well known CAs that each browser trusts by
> default, and it is expected that an attacker would be able to relatively
> easy get/steal a signed cert from one of those many "trusted" CAs. As we
> all known that happened many times in the past.

Despite cprise's recommendation in his other email, I still think
there's lots of benefits to using a CA-signed certificate. Nothing stops
you from getting your cert signed by a CA _and also_ distributing the
fingerprint in some other fashion for those that don't trust CAs.
Causing cert warnings in browsers when it's not actually an attack is
always a bad idea and encourages users to click through warnings.

Once a website uses HTTPS, the way browsers end up trusting it can
easily be swapped out. The PKI that everyone uses by default is trusting
CAs (because this is default, I think it's good to support it), but
those exact same certs can be used with other methods, like
convergence.io, Sovereign Keys, some of the HTTPS web of trust models, etc.

But more immediately, Chrome and Firefox have an HSTS preload list [1]
(here's the complete list right now [2]). According to that page, both
browsers share the same list. Once you're using HTTPS, you can email
a...@chromium.org to get your website added to it.

You can make it so Chrome and Firefox automatically preload qubes-os.org
in the HSTS list, which forces HTTPS, and you can pin to a specific CA.
This means that if someone loads https://qubes-os.org/ and is served a
cert that's signed by a different CA, the browser throws a warning. You
still use a CA, but by doing this you can shrink the attack surface by
orders of magnitude.

> 2) But, even if #1 was not a problem: we still don't (want to) trust our
> cloud operator (and the cert private key must be on the server, and the
> operator can always, at the very least, sniff our servers memory without
> leaving any traces). This specifically considers a government-backed
> attackers.

This is a hard problem. But even limiting your threat model from anyone
to (a small number of) government-backed attackers is good. You could
also choose a cloud provider outside of the jurisdiction of the
governments you distrust the most (so those governments would be forced
to do attacks instead of lawful data requests), but that's not ideal.
More on real solutions below.

> 3) And even if #1 and #2 were not problems: we don't want to host ISO
> images on our own (hosted) sever(s) because of high bandwith costs, and
> that is why we use sf.net to distribute ISOs.

Understandable. If you had funding specifically for more secure hosting
though, would that make the issue go away?

> So, I'm concerned that HTTPS might only offer an illusion of trust,
> surely much less than digital signatures we use could offer [*]. Having
> that said, I just recently re-opened a ticket [1] to get cert for the
> wiki server. But as the ticket says this is mostly for "aesthetic
> reasons" and would not apply to ISO download (yet fingerprints will be
> listed on a HTTPS wiki site -- again, still not sure if this a good or
> bad idea...)
>
> Curious to hear your thoughts on addressing the above mentioned
> problems, specifically by "all the cool kids" you mentioned? :)

Freedom of the Press Foundation also operates on a small budget, and is
also using a cloud host that we choose to trust with our SSL key. But
we're actually being even more trusting than that -- we've had to deal
with DDoS attacks before, so we decided to put our whole website behind
CloudFlare in order to weather the storm. This means that the SSL cert
and key served by https://pressfreedomfoundation.org/ is controlled by
CloudFlare (not us), and then CloudFlare connects over the internet to
our VPS with an SSL key controlled by us -- but also readable by our
cloud host.

So the weak points are: trusting CloudFlare and trusting our VPS
provider, and finally trusting all the browser-trusted CAs to not issue
fake certs for our domain. A lot more trust than is ideal, but I still
think this is much, much better than nothing. Also it's cheap.

I'm not sure about the hosting environment for torproject.org and
tails.boum.org, but I'm pretty confident it's much better (but also more
expensive).

I believe Tor owns their physical servers, has physical access to the
data center they're hosted in, and has taken physical security measures
as well. They don't trust any third parties (except for CAs, sort of).
They're in the Chrome/Firefox HSTS preload list. And because they're
using HTTPS, software like Tor Browser Launcher [3] is able to pin to
their actual cert before downloading tarballs and sigs, cutting CAs out
of the loop.

This is clearly more expensive, but setting up HTTPS now in
less-than-ideal situations is a good first step. If you ever get a
better physical hosting situation, it will be easy to generate a new key
and be protected against even more threats.

Without any HTTPS, attacks can be done without leaving any evidence.
Passive attackers can see everything -- someone logs into the wiki at
some point, right? Teenagers at cafes can trick people into downloading
malicious isos. With HTTPS (event trusting CAs) attacks need to be much
more sophisticated and they automatically cut out the set of attackers
that don't have access to a CA. If you get in the Chrome/Firefox preload
list, you automatically cut out the set of attackers that don't have
access to _your_ CA.

And even when there are active attacks, it's impossible to do them
without leaving behind a trail of evidence that software like the SSL
Observatory will pick up [4].

> joanna.
>
> [*] Currently the biggest hole in trust chain for Qubes OS are all the
> packages we get from Fedora (and a few other software we download "in
> raw" format such as e.g. kernel and xen). However all this is digitally
> signed [**] so at least we could always pinpoint where the breach came from.
>
> [**] Not actually true. A few sources for KDE is not digitally signed,
> because the KDE project doesn't understand why signing is good, as well
> as some software components we use to build Xen. In that case we keep
> hashes of those components in our repos, and the hashes were obtained by
> just downloading the component "by a fair amount of parties" via "a fair
> amount of internet connections" :) See e.g. [2]
>
> [1] https://wiki.qubes-os.org/trac/ticket/203
>
> [2]
> http://git.qubes-os.org/?p=joanna/desktop-linux-kde.git;a=blob;f=kde-baseapps/sources-4.9.5;h=7cd127e8a0f098a9428f7bee1bf45c87c5b7500c;hb=HEAD
>

[1] http://dev.chromium.org/sts

[2]
https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

[3] https://github.com/micahflee/torbrowser-launcher

[4]
https://www.eff.org/deeplinks/2012/02/https-everywhere-decentralized-ssl-observatory

--
Micah Lee

[Joanna Rutkowska]

These are some good arguments, I admit, and I like the HSTS. I would
like it even more if I could pin to a specific cert, not just CA...

So, anyway, I'm quite convinced to buy a cert for our wiki at least. Any
recommendations with regards to the (least untrustworthy) CA I should by
it from?

>> 2) But, even if #1 was not a problem: we still don't (want to) trust our
>> cloud operator (and the cert private key must be on the server, and the
>> operator can always, at the very least, sniff our servers memory without
>> leaving any traces). This specifically considers a government-backed
>> attackers.
>
> This is a hard problem. But even limiting your threat model from anyone
> to (a small number of) government-backed attackers is good. You could
> also choose a cloud provider outside of the jurisdiction of the
> governments you distrust the most (so those governments would be forced
> to do attacks instead of lawful data requests), but that's not ideal.
> More on real solutions below.
>
>> 3) And even if #1 and #2 were not problems: we don't want to host ISO
>> images on our own (hosted) sever(s) because of high bandwith costs, and
>> that is why we use sf.net to distribute ISOs.
>
> Understandable. If you had funding specifically for more secure hosting
> though, would that make the issue go away?
>

That particular problem (hosting costs) yes, and you also somehow
convinced me that #1 might not be so much of a problem as I originally
though, but the problem #2 (malicious hosting provider who can
read/modify my VMs memory) still remains unsolved.

And it's quite a problem because it is perfectly possible to imagine an
attack, conducted by the hosting admin, which will not leave any traces
(e.g. in SSL Observatory, etc). It should be only enough for the
attacker to modify the bytes streamed to the user over an already opened
HTTPS connection without the need to play any tricks with certs.
Remember: the attacker has full access to the running VMs memory...

But there is one more problem, orthogonal to the above discussed, but
whose solution might perhaps solve the ISO hosting problem.

It's of course the problem that when the user downloads the ISO on a
compromised client OS, then even if he or she properly verifies the
signatures or the cert of the hosting site (and even if the hoster is
trusted), still the malware on the client can compromise it afterwards.
Or it might come compromised from the server, yet the malware will spoof
the verification process (backdoored gpg, backdoored browser, backdoored
crypto API, etc). These attacks are easier to implement in practice than
many might think. And if all the cool kids start using Tail, Qubes OS,
etc, do you really think the NSA will not go this path in order to
neutralize such tools?

So, how can we protect against this?

1) Order a physical installation disc delivery from e.g. Tails or
Qubes-os.org OS via DHL or FedEx? And how can we know the disc will not
get replaced in transfer?

2) Perhaps buy a Windows original installation disc at a retail store,
check the hologram, install it, and then use for Qubes ISO download?
Sounds a bit clumsy ;) Also implies lots of trusting to various
entities, e.g. the retail store (do we all know how the proper MS
hologram should look like?), or that Windows will not get compromised 5
minutes after we plug it into Internet, or leave with WiFi turned on ;)

3) The more elegant solution would be to use some from of Remote
Attestation paired with trusted boot using SRTM or Intel TXT (note that
trusted boot is a different thing than secure boot).

The way it could work would be that the user downloads the ISO and boots
into it. If the ISO was unmodified and hashes of all the loaded and
executed components (starting from BIOS CRTM) matched, the server
receiving the remote attestation (e.g. hosted by Qubes OS project) would
return a magic response "You booted to a genuine Qubes OS v2.1". The
"only" problem is how to make this response unspoofable by the attacker.
I.e. a compromised ISO might very well pretend it's doing a remote
attestation and just display the expect message anyway...

A simple solution, that is not very secure IMHO, but gives an idea of
how this should work: request the user to send an SMS to predefined
number (controlled by Qubes OS project) and have the server return the
content of this SMS as part of successful remote attestation.

4) Or, how about creating a special Linux distro, very minimal, without
most drivers except for eth, basic video, yet with all the tools needed
to verify downloads (gnupg, preloaded public keys of various projects,
etc). Freeze the distro (so that its hash doesn't change) and keep
giving away (sell) physical discs on each computer security/floss/etc
conference? :)

joanna.

[cprise]

I also would look for a way to distribute the certificate itself with
Qubes, then. Perhaps adding it to the template at install time in a way
that Firefox will use it whenever qubes-os.org is accessed.

BTW, there are some CAs that advertised "Lawful Intercept" services
starting in the late 2000s. VeriSign is one and may even have started
the trend.

>
>>> 2) But, even if #1 was not a problem: we still don't (want to) trust our
>>> cloud operator (and the cert private key must be on the server, and the
>>> operator can always, at the very least, sniff our servers memory without
>>> leaving any traces). This specifically considers a government-backed
>>> attackers.
>> This is a hard problem. But even limiting your threat model from anyone
>> to (a small number of) government-backed attackers is good. You could
>> also choose a cloud provider outside of the jurisdiction of the
>> governments you distrust the most (so those governments would be forced
>> to do attacks instead of lawful data requests), but that's not ideal.
>> More on real solutions below.
>>
>>> 3) And even if #1 and #2 were not problems: we don't want to host ISO
>>> images on our own (hosted) sever(s) because of high bandwith costs, and
>>> that is why we use sf.net to distribute ISOs.
>> Understandable. If you had funding specifically for more secure hosting
>> though, would that make the issue go away?
>>
> That particular problem (hosting costs) yes, and you also somehow
> convinced me that #1 might not be so much of a problem as I originally
> though, but the problem #2 (malicious hosting provider who can
> read/modify my VMs memory) still remains unsolved.

Use an in-house server that accommodates no bulk downloading; just
bittorrent, the wiki, keys and certs.

You could also slim-down the Fedora template part of the Qubes
distribution, and initiate network installation of the remaining parts
right after the template is created.

> And it's quite a problem because it is perfectly possible to imagine an
> attack, conducted by the hosting admin, which will not leave any traces
> (e.g. in SSL Observatory, etc). It should be only enough for the
> attacker to modify the bytes streamed to the user over an already opened
> HTTPS connection without the need to play any tricks with certs.
> Remember: the attacker has full access to the running VMs memory...
>
> But there is one more problem, orthogonal to the above discussed, but
> whose solution might perhaps solve the ISO hosting problem.
>
> It's of course the problem that when the user downloads the ISO on a
> compromised client OS, then even if he or she properly verifies the
> signatures or the cert of the hosting site (and even if the hoster is
> trusted), still the malware on the client can compromise it afterwards.
> Or it might come compromised from the server, yet the malware will spoof
> the verification process (backdoored gpg, backdoored browser, backdoored
> crypto API, etc). These attacks are easier to implement in practice than
> many might think. And if all the cool kids start using Tail, Qubes OS,
> etc, do you really think the NSA will not go this path in order to
> neutralize such tools?
>
> So, how can we protect against this?
>
> 1) Order a physical installation disc delivery from e.g. Tails or
> Qubes-os.org OS via DHL or FedEx? And how can we know the disc will not
> get replaced in transfer?

After learning of computers being systematically intercepted and
altered, I would not even trust delivery for discs anymore. IMO its like
downloading now.

It would, however, make sense for ITL to take Qubes discs for
distribution wherever you go (especially at conferences and trade
shows). I would trust that.

Otherwise, I'd feel obliged to check the signature of the disc or ISO.

> 2) Perhaps buy a Windows original installation disc at a retail store,
> check the hologram, install it, and then use for Qubes ISO download?
> Sounds a bit clumsy ;) Also implies lots of trusting to various
> entities, e.g. the retail store (do we all know how the proper MS
> hologram should look like?), or that Windows will not get compromised 5
> minutes after we plug it into Internet, or leave with WiFi turned on ;)

I wouldn't trust Windows at this point.

> 3) The more elegant solution would be to use some from of Remote
> Attestation paired with trusted boot using SRTM or Intel TXT (note that
> trusted boot is a different thing than secure boot).
>
> The way it could work would be that the user downloads the ISO and boots
> into it. If the ISO was unmodified and hashes of all the loaded and
> executed components (starting from BIOS CRTM) matched, the server
> receiving the remote attestation (e.g. hosted by Qubes OS project) would
> return a magic response "You booted to a genuine Qubes OS v2.1". The
> "only" problem is how to make this response unspoofable by the attacker.
> I.e. a compromised ISO might very well pretend it's doing a remote
> attestation and just display the expect message anyway...
>
> A simple solution, that is not very secure IMHO, but gives an idea of
> how this should work: request the user to send an SMS to predefined
> number (controlled by Qubes OS project) and have the server return the
> content of this SMS as part of successful remote attestation.

Does that bring you back to the dilemma of running a secure server?

> 4) Or, how about creating a special Linux distro, very minimal, without
> most drivers except for eth, basic video, yet with all the tools needed
> to verify downloads (gnupg, preloaded public keys of various projects,
> etc). Freeze the distro (so that its hash doesn't change) and keep
> giving away (sell) physical discs on each computer security/floss/etc
> conference? :)
>
> joanna.
>

Ah, yes. But in this context, I'm not sure what is gained by making a
minimal distro. You might as well use full-sized discs. But minimizing
for network distribution makes sense, and maybe as a side-effect this
would allow you to use CDs or mini-DVD-Rs.

[Joanna Rutkowska]

That is a good idea. For that, however, to be more complete we also need:
1) a way to force the web browser to always expect the specific cert for
qubes-os.org
2) forbid access via http://

Then you would still need to trust... me.

Sure, all Qubes users must currently trust me because it's me who has
the official signing keys for Qubes ISOs and updates. But, sooner or
later we want to move towards deterministic builds and distributed
singing (see ticket #816).

Also, and more importantly, if I (or anybody) sign something
intentionally malicious, I would, sooner or later, loose credibility.
But when I'm physically in possession of a server I can do attacks
without leaving such traces, as explained in the previous post.

Yes. But these could be many servers, or a p2p network even I think.
Only that I still don't have a good idea for this secret confirmation
passphrase...

>> 4) Or, how about creating a special Linux distro, very minimal, without
>> most drivers except for eth, basic video, yet with all the tools needed
>> to verify downloads (gnupg, preloaded public keys of various projects,
>> etc). Freeze the distro (so that its hash doesn't change) and keep
>> giving away (sell) physical discs on each computer security/floss/etc
>> conference? :)
>>
>> joanna.
>>
> Ah, yes. But in this context, I'm not sure what is gained by making a
> minimal distro. You might as well use full-sized discs. But minimizing
> for network distribution makes sense, and maybe as a side-effect this
> would allow you to use CDs or mini-DVD-Rs.

This could be used for trusted download of many other systems, not just
Qubes OS. The should be a broader community project I think. A trusted
platform for ISO download.

joanna.

[J.M. Porup]

On Thu, Apr 17, 2014, at 14:25, Joanna Rutkowska wrote:
> Yes. But these could be many servers, or a p2p network even I think.
> Only that I still don't have a good idea for this secret confirmation
> passphrase...

Would something like a distributed autonomous corporation be a near-future
solution to this problem?

http://www.economist.com/blogs/babbage/2014/01/computer-corporations

http://garzikrants.blogspot.com/2013/01/storj-and-bitcoin-autonomous-agents.html

[cprise]

If used in conjunction with either preloaded HSTS list, or
Https-Everywhere addon (available in repositories such as Fedora), it
could work.

This sounds very interesting, though I worry as researchers and
developers, you are now also facing the administration of complex
security infrastructure. At what point do you have to add manpower to
implement/maintain this...

>> [...]

>>> 4) Or, how about creating a special Linux distro, very minimal, without
>>> most drivers except for eth, basic video, yet with all the tools needed
>>> to verify downloads (gnupg, preloaded public keys of various projects,
>>> etc). Freeze the distro (so that its hash doesn't change) and keep
>>> giving away (sell) physical discs on each computer security/floss/etc
>>> conference? :)
>>>
>>> joanna.
>>>
>> Ah, yes. But in this context, I'm not sure what is gained by making a
>> minimal distro. You might as well use full-sized discs. But minimizing
>> for network distribution makes sense, and maybe as a side-effect this
>> would allow you to use CDs or mini-DVD-Rs.
> This could be used for trusted download of many other systems, not just
> Qubes OS. The should be a broader community project I think. A trusted
> platform for ISO download.
>
> joanna.
>

Getting back to #2, then, I think for the time being we can expect an
attacker to not be so omnipotent as to compromise the GPG verifying
ability of /all/ different operating systems, obtained from divergent
channels and at different points in time. Especially if we bother to
physically remove network access during the process. I think this can
reasonably be considered true even if we use downloaded distros...
booting with an old Knoppix or Ubuntu LTS live CD can be a good way to
verify integrity in a pinch. Perform the same step over again with other
freshly-installed operating systems/distros that were obtained
over-the-counter or at trade shows, while travelling, etc.

So for now the diversity of the IT sector itself may be the best defence
against tainted-in-transit distros. Its a techie strategy but at least
its something. Verification is also not something that has to be done by
the user frequently.

[cprise]

On 04/17/14 13:25, Joanna Rutkowska wrote:

> Does that bring you back to the dilemma of running a secure server?
> Yes. But these could be many servers, or a p2p network even I think.
> Only that I still don't have a good idea for this secret confirmation
> passphrase...
>

There is a p2p, onion-routed network called I2P that has
redundancy/mirror mechanisms. It is not as polished as Tor, but its been
around for a long time, has steadily grown, and the software has been
included in the TAILS distro for the past few years.

http://geti2p.net

The organizational principles you're alluding to seem to reflect those
of I2P: No centralized failure points for either distribution or trust.
In I2P's case, everyone is a "relay" node by default, contributing
bandwidth to the network under expectations that resemble bittorrent
(and I2P even comes with a torrent client designed to run over that
network). There are no centralized 'authorities' that determine routing
patterns or addressing, and the addresses themselves are essentially
public keys so an I2P address can become a strong basis for identity if
the user wishes.

Establishing a presence on I2P may automatically give you some clear
avenues for implementing your ideas.

[Oleg Artemiev]

You're right. Though people voting for https by default are also right. :)

In a few words:

1. ssl makes SOME attacks impossible and SOME attacks harder to gain result.

2. protection from some is better then no protection.

To save users from false sense of security by forced ssl, you should
put a warning
with a link to your comments above.

At least I vote for forced ssl everywhere + this warning on top.

SSL for iso downloads is not that important, though having
information about iso
checksums in a few places would be better. AFAIK, currently an ISO and a hash
are both in one place (sourceforge) & no way to compare hashes obtained from
diffrent locations (please correct me if I'm wrong).

>
> [*] Currently the biggest hole in trust chain for Qubes OS are all the
> packages we get from Fedora (and a few other software we download "in
> raw" format such as e.g. kernel and xen). However all this is digitally
> signed [**] so at least we could always pinpoint where the breach came from.
>
> [**] Not actually true. A few sources for KDE is not digitally signed,
> because the KDE project doesn't understand why signing is good, as well
> as some software components we use to build Xen. In that case we keep
> hashes of those components in our repos, and the hashes were obtained by
> just downloading the component "by a fair amount of parties" via "a fair
> amount of internet connections" :) See e.g. [2]
>
> [1] https://wiki.qubes-os.org/trac/ticket/203
>
> [2]
> http://git.qubes-os.org/?p=joanna/desktop-linux-kde.git;a=blob;f=kde-baseapps/sources-4.9.5;h=7cd127e8a0f098a9428f7bee1bf45c87c5b7500c;hb=HEAD
>

--
Bye.Olli.
gpg --search-keys grey_olli
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (mostly in russian): http://grey-olli.livejournal.com/tag/