Re: [PATCH] Cache ssl client certificate passphrases

On Fri, May 9, 2008 at 4:03 AM, Joe Orton <jorton_at_redhat.com> wrote:
> On Thu, May 08, 2008 at 05:19:55PM -0400, Mark Phippard wrote:
>> I must be missing something because I do not see how this is any
>> better. It would still rely on physical security otherwise someone
>> could just grab your unencrypted cert and use it to impersonate you.
>
> At the moment you can configure Subversion to use a client certificate
> in PKCS#12 format in a file on disk. This client cert can be stored on
> disk in (essentially) "plaintext" form; Subversion can use the clicert
> to authenticate the user to a server as-is, without ever having to
> prompt for any passphrase.
>
> If you store the client cert on disk in that way, you rely on the
> physical security of the filesystem, as you say.
>
> If you do *not* trust the physical security of the filesystem, you have
> a few different options for continuing to use client certs; one of which
> is to store the client cert in encrypted PKCS#12 format, on disk.
>
> Subversion would then need to prompt the user for the password before
> being able to use the client cert. Because it is implicit that the user
> does not trust the physical security of the filesystem in this case, it
> would then be pretty silly to go and store that passphrase *in the
> filesystem*.
>
> Does this make sense yet?

Sorry, but it does not make any sense. We already allow you to store
a plain text pass-phrase in the servers file. Why would you object to
moving this into our password storage area, which on Windows and OSX
is very secure? Why should those users have to accept this as is when
we can offer a much better solution? And if any of these Unix
branches being worked on pan out, then Unix users would also be able
to have it stored securely.

> Using PKCS#11 providers with SVN 1.5, you can solve the problem of not
> trusting the physical security of $HOME in a couple of new ways:
>
> 1) using real hardware smartcards means you avoid storing client certs
> in files at all

Just a question since you might have tested this. When you use a
solution like this what is the user experience typically like? I
assume every Subversion command still has to issue this challenge.
Does a user need to swipe a card for every command, or do they
typically insert it and leave it some device, or does the OS do
something to authenticate for the user?

> 2) GNOME Keyring includes a PKCS#11 provider, and can handle client
> certs in PKCS#12 format. So you can dump an encrypted PKCS#12 cert in
> the GNOME Keyring, and configure Subversion to use the GNOME keyring
> PKCS#11 provider. The first time SVN needs to use the client cert,
> you'll get a GNOME dialog popup asking for the client cert passphrase.
> Subsequently, it's cached in RAM and works automagically. This provides
> an ssh-agent-like solution for SSL, which is pretty neat.

What is doing the integration with GNOME keyring? pakchois? How does
it handle running in a non-GUI environment or loading the
dependencies? I ask because this discussion has been going on in
relation to the SVN GNONE keyring branch activity.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org