{"thread":{"id":"34022","subject":"SNI (SSL virtual hosts)","startedAt":"2013-06-04T09:36:14Z","lastAt":"2013-06-05T06:58:07Z","messageCount":8,"participants":["Janusz Harkot","Daniel Stenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"219341","messageId":"97F8F367D27D4B3E93439FF8D0F121FA@gmail.com","threadId":"34022","inReplyTo":"DC851F5EA18E478DACB62178624BF5B7@gmail.com","subject":"SNI (SSL virtual hosts)","fromName":"Janusz Harkot","fromEmail":"janusz.harkot@gmail.com","sentAt":"2013-06-04T09:36:14Z","receivedAt":"2013-06-04T09:36:14Z","isPatch":false,"sender":{"key":"janusz.harkot@gmail.com","avatar":null},"body":"I was trying to to a push some repo over https and after few unsuccessful tries I've managed to find a problem - multiple virtual SSL servers on one IP address…\n\nStrange was, that initial communication was OK (http GET), but when there was http POST - git reported error (incorrect certificate).\nThe only workaround was to disable certificate verification.\n\nMy question is: does git support SNI on the https? If so - are there (undocumented) options to make it work?\n\n\n\nThanks!\nJanusz  \n"},{"id":"219342","messageId":"alpine.DEB.2.00.1306041142200.16303@tvnag.unkk.fr","threadId":"34022","inReplyTo":"97F8F367D27D4B3E93439FF8D0F121FA@gmail.com","subject":"Re: SNI (SSL virtual hosts)","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2013-06-04T09:45:26Z","receivedAt":"2013-06-04T09:45:26Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Tue, 4 Jun 2013, Janusz Harkot wrote:\n\n> Strange was, that initial communication was OK (http GET), but when there \n> was http POST - git reported error (incorrect certificate). The only \n> workaround was to disable certificate verification.\n>\n> My question is: does git support SNI on the https? If so - are there \n> (undocumented) options to make it work?\n\nIt does. git uses libcurl for the HTTPS parts and it has support SNI for a \nlong time, assuming you built libcurl with a TLS library that handles it.\n\nWhich libcurl version and SSL backend is this? (curl -V usually tells)\n\nIf you made it working by disabling certificate verification then it sounds as \nif SNI might still have worked and the problem was rahter something else, as \nwithout SNI you can't do name-based virtual hosting over HTTPS - but perhaps \nyou wanted to communicate with the \"default\" server on that IP?\n\n-- \n\n  / daniel.haxx.se\n"},{"id":"219344","messageId":"8B7A2C3A8CC346D6B34D153F591F878F@gmail.com","threadId":"34022","inReplyTo":"alpine.DEB.2.00.1306041142200.16303@tvnag.unkk.fr","subject":"Re: SNI (SSL virtual hosts)","fromName":"Janusz Harkot","fromEmail":"janusz.harkot@gmail.com","sentAt":"2013-06-04T10:19:54Z","receivedAt":"2013-06-04T10:19:54Z","isPatch":false,"sender":{"key":"janusz.harkot@gmail.com","avatar":null},"body":"> It does. git uses libcurl for the HTTPS parts and it has support SNI for a \n> long time, assuming you built libcurl with a TLS library that handles it.\n> \n> Which libcurl version and SSL backend is this? (curl -V usually tells)\n$ curl -V\ncurl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5\nProtocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp \nFeatures: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz \n\n$ otool -L /usr/local/bin/git\n/usr/local/bin/git:\n/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)\n/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)\n/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)\n/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)\n/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)\n\n\n\n> If you made it working by disabling certificate verification then it sounds as \n> if SNI might still have worked and the problem was rahter something else, as \n> without SNI you can't do name-based virtual hosting over HTTPS - but perhaps \n> you wanted to communicate with the \"default\" server on that IP?\n\nhere is a log (with GIT_CURL_VERBOSE=1)\n\nhttps://gist.github.com/anonymous/8f6533a755ae5c710c75 \n\nInitial connection is correct (line 10 - shows that it reads correct certificate),\n but then subsequent call to the server (line 68) shows that the defat server certificate is used.\n\nIt looks like the second call was without hostname (?).\n\nThanks!\nJanusz\n"},{"id":"219347","messageId":"alpine.DEB.2.00.1306041349290.32021@tvnag.unkk.fr","threadId":"34022","inReplyTo":"8B7A2C3A8CC346D6B34D153F591F878F@gmail.com","subject":"Re: SNI (SSL virtual hosts)","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2013-06-04T11:58:07Z","receivedAt":"2013-06-04T11:58:07Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Tue, 4 Jun 2013, Janusz Harkot wrote:\n\n>> Which libcurl version and SSL backend is this? (curl -V usually tells)\n> $ curl -V\n> curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r \n> zlib/1.2.5\n\n>From what I can tell, that OpenSSL version supports SNI fine and libcurl has \nsupported it since 7.18.1.\n\n> here is a log (with GIT_CURL_VERBOSE=1)\n>\n> https://gist.github.com/anonymous/8f6533a755ae5c710c75\n>\n> Initial connection is correct (line 10 - shows that it reads correct \n> certificate), but then subsequent call to the server (line 68) shows that \n> the defat server certificate is used.\n>\n> It looks like the second call was without hostname (?).\n\nWhat makes you suggest that's what's happening? Sure, if it would've sent no \nor the wrong host name it would probably have that effect.\n\nAny chance you can snoop on the network and the SSL handshake to see who's to \nblame? I can't but to think that is is a very common use case!\n\n-- \n\n  / daniel.haxx.se\n"},{"id":"219382","messageId":"CEC3E2C7A86A477DAC658432461A60BC@gmail.com","threadId":"34022","inReplyTo":"alpine.DEB.2.00.1306041349290.32021@tvnag.unkk.fr","subject":"Re: SNI (SSL virtual hosts)","fromName":"Janusz Harkot","fromEmail":"janusz.harkot@gmail.com","sentAt":"2013-06-04T16:59:52Z","receivedAt":"2013-06-04T16:59:52Z","isPatch":false,"sender":{"key":"janusz.harkot@gmail.com","avatar":null},"body":"> What makes you suggest that's what's happening? Sure, if it would've sent no  \n> or the wrong host name it would probably have that effect.\n\nline:\n\n[36] * Re-using existing connection! (#0) with host (nil)  \n> Any chance you can snoop on the network and the SSL handshake to see who's to  \n> blame? I can't but to think that is is a very common use case!\n\n\nI was trying to verify this via command line curl, and GET/POST is working fine.\n\nThere is one thing that make me suspicious - this is that message about SSL session expiration:\n[64] * SSL re-using session ID\n[65] * SSL connection using RC4-SHA\n[66] * old SSL session ID is stale, removing\n\n\n\nSo, I've spent last few hours playing with different settings/builds etc.  \nI was using sources of curl (7.30.0) and git (1.8.2.3)\n\ncurl & git bult with default os-x's openssl (0.9.8) - failed\ncurl & git bult with '--with-darwin-ssl' + default openssl for git - failed\n\ncurl & git both bult with newest openssl (1.0.1e):\nerror: SSL certificate problem: self signed certificate in certificate chain while accessing https://....\n\nso it looks promising, I've set GIT_SSL_CAPATH (because bundle config is not supported in git - this is a good feature request)\n\nand.. t looks like it is working…\nfirst and second attempt was to correct SNI host!\n\nSo, the question is still why it is not working with openssl 0.9.8r - this version supports SNI by default.\nThis looks like an error in openssl (maybe: Only allow one SGC handshake restart for SSL/TLS.)\n\nNow is the question, shall this be handled by curl or left alone?\n(handling older version of openssl, and force new ssl session?)\n\n\nkind regards,\nJanusz\n\n\np.s.\nI've tested cur built with polarssl - works and gnutls - works too...\n"},{"id":"219411","messageId":"alpine.DEB.2.00.1306042305300.2878@tvnag.unkk.fr","threadId":"34022","inReplyTo":"CEC3E2C7A86A477DAC658432461A60BC@gmail.com","subject":"Re: SNI (SSL virtual hosts)","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2013-06-04T21:18:27Z","receivedAt":"2013-06-04T21:18:27Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Tue, 4 Jun 2013, Janusz Harkot wrote:\n\n>> What makes you suggest that's what's happening? Sure, if it would've sent no\n>> or the wrong host name it would probably have that effect.\n>\n> line:\n>\n> [36] * Re-using existing connection! (#0) with host (nil)\n\nAh that. Yes, that's a stupid line to show (that bug has been fixed since). \nBut if you look further down your log you see that the connection which is \nre-used according to that log line gets closed anyway.\n\n> it looks like it is working\n\nAwesome!\n\n> So, the question is still why it is not working with openssl 0.9.8r - this \n> version supports SNI by default. This looks like an error in openssl (maybe: \n> Only allow one SGC handshake restart for SSL/TLS.)\n\nRight. As you can see in the libcurl code it activates SNI for OpenSSL the \nexact same way independently of what version that's used.\n\n> Now is the question, shall this be handled by curl or left alone? (handling \n> older version of openssl, and force new ssl session?)\n\nI'm not even completely convinced this is \"just\" an old-OpenSSL-problem. If \nthat version you're using is the one Apple has provided, there's the risk that \nthe problem is rather caused by their changes!\n\nI'm reluctant to globally switch off session-id caching for OpenSSL 0.9.8 \nusers since that feature has been used for over 8 years in the code and you're \nthe first to have a problem with it! =-/\n\n-- \n\n  / daniel.haxx.se\n"},{"id":"219415","messageId":"630928524B6441DC907D7AFF34389010@gmail.com","threadId":"34022","inReplyTo":"alpine.DEB.2.00.1306042305300.2878@tvnag.unkk.fr","subject":"Re: SNI (SSL virtual hosts)","fromName":"Janusz Harkot","fromEmail":"janusz.harkot@gmail.com","sentAt":"2013-06-04T21:26:51Z","receivedAt":"2013-06-04T21:26:51Z","isPatch":false,"sender":{"key":"janusz.harkot@gmail.com","avatar":null},"body":"valid point, but from what you can find on the web, the only solution provided everywhere was to\ndisable certificate checking… so maybe that's not me, but this is first time someone spent\nsome time to check whats going on :)\n\nat least there will be something, maybe this will help someone…\n\nthanks Daniel!\n\n\nbest!\nJanusz\n\n\n\n\n\n\n\n\nOn Tuesday, 4 June 2013 at 23:18, Daniel Stenberg wrote:\n\n> On Tue, 4 Jun 2013, Janusz Harkot wrote:\n>  \n> > > What makes you suggest that's what's happening? Sure, if it would've sent no\n> > > or the wrong host name it would probably have that effect.\n> >  \n> >  \n> >  \n> > line:\n> >  \n> > [36] * Re-using existing connection! (#0) with host (nil)\n>  \n> Ah that. Yes, that's a stupid line to show (that bug has been fixed since).  \n> But if you look further down your log you see that the connection which is  \n> re-used according to that log line gets closed anyway.\n>  \n> > it looks like it is working\n>  \n> Awesome!\n>  \n> > So, the question is still why it is not working with openssl 0.9.8r - this  \n> > version supports SNI by default. This looks like an error in openssl (maybe:  \n> > Only allow one SGC handshake restart for SSL/TLS.)\n>  \n>  \n>  \n> Right. As you can see in the libcurl code it activates SNI for OpenSSL the  \n> exact same way independently of what version that's used.\n>  \n> > Now is the question, shall this be handled by curl or left alone? (handling  \n> > older version of openssl, and force new ssl session?)\n>  \n>  \n>  \n> I'm not even completely convinced this is \"just\" an old-OpenSSL-problem. If  \n> that version you're using is the one Apple has provided, there's the risk that  \n> the problem is rather caused by their changes!\n>  \n> I'm reluctant to globally switch off session-id caching for OpenSSL 0.9.8  \n> users since that feature has been used for over 8 years in the code and you're  \n> the first to have a problem with it! =-/\n>  \n> --  \n>  \n> / daniel.haxx.se (http://daniel.haxx.se)\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org (mailto:majordomo@vger.kernel.org)\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"219437","messageId":"alpine.DEB.2.00.1306050851210.4783@tvnag.unkk.fr","threadId":"34022","inReplyTo":"630928524B6441DC907D7AFF34389010@gmail.com","subject":"Re: SNI (SSL virtual hosts)","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2013-06-05T06:58:07Z","receivedAt":"2013-06-05T06:58:07Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Tue, 4 Jun 2013, Janusz Harkot wrote:\n\n> valid point, but from what you can find on the web, the only solution \n> provided everywhere was to disable certificate checking… so maybe that's not \n> me, but this is first time someone spent some time to check whats going on \n> :)\n\nI don't disagree with that. You may be right.\n\nBut I am the maintainer of libcurl and I have *never* gotten a report about \nthis before, and I rather base my actions and assumptions on true reports from \nactual developers with whom I can discuss and delve into details with (like \nyou and me right now). Basing decisions on vague statements posted elsewhere \nby unknown people is for sure a road into sadness.\n\nAnyway, now I'm off topic. I'm glad you could fix the problem. Thanks for \nflying git + libcurl! =)\n\n-- \n\n  / daniel.haxx.se"}]}