Re: [PATCH 1/2] http.c: prompt for SSL client certificate password
- From
Mark Lodato <lodatom@gmail.com>
- Date
- Jun 12, 2009, 23:26 UTC
- Message-ID
- <ca433830906121626q52c15f6cjdb91ffee1f2d8652@mail.gmail.com>
- In-Reply-To
- <alpine.DEB.2.00.0906120943560.5566@yvahk2.pbagnpgbe.fr>
On Fri, Jun 12, 2009 at 3:56 AM, Daniel Stenberg<daniel@haxx.se> wrote:
Show 18 quoted lines
> On Fri, 12 Jun 2009, Nanako Shiraishi wrote: > >> It would be ideal if you can inspect the certificate and decide if you >> need to ask for decrypting password before using it (and otherwise you don't >> ask). If you can't do that, probably you can introduce a config var that >> says "this certificate is encrypted", and bypass your new code if that >> config var isn't set. > > Is this really a common setup? Using an unencrypted private key sounds like > a really bad security situation to me. The certificate is never encrupted, > the passphrase is for the key. > > And for the libcurl not supporting this, I figure it _could_ be done by > simply letting libcurl prope the remote and see if it can access it without > a passphrase as that would then imply that isn't necessary. > > I'm not familiar enough with the code and architecture to deem how suitable > such an action would be.
I don't think it is possible to check to see if it is encrypted from within git (without calling OpenSSL directly.) To implement this in libcurl, a possible solution is to always set SSL_CTX_set_default_passwd_cb(), and have the callback function prompt the user on the first call if CURLOPT_KEYPASSWD is not set. If there is interest, I could try this out and, if it works, submit a patch for libcurl.
The upside of doing the prompting in git is that it works with old libcurl versions... but I'm not sure this is a big deal. Having it in libcurl is probably better.
On Thu, Jun 11, 2009 at 7:42 PM, Nanako Shiraishi<nanako3@lavabit.com> wrote:
Show 5 quoted lines
> Somebody mentioned that your patch forces people to type password > even when the certificate isn't encrypted. How was this issue addressed? > > <snip...> If you can't do that, probably you can introduce a config var that says > "this certificate is encrypted", and bypass your new code if that config var isn't set.
Patch 2/2 gives the user a way to disable this new password prompt. I imagine it is a more common for the certificate to be encrypted than not, so I believe the default should be to prompt.
Mark