[vlc-devel] Future of the update mechanism

[jpd at videolan.org]

On Thu, Jul 30, 2009 at 09:19:52AM +0200, R??mi Denis-Courmont wrote:
> On Thu, 30 Jul 2009 02:05:02 +0200, jpd at videolan.org wrote:
> > I'm not aware that ssl is much more computationally expensive than
> > gpg
> 
> With OpenPGP, the server does NOT make ANY cryptographic operation. It just
> serves a file (over HTTP) that happens to contain a digital signature...
> And you can replicate that file to any number of mirrors without problems.

Right. I wasn't thinking server side. You are right that trusting
anything merely because it came in over a secured socket is fairly
weak and costly for our servers, and so foregoing that in favour
of one signature check makes sense, provided the keys used are not
compromised[1].

But you could do that with gpg and openssl both. And x509 certificates,
even self-signed ones, can provide better protection there, but are more
cumbersome to setup.


> And, depending on the of the SSL framework, we may have to pay an
> x.509 certificate eternally.

That's not an argument against using openssl in general. As noted it's
entirely possible to create our own CA cert and use that. Any openssl
can do it, once you figure out how.

It is, however, an argument against using frameworks that require
paid-for certificates, especially since no issuers so far have managed
to satisfactorily show they vet their issuees properly. In fact, it has
been shown time and again that they *do not* do any such thing.
Thus, scam. Like I said.


But that leaves us with a minor problem: How do you detect the key
is compromised? gpgverify will just take any supplied key. gpg will
complain that a key isn't signed but most users won't have our signing
key signed on their keyring so that means suppressing the warnings (back
to gpgverify). That means that the most you'll get out of gpg outside
of close-knit gpg-using communities[2] is ``this signature successfully
verifies with this key'', meaning that if the key can be trusted, the
verified data can be trusted.

But it gives exactly *no* guarantees about the trustworthyness of the key.


Using x509 certificates (including on the client side only) at least
allows us to force checking the key against a (our) CA. That's still no
panacea, but if we manage to make use of that it is a better proposition
for our use case. If we don't manage our key integrity it suddenly matters
much less whether we sign anything or not. I am not quite prepared to
argue it would be better to not sign anything in that case, but it is
conceivable that would turn out be the case. Do not expect magic from the
mere fact that we're signing; if you do, you believe in snake oil.


> It's probably not an accident that apt and similar things use OpenPGP
> rather than SSL/TLS.

They could be using openssl for client side signature verification too,
but the trust propagation model probably fits their beliefs better.


[1] It's not too difficult to imagine that as part of a MITM attack an
    adversary replaces the (gpg|openssl) certificate used with his own.
[2] That would require we go to key signing parties and convince as many
    people as possible to sign our key. But that is still not going to
    help any of the people who did not go to such a party, ie. the bulk
    of our users.