Re: https, client certificate, pem pass phrase

From: Mark Lodato <lodatom@gmail.com>
Date: Jun 11, 2009, 23:54 UTC
Message-ID: <ca433830906111654g629429d1j73722baf7ab02fc2@mail.gmail.com>
In-Reply-To: <alpine.OSX.2.00.0906111801400.67531@xor.localnet>

On Thu, Jun 11, 2009 at 12:43 PM, Karsten Weiss<knweiss@gmx.de> wrote:

Show 18 quoted lines

> On Thu, 11 Jun 2009, Karsten Weiss wrote:
>
>> However, it only works as long as I do *not* protect the client's private
>> key (PEM) with a pass phrase which is not secure (especially when using
>> FakeBasicAuth!). When I do protect the private key with a pass phrase *each*
>> git fetch/pull/push prompts the user *several* times with "Enter PEM pass
>> phrase:". Thus, it's not usable (even though it works).
>
> Somehow I managed to miss Mark Lodato's posting from 2009-05-28 before:
>
> [PATCH 1/2] http.c: prompt for SSL client certificate password
> http://marc.info/?l=git&m=124348062226665&w=4
> [PATCH 2/2] http.c: add http.sslCertNoPass option
> http://marc.info/?l=git&m=124348062326671&w=4
>
> I can confirm that his two patches solve the problem. I.e. there is now only
> a single passphrase prompt during each Git invocation that involves the
> https protocol. Great!

Glad to hear this works for you, and that there is interest in this patch series!

Show 5 quoted lines

> However, I want to add two additional suggestions:
>
> With the patch Git prompts for a "Certificate Password". IMHO it would be
> better to prompt for the "Certificate private key passphrase" because it's
> the private key which is protected and not the certificate itself.

I realize this is the case, but here's my reasoning for the wording: The user is trying to use a client-side certificate, and a password is needed for that certificate. It doesn't really matter whether it's the private key or the certificate itself - a password is needed to perform this operation, thus the name "Certificate Password." Furthermore, if only http.sslCert is given, asking for the "private key" pass phrase might be confusing since http.sslKey was not set. (Note that if *only* http.sslKey is set, it is ignored.) I'm not strongly tied to this wording, but I'd be interested to hear other input on this.

On "password" vs "passphrase" vs "pass phrase", it should perhaps be "pass phrase," since that's the term OpenSSL uses.

> The
> config flag IMHO also should be renamed from http.sslCertNoPass to
> http.sslKeyNoPassphrase.

I used "NoPass" to keep the name short. I'm not tied to this, but I prefer the shorter "NoPass," if there are no other opinions.

> (Of course it would be even nicer if the code could
> detect if the key has a passphrase and only prompt for it when really
> necessary)

I agree, this would really be best, but I do not think this is possible without modifying libcurl or implementing our own, OpenSSL-specific engine to open the key. Neither seems worth the effort to me.

> Regarding the caching of the passphrase in memory: Maybe the passphrase
> memory region could be mlock()ed to prevent the kernel from paging it to
> disk? But I'm not sure if this is worth effort.

Libcurl doesn't do this, so I didn't bother to either. Like above, I don't think it's worth the effort to do it now. But I didn't know about mlock(), so thanks for that tip!

Anyway, thanks for the feedback on the patch!

Mark