One more time, SSL vs GPG was Re: hackage, cabal-get, and security

[S. Alexander Jacobson]

Abstracts:

GPG secures documents, not interactions.
SSL secures interactions, not documents
Hackage is an interaction not a document.
Therefore, SSL can secure Hackage, but GPG can't.

GPG requires that users learn GPG and attend key signing parties.
SSL requires no additional work from the user.
Therefore, SSL is easier for users than GPG.

GPG requires authors to learn GPG and attend key signing parties.
SSL requires authors to learn nothing.
Therefore, SSL is easier for authors.

SSL requires server operators to obtain a cert and authenticate users.
GPG requires little of server operators.
Therefore, GPG is easier for server operators.

GPG requires that an arbitrarily long chain of attendees at 
key signing parties all to manage keys AND verify identity 
properly in order to authenticate authorship of a document.
SSL requires only that a server operators manage keys and 
verify identity properly in orer to authenticate authorship of a 
document.
Therefore, SSL is less risky/more secure than GPG.

Gory Details:

A Hackage installation exists because some server operator did the due 
dilligence of building up an accurate package database.  However, 
since Hackage exposes a search interface rather than a database file, 
absent a secure (SSL) connection to the server, Hackage users have no 
way to authenticate search results e.g a mapping from package name to 
URL.

On Thu, 19 May 2005, Shae Matijs Erisson wrote:
> How do server operators know that the packages they get come from the actual
> developers and are not forged? If you use an SSL upload, how do you know who or
> where the upload came from? In this scenario, developers must be their own
> server operators to achieve any security.

Typically server operators issue developers a password via some secure 
means.  The server operator knows it is the developer that is 
uploading because only the developer (hopefully) has the password, 
just as with GPG only the developer (hopefuly) has the private key.
I'm not sure what security you think developers need here.

>> * With GPG, developers need to keep their private keys secure on all their
>> machines.  If ANY of their machines are cracked, their identity is owned
>> until they are able to publish a revocation certificate. They need to keep
>> all their revocation certificates in a safe place and NOT on the machine
>> where they keep their private keys and proximate to wherever they happen to
>> be!  Developers have to be really diligent.  With SSL, only server operators
>> need to manage certs and they are already expected to be diligent.

> Keys are kept on a single machine. Your identity is not 'owned' if a copy of
> your keyring is stolen, not unless that keyring has no password. You will want
> to keep the revocation certificate in one or two other places, so there's a
> greater chance that someone would crack your box and then revoke your key.

No.  You need a key on every machine on which you intend to sign code. 
The worry is not just that someone will steal your keyring file.  The 
worry is that they replace your GPG executable with one that allows 
them to intercept your password.  And my point about revocation 
certificates is that you are vulnerable to anyone in your network that 
fails to handle maintaining revocation certs properly. I think server 
operators are likely to be more reachable and diligent about such 
things than work-a-day developers.  And the SSL/CA model doesn't 
require that a user maintain a revocation cert in order to accomplish 
a revocation!

> On the other hand, SSL certificates must have no password, or else they require
> the server admin to type in the password each time the SSL server starts.

However, if someone gets root, they can do whatever they want 
anyway so, ALSO getting the private key may add little value. 
Moreover, since they can replace the password system 
and force a reboot in any case, there is no major value to 
requiring a password.  Note, they can only do damage for the time 
they have root and are not discovered.
Note that usually professionally managed SSL servers are more 
hardenned than the typical developer box.

> If someone cracks the SSL server, how do you revoke the certificate?

You tell your CA to add it to a Certificate Revocation List.

> There is no difference between a relationship with a server operator and a
> chain of key signings.

Actually there is a substantial difference.  Both sender and reciever 
have a very specific relationship with a CA whose job it is to provide 
these sorts of relationships.  One requires you to go to key signing 
parties.  The other does not.  In theory you can implement a CA type 
role on top of GPG, but then you are operating a CA rather than a GPG 
chain of trust.

>> * With GPG, module users have to understand the whole public key security
>> model and how to use gpg etc (e.g. how do they get a key signing
>> relationship? how often will they do a gpg --refresh, why?). With SSL, users
>> don't need to learn anything new.
>
> SSL doesn't do what GPG does. SSL doesn't have any way to update certificate
> trust other than manually removing or adding certificates.

SSL doesn't *need* a way to update certificates except when you want 
to add/remove a CA and that is/should-be relatively rare.  GPG 
requires users to deal with manual key exchanges on a regular basis.

> Other widespread code-signing models exist in the form of Linux distributions
> that allow signed packages that fit into the web of trust, see Mandriva, Red
> Hat, and Debian for examples.

With Debian, I assume you are referring to 
http://www.debian.org/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign

It looks like they are experimenting with signing packages and it 
looks like they are still not clear on exactly what a signed package 
actually signifies.

Note this is in contrast to signed release files which would be 
analogous to signed modulemaps rather than signed packages.

In theory I could implement that sort of security for module maps, but 
that is a different discusion.

> If you want to take Microsoft as an example, they also use GPG-style per-file
> signatures for ActiveX components. They don't use SSL in place of the per-file
> signatures.

True.  Except that note that Microsoft code signing is CA based NOT 
GPG-style chain-of-trust based.  And the reasons they chose 
code-signing over SSL for ActiveX are not necessarily relevant here.

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com




> "S. Alexander Jacobson" <alex at alexjacobson.com> writes:
>
> Abstract:
>
> GPG and SSL are tools for entirely different goals.
> GPG can give you some assurance that a file was signed by a certain person.
> SSL can give you some assurance that received data is the same as server data.
>
> SSL does not guarantee that a certain person put information on the server,
> only that the information that you got did come from the server.
> That's just not the same thing at all.
>
>
> You can skip the rest of this message if you don't want the blow by blow.
>
>
>> * With GPG, all developers need to create and manage private keys (including
>> all that workflow associated pre-generating revocation certificates, etc).
>> With SSL, only server operators do.
>





>> * With GPG, developers need to keep their private keys secure on all their
>> machines.  If ANY of their machines are cracked, their identity is owned
>> until they are able to publish a revocation certificate. They need to keep
>> all their revocation certificates in a safe place and NOT on the machine
>> where they keep their private keys and proximate to wherever they happen to
>> be!  Developers have to be really diligent.  With SSL, only server operators
>> need to manage certs and they are already expected to be diligent.
>
> No, this is not true.
>
> Keys are kept on a single machine. Your identity is not 'owned' if a copy of
> your keyring is stolen, not unless that keyring has no password. You will want
> to keep the revocation certificate in one or two other places, so there's a
> greater chance that someone would crack your box and then revoke your key.
>
> On the other hand, SSL certificates must have no password, or else they require
> the server admin to type in the password each time the SSL server starts.
> In the password case, you either need to decrease security by sharing the
> password with multiple people or you need to wake up the guy with the password
> everytime the power goes out, the kernel panics, or other force majeure
> restarts the SSL server or the hardware.
>
> If someone cracks the SSL server, how do you revoke the certificate?
>
>> * With GPG, developers needs to establish a chain of key signings to all of
>> the users of the modules they create. With SSL, developers only need a
>> relationship with a server operator.
>
> No, this is not true.
>
> There is no difference between a relationship with a server operator and a
> chain of key signings.
>
>> * With GPG, module users have to understand the whole public key security
>> model and how to use gpg etc (e.g. how do they get a key signing
>> relationship? how often will they do a gpg --refresh, why?). With SSL, users
>> don't need to learn anything new.
>
> SSL doesn't do what GPG does. SSL doesn't have any way to update certificate
> trust other than manually removing or adding certificates.
>
>> And this isn't all just theory.  In practice, SSL's transport security model
>> has been *vastly* more successful in the real world than any content signing
>> model (e.g. whatever happenned to SHTTP(1)).  And note that the *only*
>> widespread code-signing model, is Microsoft's active-x and that relies on a
>> centralized CA, like SSL, rather than a GPG style web-of-trust.
>
> No, this is not true.
>
> Other widespread code-signing models exist in the form of Linux distributions
> that allow signed packages that fit into the web of trust, see Mandriva, Red
> Hat, and Debian for examples.
>
> If you want to take Microsoft as an example, they also use GPG-style per-file
> signatures for ActiveX components. They don't use SSL in place of the per-file
> signatures.
> -- 
> It seems I've been living two lives. One life is a self-employed web developer
> In the other life, I'm shapr, functional programmer.  | www.ScannedInAvian.com
> One of these lives has futures (and subcontinuations!)|  --Shae Matijs Erisson
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>