I am not sure if its a bug in curl or git, but despite setting GIT_SSL_NO_VERIFY=1, if i use a different ip address or hostname then the certificate was signed for, git fails to push changes.
threads / discuss / 12228
GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
Subject: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
On Wed, Feb 20, 2008 at 03:35:54PM -0800, Anatoly Yakovenko wrote:
> I am not sure if its a bug in curl or git, but despite setting > GIT_SSL_NO_VERIFY=1, if i use a different ip address or hostname then > the certificate was signed for, git fails to push changes.
Can you try with GIT_CURL_VERBOSE=1 ? The trace message will probably help understanding what happens.
Mike
Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
yep, it tells me that the certificate is rejected because it was signed for a different ip then the one i am connected too. while this is a security threat, browsers will let you ignore it, so i expect that libcurl or git should be able to ignore that error as well.
On Wed, Feb 20, 2008 at 10:42 PM, Mike Hommey <mh@glandium.org> wrote:
Show 11 quoted lines
> > On Wed, Feb 20, 2008 at 03:35:54PM -0800, Anatoly Yakovenko wrote: > > I am not sure if its a bug in curl or git, but despite setting > > GIT_SSL_NO_VERIFY=1, if i use a different ip address or hostname then > > the certificate was signed for, git fails to push changes. > > Can you try with GIT_CURL_VERBOSE=1 ? The trace message will probably > help understanding what happens. > > Mike >
Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
On Thu, 21 Feb 2008, Anatoly Yakovenko wrote:
> yep, it tells me that the certificate is rejected because it was signed for > a different ip then the one i am connected too. while this is a security > threat, browsers will let you ignore it, so i expect that libcurl or git > should be able to ignore that error as well.
libcurl can most certainly be told to ignore that:
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTSSLVERIFYHOST
[PATCH] Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set
Signed-off-by: Mike Hommey <mh@glandium.org> --- http.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c index 5925d07..519621a 100644 --- a/http.c +++ b/http.c @@ -177,6 +177,7 @@ static CURL* get_curl_handle(void) CURL* result = curl_easy_init(); curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, curl_ssl_verify); + curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, curl_ssl_verify * 2); #if LIBCURL_VERSION_NUM >= 0x070907 curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL); #endif
-- 1.5.4.1.48.g0d77
Re: [PATCH] Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set
Mike Hommey <mh@glandium.org> writes:
Show 17 quoted lines
> Signed-off-by: Mike Hommey <mh@glandium.org> > --- > http.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/http.c b/http.c > index 5925d07..519621a 100644 > --- a/http.c > +++ b/http.c > @@ -177,6 +177,7 @@ static CURL* get_curl_handle(void) > CURL* result = curl_easy_init(); > > curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, curl_ssl_verify); > + curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, curl_ssl_verify * 2); > #if LIBCURL_VERSION_NUM >= 0x070907 > curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL); > #endif
Is it just me who finds that "* 2" is extremely magical?
diff --git a/http.c b/http.c index 5925d07..8dce820 100644 --- a/http.c +++ b/http.c @@ -176,7 +176,16 @@ static CURL* get_curl_handle(void) { CURL* result = curl_easy_init(); - curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, curl_ssl_verify); + if (!curl_ssl_verify) { + curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 0); + curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 0); + } else { + /* Verify authenticity of the peer's certificate */ + curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 1); + /* The name in the cert must match whom we tried to connect */ + curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2); + } + #if LIBCURL_VERSION_NUM >= 0x070907 curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL); #endif
Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
On Thu, Feb 21, 2008 at 10:57:58AM -0800, Anatoly Yakovenko wrote:
> yep, it tells me that the certificate is rejected because it was > signed for a different ip then the one i am connected too. while this > is a security threat, browsers will let you ignore it, so i expect > that libcurl or git should be able to ignore that error as well.
What is the exact message ?
Mike
Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
On Thu, Feb 21, 2008 at 11:09 AM, Mike Hommey <mh@glandium.org> wrote:
Show 7 quoted lines
> On Thu, Feb 21, 2008 at 10:57:58AM -0800, Anatoly Yakovenko wrote: > > yep, it tells me that the certificate is rejected because it was > > signed for a different ip then the one i am connected too. while this > > is a security threat, browsers will let you ignore it, so i expect > > that libcurl or git should be able to ignore that error as well. > > What is the exact message ?
$ GIT_SSL_NO_VERIFY=1 GIT_CURL_VERBOSE=1 git clone https://aeyakovenko@127.0.0.1/git
i get this as an error:
error: SSL: certificate subject name 'localhost' does not match target host name '127.0.0.1' (curl_result = 51, http_code = 0, sha1 = 4590de71622f1a90f906413fd7f63d5553cd5f93)
cloning https://aeyakovenko@localhost/git works fine
Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate
On Thu, 21 Feb 2008, Anatoly Yakovenko wrote:
Show 8 quoted lines
> $ GIT_SSL_NO_VERIFY=1 GIT_CURL_VERBOSE=1 git clone > https://aeyakovenko@127.0.0.1/git > > i get this as an error: > > error: SSL: certificate subject name 'localhost' does not match target > host name '127.0.0.1' (curl_result = 51, http_code = 0, sha1 = > 4590de71622f1a90f906413fd7f63d5553cd5f93)
That's the very problem Mike Hommey's recent patch addresses. Verifying a peer's certificate is done with two different libcurl options:
* VERIFYPEER verifies the server's certificate against a local CA cert bundle
* VERIFYHOST verifies that the name in the server certificate matches the host you're talking to
For this particular case, you can in fact also make it work by making sure the server's certificate has the IP address as a "subjectAltName".