[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Cache ssl client certificate passphrases

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 08 May 2008 15:27:53 -0400

"Mark Phippard" <markphip_at_gmail.com> writes:
>> I think this is a bad idea. The only reason to store a client cert in
>> encrypted form is to prevent anybody who can get a filesystem
>> dump/backup from using it. If you want to store the passphrase on disk,
>> it's implicit that you don't care about that threat model - so just
>> store the client cert on disk in unencrypted form, and you'll never have
>> to enter a passphrase. (Yes, I think ssl-client-cert-password is a bad
>> idea too, FWIW)
>
> I think a certificate passphrase is not all that different from a
> password provided to a basic response challenge. Given that every
> Subversion command is a new session and a passphrase has to be entered
> every time, people are going to want to cache them. And it does not
> make sense to store these in plain-text when we have the ability to
> encrypt them.

If I understand him correctly, Joe is pointing out that the only purpose
of this passphrase is to decrypt the cert -- so instead of storing the
passphrase unencrypted, we might as well dispense with the passphrase
entirely and just store the unencrypted cert itself.

It is true that from the user's point of view, the passphrase is just
another password. But the user-visible behavior would be the same
whether the passphrase or the cert were stored unencrypted: namely, that
the user wouldn't get prompted for the passphrase.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-08 21:28:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.