https, client certificate, pem pass phrase

https, client certificate, pem pass phrase

[Karsten Weiss]

Hi,

I'm using git-1.6.3.2 (with curl-7.19.5) and would like to configure a 
private git server to be used over https with client-side certificate and 
BasicAuth authentication because I want to restrict access to selective 
and authenticated clients from the Internet which connect to the server 
through a firewall and web proxy.

So far my test setup works fine. Using SSL FakeBasicAuth I can even access 
the git server without storing the BasicAuth password unencrypted in 
~/.netrc (and there are also no git password prompts).

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).

Is there any way I can prevent this? Ideally, I want to be prompted for 
the PEM pass phrase once and only once for each git command which uses a 
secure network connection.

Searching the git mailing list archive I found this thread from February 
09 which seems to indicate

git with https and client cert asks for password repeatedly
http://marc.info/?l=git&m=123553151323420&w=2

that this really does not work with git's current http code. Can anyone 
confirm that this is still the case? I'm willing to test patches if 
somebody is working on this problem.

-- 
Karsten Weiss

Re: https, client certificate, pem pass phrase

[Karsten Weiss]

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!

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. The 
config flag IMHO also should be renamed from http.sslCertNoPass to 
http.sslKeyNoPassphrase. (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)

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.

Re: https, client certificate, pem pass phrase

[Mark Lodato]

On Thu, Jun 11, 2009 at 12:43 PM, Karsten Weiss<knweiss@gmx.de> wrote:
> 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!

> 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