# GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate 9 messages from 2008-02-20 to 2008-02-22. Participants: Anatoly Yakovenko, Mike Hommey, Daniel Stenberg, Junio C Hamano. Thread: https://gitlist.dev/t/12228 ## Anatoly Yakovenko, 2008-02-20 23:35 Subject: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate Message-ID: URL: https://gitlist.dev/e/e26d18e40802201535s7a5c12fbtd61d2445426f4018%40mail.gmail.com ``` 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. ``` ## Mike Hommey, 2008-02-21 06:42 Subject: Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate Message-ID: <20080221064252.GA16036@glandium.org> URL: https://gitlist.dev/e/20080221064252.GA16036%40glandium.org In-Reply-To: ``` 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 ``` ## Anatoly Yakovenko, 2008-02-21 18:57 Subject: Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate Message-ID: URL: https://gitlist.dev/e/e26d18e40802211057o255246f3p31800c73eb8391ec%40mail.gmail.com In-Reply-To: <20080221064252.GA16036@glandium.org> ``` 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 wrote: > > 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 > ``` ## Daniel Stenberg, 2008-02-21 19:04 Subject: Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0802212003140.14691%40yvahk3.pbagnpgbe.fr In-Reply-To: ``` 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 ``` ## Mike Hommey, 2008-02-21 19:09 Subject: Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate Message-ID: <20080221190954.GA24759@glandium.org> URL: https://gitlist.dev/e/20080221190954.GA24759%40glandium.org In-Reply-To: ``` 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 ``` ## Mike Hommey, 2008-02-21 19:23 Subject: [PATCH] Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set Message-ID: <1203621790-1415-1-git-send-email-mh@glandium.org> URL: https://gitlist.dev/e/1203621790-1415-1-git-send-email-mh%40glandium.org In-Reply-To: ``` Signed-off-by: Mike Hommey --- 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 ``` ## Junio C Hamano, 2008-02-21 23:10 Subject: Re: [PATCH] Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set Message-ID: <7vd4qpsy6q.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vd4qpsy6q.fsf%40gitster.siamese.dyndns.org In-Reply-To: <1203621790-1415-1-git-send-email-mh@glandium.org> ``` Mike Hommey writes: > Signed-off-by: Mike Hommey > --- > 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 ``` ## Anatoly Yakovenko, 2008-02-22 01:27 Subject: Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate Message-ID: URL: https://gitlist.dev/e/e26d18e40802211727w4f7f5b37vc73a756f6b384289%40mail.gmail.com In-Reply-To: <20080221190954.GA24759@glandium.org> ``` On Thu, Feb 21, 2008 at 11:09 AM, Mike Hommey wrote: > 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 ``` ## Daniel Stenberg, 2008-02-22 10:53 Subject: Re: GIT_SSL_NO_VERIFY=1 over http doesn't ignore a different ip address for the signed certificate Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0802221149210.13958%40yvahk3.pbagnpgbe.fr In-Reply-To: ``` On Thu, 21 Feb 2008, Anatoly Yakovenko wrote: > $ 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". ```