Re: git:// protocol over SSL/TLS
On Fri, Dec 27, 2013 at 08:47:54PM +0600, Sergey Sharybin wrote: The web server software has nothing to do with HTTP[S] used by Git being smart, I think, it just has to be set up properly. Misunderstood git doc then which says it has to be Apache, currently - other CGI servers don't work, last I checked. Do you happen to remember where you saw that claim? If the manual in git's Documentation/ directory says that, I'd like to fix it. I added sample lighttpd config to git help http-backend a while back. I tested it at the time, but I do not currently run a lighttpd git server at all. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
On Fri, Dec 27, 2013 at 02:21:31PM -0800, Junio C Hamano wrote: Konstantin Khomoutov flatw...@users.sourceforge.net writes: The Git protocol does not implement it itself but you can channel it over a TLS tunnel (via stunnel for instance). Unfortunately, this means a specialized software and setup on both ends so if the question was about a general client using stock Git then the answer is no, it's impossible. Hmph, I somehow had an impression that you wouldn't need anything more complex than a simple helper that uses git-remote-ext on the client side. On the remote end, you'd need to have something that terminates the incoming SSL/TLS and plugs it to your git daemon. If you have some tool that can do cleartext I/O from stdin/stdout and establishes ciphertext connection itself, you can use it with git-remote-ext. It was written for cases exactly like that. To do git:// inside, use the %G pseudo-argument. -Ilari -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
Yeah, i understand this. We can not protect self from every single possible attack.. On Fri, Dec 27, 2013 at 10:26 PM, Bernhard R. Link brl+...@mail.brlink.eu wrote: * Sergey Sharybin sergey@gmail.com [131227 15:25]: Security in this case is about being sure everyone gets exactly the same repository as stored on the server, without any modifications to the sources cased by MITM. Note that ssl (and thus https) only helps here against a resource-less man-in-the-middle. Getting catch-all CA-signed certificates is said to no longer available to everyone as easily as it was some years ago, but unless you allow only one private CA (and even there clients often fail) you still should assume everyone resourceful enough to still be able to do MITM. Bernhard R. Link -- With best regards, Sergey Sharybin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git:// protocol over SSL/TLS
Hello everyone! Quick question is, is it possible to use git:// protocol over SSL/TLS/other secure transport? Or the recommended way to do secure anonymous checkout is to simply use https:// ? Thanks in advance! -- With best regards, Sergey Sharybin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
Sergey Sharybin sergey@gmail.com writes: Quick question is, is it possible to use git:// protocol over SSL/TLS/other secure transport? The git protocol itself performs no encryption or authentication by design. This is the job of the transport protocol. Or the recommended way to do secure anonymous checkout is to simply use https:// ? Yes. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
On Fri, 27 Dec 2013 18:59:00 +0600 Sergey Sharybin sergey@gmail.com wrote: Quick question is, is it possible to use git:// protocol over SSL/TLS/other secure transport? The Git protocol does not implement it itself but you can channel it over a TLS tunnel (via stunnel for instance). Unfortunately, this means a specialized software and setup on both ends so if the question was about a general client using stock Git then the answer is no, it's impossible. Or the recommended way to do secure anonymous checkout is to simply use https:// ? Yes, but it will only be secure if you've managed to verify the server's certificate and do trust its issuer (or a CA higher up the cert's trust chain) -- people tend to confuse encrypted with secure which is not at all the same thing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
Hi, On Fri, Dec 27, 2013 at 7:36 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: The Git protocol does not implement it itself but you can channel it over a TLS tunnel (via stunnel for instance). Unfortunately, this means a specialized software and setup on both ends so if the question was about a general client using stock Git then the answer is no, it's impossible. Ok, got it. Yes, but it will only be secure if you've managed to verify the server's certificate and do trust its issuer (or a CA higher up the cert's trust chain) -- people tend to confuse encrypted with secure which is not at all the same thing. We've got CA-signed certificate atm and it's about to be also EV-signed for our server (git.blender.org). So this is not gonna to be an issue. Cloning over https:// works fine, but we wanted to be sure all the bits are secure. So guess we just need to recommend using https:// protocol instead of git:// for our users? -- With best regards, Sergey Sharybin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
On Fri, 27 Dec 2013 19:58:19 +0600 Sergey Sharybin sergey@gmail.com wrote: [...] Yes, but it will only be secure if you've managed to verify the server's certificate and do trust its issuer (or a CA higher up the cert's trust chain) -- people tend to confuse encrypted with secure which is not at all the same thing. We've got CA-signed certificate atm and it's about to be also EV-signed for our server (git.blender.org). So this is not gonna to be an issue. Cloning over https:// works fine, but we wanted to be sure all the bits are secure. This setup sounds to be just the right thing. So guess we just need to recommend using https:// protocol instead of git:// for our users? I think yes. HTTP[S] once was dumb and slow but now it should be comparable in speed to git:// as essentially using this protocol (which became smart [1]) means spawning a git server process once per fetch/push session and making the client and server Git processes communicate all by themselves, so HTTP is there for request routing, authentication and session setup while data transfer is carried out by Git processes themselves [2]. 1. http://git-scm.com/blog/2010/03/04/smart-http.html 2. https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
On Fri, 27 Dec 2013 15:12:07 +0100 Andreas Schwab sch...@linux-m68k.org wrote: So guess we just need to recommend using https:// protocol instead of git:// for our users? Given how easy it is to verify the integrity of a git repository out of band there isn't really much of added security by using TLS for transport. If the devs employ signed tags then yes but otherwise you'd have to have some reference repository to compare with. Sure they target for a more no-brainer setup. ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
Our sysadmns are mainly worried about possible MITM which might give users completely wrong repo. For sure users might simply compare hash of HEAD from https'ed site with repo browser with what they've got in the checkout. But that's an extra step which we'd like to avoid without security harm :) On Fri, Dec 27, 2013 at 8:12 PM, Andreas Schwab sch...@linux-m68k.org wrote: Sergey Sharybin sergey@gmail.com writes: So guess we just need to recommend using https:// protocol instead of git:// for our users? Given how easy it is to verify the integrity of a git repository out of band there isn't really much of added security by using TLS for transport. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- With best regards, Sergey Sharybin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git:// protocol over SSL/TLS
-Original Message- From: Andreas Schwab Sent: Friday, December 27, 2013 9:12 AM Sergey Sharybin sergey@gmail.com writes: So guess we just need to recommend using https:// protocol instead of git:// for our users? Given how easy it is to verify the integrity of a git repository out of band there isn't really much of added security by using TLS for transport. I have to say, using encryption (TLS, etc) is not just for assurance of the communicating parties, but also to prevent a compromise of confidentiality. Jason Pyeron (please do not add me to the cc) smime.p7s Description: S/MIME cryptographic signature
Re: git:// protocol over SSL/TLS
Andreas Schwab sch...@linux-m68k.org writes: Sergey Sharybin sergey@gmail.com writes: So guess we just need to recommend using https:// protocol instead of git:// for our users? Given how easy it is to verify the integrity of a git repository out of band there isn't really much of added security by using TLS for transport. You can verify integrity after the fact, but not guarantee confidentiality ... so it again depends on the definition of security. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
Security in this case is about being sure everyone gets exactly the same repository as stored on the server, without any modifications to the sources cased by MITM. As for smart http, this seems pretty much cool.However, we're currently using lighthttpd, so it might be an issue. We'll check on whether smart http is used there, and if not guess it wouldn't be a big deal to switch to apache. On Fri, Dec 27, 2013 at 8:20 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Andreas Schwab sch...@linux-m68k.org writes: Sergey Sharybin sergey@gmail.com writes: So guess we just need to recommend using https:// protocol instead of git:// for our users? Given how easy it is to verify the integrity of a git repository out of band there isn't really much of added security by using TLS for transport. You can verify integrity after the fact, but not guarantee confidentiality ... so it again depends on the definition of security. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- With best regards, Sergey Sharybin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
Matthieu Moy matthieu@grenoble-inp.fr writes: You can verify integrity after the fact, but not guarantee confidentiality ... so it again depends on the definition of security. Since the OP is talking about anonymous access there is no need for confidentiality in this case. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
On Fri, 27 Dec 2013 20:25:16 +0600 Sergey Sharybin sergey@gmail.com wrote: Security in this case is about being sure everyone gets exactly the same repository as stored on the server, without any modifications to the sources cased by MITM. As for smart http, this seems pretty much cool.However, we're currently using lighthttpd, so it might be an issue. We'll check on whether smart http is used there, and if not guess it wouldn't be a big deal to switch to apache. The web server software has nothing to do with HTTP[S] used by Git being smart, I think, it just has to be set up properly. As discussed in an earlier thread here, a good indication of the dumb version of the protocol being in use is no display of the fetching progress on the client while doing `git clone` because this information (like compressing objects ... etc) is sent by the server-side Git process which is only there if HTTP[S] was smart. Otherwise the client just GETs packs of objects, traverses them, GETs more and so on, so batches of HTTP GET requests correlating to clone sessions in the web server logs should also be indicative of the problem. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
As for smart http, this seems pretty much cool.However, we're currently using lighthttpd, so it might be an issue. We'll check on whether smart http is used there, and if not guess it wouldn't be a big deal to switch to apache. The web server software has nothing to do with HTTP[S] used by Git being smart, I think, it just has to be set up properly. Misunderstood git doc then which says it has to be Apache, currently - other CGI servers don't work, last I checked. As discussed in an earlier thread here, a good indication of the dumb version of the protocol being in use is no display of the fetching progress on the client while doing `git clone` because this information (like compressing objects ... etc) is sent by the server-side Git process which is only there if HTTP[S] was smart. Otherwise the client just GETs packs of objects, traverses them, GETs more and so on, so batches of HTTP GET requests correlating to clone sessions in the web server logs should also be indicative of the problem. Just to verify, if i see messages like Receiving objects: 1% (7289/705777), 1.72 MiB | 340.00 KiB/s it means server is smart ? -- With best regards, Sergey Sharybin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
On Fri, 27 Dec 2013 20:47:54 +0600 Sergey Sharybin sergey@gmail.com wrote: [...] As discussed in an earlier thread here, a good indication of the dumb version of the protocol being in use is no display of the fetching progress on the client while doing `git clone` because this information (like compressing objects ... etc) is sent by the server-side Git process which is only there if HTTP[S] was smart. Otherwise the client just GETs packs of objects, traverses them, GETs more and so on, so batches of HTTP GET requests correlating to clone sessions in the web server logs should also be indicative of the problem. Just to verify, if i see messages like Receiving objects: 1% (7289/705777), 1.72 MiB | 340.00 KiB/s it means server is smart ? I would say yes, because your Git knows the precise number of objects to receive. Unfortunately, I won't swear by this as this was a long time ago I have seen cloning using the dumb protocol. By the way, here [1] is that discussion. 1. http://thread.gmane.org/gmane.comp.version-control.git/238933/focus=238946 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
* Sergey Sharybin sergey@gmail.com [131227 15:25]: Security in this case is about being sure everyone gets exactly the same repository as stored on the server, without any modifications to the sources cased by MITM. Note that ssl (and thus https) only helps here against a resource-less man-in-the-middle. Getting catch-all CA-signed certificates is said to no longer available to everyone as easily as it was some years ago, but unless you allow only one private CA (and even there clients often fail) you still should assume everyone resourceful enough to still be able to do MITM. Bernhard R. Link -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
Konstantin Khomoutov flatw...@users.sourceforge.net writes: On Fri, 27 Dec 2013 18:59:00 +0600 Sergey Sharybin sergey@gmail.com wrote: Quick question is, is it possible to use git:// protocol over SSL/TLS/other secure transport? The Git protocol does not implement it itself but you can channel it over a TLS tunnel (via stunnel for instance). Unfortunately, this means a specialized software and setup on both ends so if the question was about a general client using stock Git then the answer is no, it's impossible. Hmph, I somehow had an impression that you wouldn't need anything more complex than a simple helper that uses git-remote-ext on the client side. On the remote end, you'd need to have something that terminates the incoming SSL/TLS and plugs it to your git daemon. Or the recommended way to do secure anonymous checkout is to simply use https:// ? Yes, but it will only be secure if you've managed to verify the server's certificate and do trust its issuer (or a CA higher up the cert's trust chain) -- people tend to confuse encrypted with secure which is not at all the same thing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git:// protocol over SSL/TLS
On Fri, Dec 27, 2013 at 08:25:16PM +0600, Sergey Sharybin wrote: Security in this case is about being sure everyone gets exactly the same repository as stored on the server, without any modifications to the sources cased by MITM. Besides security, HTTPS is more likely to work across different firewalls and proxies, since odd ports like 9418 are often blocked and HTTPS usually isn't subject to the weirdness of proxies (since they can't inspect it or modify it). As for smart http, this seems pretty much cool.However, we're currently using lighthttpd, so it might be an issue. We'll check on whether smart http is used there, and if not guess it wouldn't be a big deal to switch to apache. You can use Lighttpd if you like. See Documentation/git-http-backend.txt (or git http-backend --help). -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
