3 ms·

Turning off unencrypted raw git protocol will be a pain. I generally use that for grabbing stuff for inspection & evaluation as on a number of my machines, htt

Turning off unencrypted raw git protocol will be a pain. I generally use that for grabbing stuff for inspection & evaluation as on a number of my machines, https protocol does not work (seemingly due to only supporting older versions of TLS). I have not upgraded those machines for 'reasons'. It can be worked around by grabbing on a newer machine, then cloning from there, but that is extra hassle. Ho hum. (Given the Merkle hash format of the git repo's, there is really little or no need for an encrypted connection when fetching from a public repo).

aseipp 5y ago
As usual the problem is MITM. Any clone for git://github.com/foo/bar.git can easily be intercepted to git://github.com/evil-foo/evil-baz.git, or fetch, etc. The middleman can also do freeze attacks (i.e. prevent 'git fetch' from ever succeeding) and other such things. Almost all git workflows implicitly assume that both A) the upstream is 'correct' and therefore trusted. A corollary of this is that B) the transport to that upstream must also be secure, so you are sure it really is the upstream you wanted. A merkle tree is only useful after this chain of trust is established. The only exception is if you know the commit hash a priori perhaps, and fetch that explicitly. But you often don't; even assuming most Git/GitHub workflows did know that, you're just passing the buck because to verify that commit hash is authentic you have to use some other secure channel, and that's often HTTPS.
- dfawcus 5y ago
  Actually it is trivial to prove it was correct. My workflow was to look at the site with a web browser (with working up to date TLS), and note the hash of the final commit of master. This can be done on a different machine. Then one clones the repo from the non https capable machine, and verifies the hash for the tip of master. Rinse and repeat for any other branches of interest, especially if only performing a limited clone.
  - dfawcus 5y ago
    Now the sadly amusing aspect of all this is that I only noticed the https issue in the first place, because I'd previously cloned some repos on the machine using it. Then some time later when doing a fetch, I received a TLS nego rejection complaint. Github had turned off support or earlier versions TLS, and the machine in question did not implement the later version. (I believe this was on an old macOS version). So as a workaround, I altered the refspec in the git config file to switch to using the raw git protocol. i.e. their earlier 'improve security' measure drove me to switch to the 'improved' unencrypted git protocol. :-)
  - zaarn 5y ago
    Except git uses sha1 for those. Additionally unless you verify the ENTIRE hash not just 6 characters, it's trivial to brute force specific hashes into git. I myself have committed with a hash of 0000000 into a git repository twice, meaning it is easy to confuse those two commits. An attacker would merely have to brute force the tip of their attacker repository, a matter which you can do within the hour on a stock standard PC.
    - yc12340 5y ago
      > An attacker would merely have to brute force the tip of their attacker repository, a matter which you can do within the hour So you think, that you can do so in a hour? How much are you willing to bet on that? For bonus points try to "brute force a tip" for repository, containing actual contents (as opposite to randomly named binary files with gibberish).
      - Genbox 5y ago
        Not sure what you are asking, but it is trivially easy to fake a git short hash to whatever you like. I cloned this repo: https://github.com/bradfitz/gitbrute https://github.com/bradfitz/gitbrute Ran the command in the readme (had to do it twice for some reason) and the latest commit is now 000001 on my fork of the repo: https://github.com/Genbox/gitbrute/commit/0000019075dabc337f38baa425bb6957f5fbfdfa https://github.com/Genbox/gitbrute/commit/0000019075dabc337f... It took less than 3 minutes for the full thing.
        dfawcus 5y ago
        My example was using cut'n'paste, then cmp, so the full 40 char hash. I don't try comparing those things manually. As I said trivial to prove valid; and since I was actually reading, using, and compiling the code, quite difficult to achieve a collision in the circumstances.
        zaarn 5y ago
        Then just fake the first and last characters, not much of an additional challenge, few people compare all characters, they compare the first and last few. I bet that would have even caught you unaware in some moments.
mnarayan01 5y ago
Git has all sorts of options for using proxies, but running socat would be the quick and dirty way to do this, something like: socat TCP-LISTEN:8080,fork,reuseaddr OPENSSL:github.com:443 would let you use an HTTP connection to your less archaic machine. Could even configure git to automatically do the rewrite similar to https://stackoverflow.com/questions/1722807/how-to-convert-git-urls-to-http-urls https://stackoverflow.com/questions/1722807/how-to-convert-g.... There's security considerations here so don't just do this blindly, but if no more unencrypted git protocol is a real pain point there's pain free ways around it.
- dfawcus 5y ago
  Potentially useful, since I've used proxies before in a different manner. However what I'm more inclined to do is simply compile up a version of git from source, ensure it includes the HTTPS transport, and links against an appropriate TLS/SSL library. I used to build it from source years ago (on a different platform). The git protocol approach was simply to avoid that hassle, as used correctly it is safe enough.

aseipp 5y ago

As usual the problem is MITM. Any clone for git://github.com/foo/bar.git can easily be intercepted to git://github.com/evil-foo/evil-baz.git, or fetch, etc. The middleman can also do freeze attacks (i.e. prevent 'git fetch' from ever succeeding) and other such things. Almost all git workflows implicitly assume that both A) the upstream is 'correct' and therefore trusted. A corollary of this is that B) the transport to that upstream must also be secure, so you are sure it really is the upstream you wanted. A merkle tree is only useful after this chain of trust is established. The only exception is if you know the commit hash a priori perhaps, and fetch that explicitly. But you often don't; even assuming most Git/GitHub workflows did know that, you're just passing the buck because to verify that commit hash is authentic you have to use some other secure channel, and that's often HTTPS.

dfawcus 5y ago
Actually it is trivial to prove it was correct. My workflow was to look at the site with a web browser (with working up to date TLS), and note the hash of the final commit of master. This can be done on a different machine. Then one clones the repo from the non https capable machine, and verifies the hash for the tip of master. Rinse and repeat for any other branches of interest, especially if only performing a limited clone.
- dfawcus 5y ago
  Now the sadly amusing aspect of all this is that I only noticed the https issue in the first place, because I'd previously cloned some repos on the machine using it. Then some time later when doing a fetch, I received a TLS nego rejection complaint. Github had turned off support or earlier versions TLS, and the machine in question did not implement the later version. (I believe this was on an old macOS version). So as a workaround, I altered the refspec in the git config file to switch to using the raw git protocol. i.e. their earlier 'improve security' measure drove me to switch to the 'improved' unencrypted git protocol. :-)
- zaarn 5y ago
  Except git uses sha1 for those. Additionally unless you verify the ENTIRE hash not just 6 characters, it's trivial to brute force specific hashes into git. I myself have committed with a hash of 0000000 into a git repository twice, meaning it is easy to confuse those two commits. An attacker would merely have to brute force the tip of their attacker repository, a matter which you can do within the hour on a stock standard PC.
  - yc12340 5y ago
    > An attacker would merely have to brute force the tip of their attacker repository, a matter which you can do within the hour So you think, that you can do so in a hour? How much are you willing to bet on that? For bonus points try to "brute force a tip" for repository, containing actual contents (as opposite to randomly named binary files with gibberish).
    - Genbox 5y ago
      Not sure what you are asking, but it is trivially easy to fake a git short hash to whatever you like. I cloned this repo: https://github.com/bradfitz/gitbrute https://github.com/bradfitz/gitbrute Ran the command in the readme (had to do it twice for some reason) and the latest commit is now 000001 on my fork of the repo: https://github.com/Genbox/gitbrute/commit/0000019075dabc337f38baa425bb6957f5fbfdfa https://github.com/Genbox/gitbrute/commit/0000019075dabc337f... It took less than 3 minutes for the full thing.
      - dfawcus 5y ago
        My example was using cut'n'paste, then cmp, so the full 40 char hash. I don't try comparing those things manually. As I said trivial to prove valid; and since I was actually reading, using, and compiling the code, quite difficult to achieve a collision in the circumstances.
        zaarn 5y ago
        Then just fake the first and last characters, not much of an additional challenge, few people compare all characters, they compare the first and last few. I bet that would have even caught you unaware in some moments.

mnarayan01 5y ago

Git has all sorts of options for using proxies, but running socat would be the quick and dirty way to do this, something like: socat TCP-LISTEN:8080,fork,reuseaddr OPENSSL:github.com:443 would let you use an HTTP connection to your less archaic machine. Could even configure git to automatically do the rewrite similar to https://stackoverflow.com/questions/1722807/how-to-convert-git-urls-to-http-urls https://stackoverflow.com/questions/1722807/how-to-convert-g.... There's security considerations here so don't just do this blindly, but if no more unencrypted git protocol is a real pain point there's pain free ways around it.

dfawcus 5y ago
Potentially useful, since I've used proxies before in a different manner. However what I'm more inclined to do is simply compile up a version of git from source, ensure it includes the HTTPS transport, and links against an appropriate TLS/SSL library. I used to build it from source years ago (on a different platform). The git protocol approach was simply to avoid that hassle, as used correctly it is safe enough.