{"thread":{"id":"19772","subject":"https, client certificate, pem pass phrase","startedAt":"2009-06-11T08:36:14Z","lastAt":"2009-06-11T23:54:58Z","messageCount":3,"participants":["Karsten Weiss","Mark Lodato"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"116063","messageId":"alpine.OSX.2.00.0906110956370.945@xor.localnet","threadId":"19772","inReplyTo":null,"subject":"https, client certificate, pem pass phrase","fromName":"Karsten Weiss","fromEmail":"knweiss@gmx.de","sentAt":"2009-06-11T08:36:14Z","receivedAt":"2009-06-11T08:36:14Z","isPatch":false,"sender":{"key":"knweiss@gmx.de","avatar":null},"body":"Hi,\n\nI'm using git-1.6.3.2 (with curl-7.19.5) and would like to configure a \nprivate git server to be used over https with client-side certificate and \nBasicAuth authentication because I want to restrict access to selective \nand authenticated clients from the Internet which connect to the server \nthrough a firewall and web proxy.\n\nSo far my test setup works fine. Using SSL FakeBasicAuth I can even access \nthe git server without storing the BasicAuth password unencrypted in \n~/.netrc (and there are also no git password prompts).\n\nHowever, it only works as long as I do *not* protect the client's private \nkey (PEM) with a pass phrase which is not secure (especially when using \nFakeBasicAuth!). When I do protect the private key with a pass phrase \n*each* git fetch/pull/push prompts the user *several* times with \"Enter \nPEM pass phrase:\". Thus, it's not usable (even though it works).\n\nIs there any way I can prevent this? Ideally, I want to be prompted for \nthe PEM pass phrase once and only once for each git command which uses a \nsecure network connection.\n\nSearching the git mailing list archive I found this thread from February \n09 which seems to indicate\n\ngit with https and client cert asks for password repeatedly\nhttp://marc.info/?l=git&m=123553151323420&w=2\n\nthat this really does not work with git's current http code. Can anyone \nconfirm that this is still the case? I'm willing to test patches if \nsomebody is working on this problem.\n\n-- \nKarsten Weiss\n"},{"id":"116080","messageId":"alpine.OSX.2.00.0906111801400.67531@xor.localnet","threadId":"19772","inReplyTo":"alpine.OSX.2.00.0906110956370.945@xor.localnet","subject":"Re: https, client certificate, pem pass phrase","fromName":"Karsten Weiss","fromEmail":"knweiss@gmx.de","sentAt":"2009-06-11T16:43:50Z","receivedAt":"2009-06-11T16:43:50Z","isPatch":false,"sender":{"key":"knweiss@gmx.de","avatar":null},"body":"On Thu, 11 Jun 2009, Karsten Weiss wrote:\n\n> However, it only works as long as I do *not* protect the client's private key \n> (PEM) with a pass phrase which is not secure (especially when using \n> FakeBasicAuth!). When I do protect the private key with a pass phrase *each* \n> git fetch/pull/push prompts the user *several* times with \"Enter PEM pass \n> phrase:\". Thus, it's not usable (even though it works).\n\nSomehow I managed to miss Mark Lodato's posting from 2009-05-28 before:\n\n[PATCH 1/2] http.c: prompt for SSL client certificate password\nhttp://marc.info/?l=git&m=124348062226665&w=4\n[PATCH 2/2] http.c: add http.sslCertNoPass option\nhttp://marc.info/?l=git&m=124348062326671&w=4\n\nI can confirm that his two patches solve the problem. I.e. there is now \nonly a single passphrase prompt during each Git invocation that involves \nthe https protocol. Great!\n\nHowever, I want to add two additional suggestions:\n\nWith the patch Git prompts for a \"Certificate Password\". IMHO it would be \nbetter to prompt for the \"Certificate private key passphrase\" because it's \nthe private key which is protected and not the certificate itself. The \nconfig flag IMHO also should be renamed from http.sslCertNoPass to \nhttp.sslKeyNoPassphrase. (Of course it would be even nicer if the code \ncould detect if the key has a passphrase and only prompt for it when \nreally necessary)\n\nRegarding the caching of the passphrase in memory: Maybe the passphrase \nmemory region could be mlock()ed to prevent the kernel from paging it to \ndisk? But I'm not sure if this is worth effort.\n"},{"id":"116109","messageId":"ca433830906111654g629429d1j73722baf7ab02fc2@mail.gmail.com","threadId":"19772","inReplyTo":"alpine.OSX.2.00.0906111801400.67531@xor.localnet","subject":"Re: https, client certificate, pem pass phrase","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-06-11T23:54:58Z","receivedAt":"2009-06-11T23:54:58Z","isPatch":false,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"On Thu, Jun 11, 2009 at 12:43 PM, Karsten Weiss<knweiss@gmx.de> wrote:\n> On Thu, 11 Jun 2009, Karsten Weiss wrote:\n>\n>> However, it only works as long as I do *not* protect the client's private\n>> key (PEM) with a pass phrase which is not secure (especially when using\n>> FakeBasicAuth!). When I do protect the private key with a pass phrase *each*\n>> git fetch/pull/push prompts the user *several* times with \"Enter PEM pass\n>> phrase:\". Thus, it's not usable (even though it works).\n>\n> Somehow I managed to miss Mark Lodato's posting from 2009-05-28 before:\n>\n> [PATCH 1/2] http.c: prompt for SSL client certificate password\n> http://marc.info/?l=git&m=124348062226665&w=4\n> [PATCH 2/2] http.c: add http.sslCertNoPass option\n> http://marc.info/?l=git&m=124348062326671&w=4\n>\n> I can confirm that his two patches solve the problem. I.e. there is now only\n> a single passphrase prompt during each Git invocation that involves the\n> https protocol. Great!\n\nGlad to hear this works for you, and that there is interest in this\npatch series!\n\n> However, I want to add two additional suggestions:\n>\n> With the patch Git prompts for a \"Certificate Password\". IMHO it would be\n> better to prompt for the \"Certificate private key passphrase\" because it's\n> the private key which is protected and not the certificate itself.\n\nI realize this is the case, but here's my reasoning for the wording:\nThe user is trying to use a client-side certificate, and a password is\nneeded for that certificate.  It doesn't really matter whether it's\nthe private key or the certificate itself - a password is needed to\nperform this operation, thus the name \"Certificate Password.\"\nFurthermore, if only http.sslCert is given, asking for the \"private\nkey\" pass phrase might be confusing since http.sslKey was not set.\n(Note that if *only* http.sslKey is set, it is ignored.)  I'm not\nstrongly tied to this wording, but I'd be interested to hear other\ninput on this.\n\nOn \"password\" vs \"passphrase\" vs \"pass phrase\", it should perhaps be\n\"pass phrase,\" since that's the term OpenSSL uses.\n\n> The\n> config flag IMHO also should be renamed from http.sslCertNoPass to\n> http.sslKeyNoPassphrase.\n\nI used \"NoPass\" to keep the name short.  I'm not tied to this, but I\nprefer the shorter \"NoPass,\" if there are no other opinions.\n\n> (Of course it would be even nicer if the code could\n> detect if the key has a passphrase and only prompt for it when really\n> necessary)\n\nI agree, this would really be best, but I do not think this is\npossible without modifying libcurl or implementing our own,\nOpenSSL-specific engine to open the key.  Neither seems worth the\neffort to me.\n\n> Regarding the caching of the passphrase in memory: Maybe the passphrase\n> memory region could be mlock()ed to prevent the kernel from paging it to\n> disk? But I'm not sure if this is worth effort.\n\nLibcurl doesn't do this, so I didn't bother to either.  Like above, I\ndon't think it's worth the effort to do it now.  But I didn't know\nabout mlock(), so thanks for that tip!\n\n\nAnyway, thanks for the feedback on the patch!\n\nMark\n"}]}