5 ms·

git:// is not just unauthenticated, but unencrypted on the wire. They want you to use https:// https:// for unauthenticated clones to at least prevent MITMs.

by judge2020 5y ago

vermilingua 5y ago
Doesn’t git:// transport use SSH? How is SSH possibly unencrypted on the wire?
- otherjason 5y ago
  No. From https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...: > Finally, we have the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create a git-daemon-export-ok file — the daemon won’t serve a repository without that file in it — but, other than that, there is no security. Either the Git repository is available for everyone to clone, or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access but, given the lack of authentication, anyone on the internet who finds your project’s URL could push to that project. Suffice it to say that this is rare.
  - bin_bash 5y ago
    I was also under the incorrect impression that git:// was just an alias for ssh. It's amazing how long you can use something and still not understand how it works.
    - progmetaldev 5y ago
      Don't worry, when I first started reading I was under the same impression. git:// and git@ are so close to each other, it was easy to misunderstand.
    - ziml77 5y ago
      I thought the same thing! I didn't expect git to have a way to communicate unauthenticated and unencrypted built-in.
      - DarylZero 5y ago
        It's also possible to simply set the `$GIT_SSH` environment variable or `core.sshCommand` config option to an unencrypted shell like `rsh`
- deleted 5y ago
  [deleted]
- rgoulter 5y ago
  I think you're thinking of the URLs like git@github.com:<owner>/<repo>.git
  - idsout 5y ago
    I was. Thanks for the clarification.
- tialaramex 5y ago
  > How is SSH possibly unencrypted on the wire? Not really a practical answer, as your SSH client doesn't (and shouldn't) offer this, but of course the rest of the SSH protocol just relies on a negotiated arbitrary encryption for moving data between client and server which is transparent to it, you can drop in different algorithms (on most PCs today AES will be the best option because it is hardware accelerated, on cheaper or lower power hardware ChaCha20 may be much better). So, it is technically possible to have a NO-OP encryption layer but just a bad idea. SSHv2 negotiates this stuff up front, before anybody authenticates anywhere. Key Agreement protocols like Diffie-Hellman allow two parties to agree over the network on keys and encrypt all their data even though they don't yet know who the other party is, and in SSH the encryption protocols just have string names like chacha20-poly1305@openssh.com so you could invent useless-empty@example.com and if anybody wants to agree to use that the consequences are on them.
  - rsync 5y ago
    "So, it is technically possible to have a NO-OP encryption layer but just a bad idea." Not just technically possible - it actually exists. There is a NONE cipher that is part of the HPN-SSH patches, etc.: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/ https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/ "The NONE cipher switch disables data encryption AFTER you have been authenticated or logged into the remote host. This can significantly reduce the load on the CPUs of both machines and may improve performance even more. Its important to remember that the initial authentication process is still fully encrypted." If we're sending data over a private point-to-point link we always consider the NONE cipher ... especially if the underlying data was created by borg or restic anyway ...
tialaramex 5y ago
And in consequence although many people will experience it no longer working, it might still "work" for you (or it might never have "worked") since anybody who is between you and GitHub can decide what happens instead. If you've insisted on building something that insists on using git:// this way, you can proxy it to the safer supported system seamlessly, since you had no way to know before it was correct and you'll have no way to know if the proxy worked either. Somebody might already make a tool to do that, if not you could roll your own.
- WorldMaker 5y ago
  Git itself has a config flag to tell it to always use https:// https:// instead of git://. It's often been recommended for Windows users of git as sometimes the only way out of some peculiar submodule holes (on a platform where SSH was a second class citizen for many decades). git config --global url."https://".insteadOf https://".insteadOf git:// There are versions of that config line more specific to individual hosts if you didn't want to blanked cover every git host, but it's probably a good idea at this point to instead ask those other hosts if they would consider adding https:// https:// support.
u801e 5y ago
I've read that for fetching and pushing, the http protocol is less efficient compared to the git protocol. Could a remote helper be used to establish a TLS connection to the server and use the git protocol over that connection?
- zozbot234 5y ago
  > I've read that for fetching and pushing, the http protocol is less efficient compared to the git protocol. This was true in the past, but the newer "smart" http protocol has content negotiation similar to the git and ssh protocols.
superkuh 5y ago
Like most crimes, the biggest and most common dangers come from the people/software you already know. It's going to be a company's profit incentive or a lone dev's hissy fit expressed through softare you implicitly trust that gets you. Unencrypted internet transfers have worked and will continue to work for a very long time with very few problems for the vast majority of people. Requiring encryption might be okay, but requiring CA based TLS is not okay. It is another strong force of centralization and shortly thereafter, control. http is fine. git:// is fine. TLS CA based git and https are great. But CA TLS only to "fix" the problem introduces more security problems than it fixes.
- purkka 5y ago
  If you're using GitHub, you've already centralized. git:// support is not being removed from Git or self-hosted repos of any kind.
  - superkuh 5y ago
    https://indieweb.org/POSSE https://indieweb.org/POSSE > POSSE is an abbreviation for Publish (on your) Own Site, Syndicate Elsewhere, the practice of posting content on your own site first, then publishing copies or sharing links to third parties (like social media silos) with original post links to provide viewers a path to directly interacting with your content.
  - CRConrad 5y ago
    > git:// support is not being removed from Git or self-hosted repos of any kind. ...quite yet. Because that's the third 'E' in the strategy, and they're not quite finished with the second one.
- piaste 5y ago
  > Requiring encryption might be okay, but requiring CA based TLS is not okay. It is another strong force of centralization and shortly thereafter, control. CA-based TLS is a requirement that a client can enforce on the servers, not viceversa (except for client certificates which are obviously not the case here). When a server (Github in this case) chooses to acquire a CA-based TLS, the client isn't forced to depend on the CA in any way - it can even choose not to verify the certificate authenticity. If the official git implementation started requiring TLS, thus forcing free private git servers (including your personal selfhosted gitea or whatever) to centralize under a recognized root CA, then your comment would make sense.
DarylZero 5y ago
github is a MITM, so not exactly.

git:// is not just unauthenticated, but unencrypted on the wire. They want you to use https:// https:// for unauthenticated clones to at least prevent MITMs.

vermilingua 5y ago

Doesn’t git:// transport use SSH? How is SSH possibly unencrypted on the wire?

otherjason 5y ago
No. From https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...: > Finally, we have the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create a git-daemon-export-ok file — the daemon won’t serve a repository without that file in it — but, other than that, there is no security. Either the Git repository is available for everyone to clone, or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access but, given the lack of authentication, anyone on the internet who finds your project’s URL could push to that project. Suffice it to say that this is rare.
- bin_bash 5y ago
  I was also under the incorrect impression that git:// was just an alias for ssh. It's amazing how long you can use something and still not understand how it works.
  - progmetaldev 5y ago
    Don't worry, when I first started reading I was under the same impression. git:// and git@ are so close to each other, it was easy to misunderstand.
  - ziml77 5y ago
    I thought the same thing! I didn't expect git to have a way to communicate unauthenticated and unencrypted built-in.
    - DarylZero 5y ago
      It's also possible to simply set the `$GIT_SSH` environment variable or `core.sshCommand` config option to an unencrypted shell like `rsh`
deleted 5y ago
[deleted]
rgoulter 5y ago
I think you're thinking of the URLs like git@github.com:<owner>/<repo>.git
- idsout 5y ago
  I was. Thanks for the clarification.
tialaramex 5y ago
> How is SSH possibly unencrypted on the wire? Not really a practical answer, as your SSH client doesn't (and shouldn't) offer this, but of course the rest of the SSH protocol just relies on a negotiated arbitrary encryption for moving data between client and server which is transparent to it, you can drop in different algorithms (on most PCs today AES will be the best option because it is hardware accelerated, on cheaper or lower power hardware ChaCha20 may be much better). So, it is technically possible to have a NO-OP encryption layer but just a bad idea. SSHv2 negotiates this stuff up front, before anybody authenticates anywhere. Key Agreement protocols like Diffie-Hellman allow two parties to agree over the network on keys and encrypt all their data even though they don't yet know who the other party is, and in SSH the encryption protocols just have string names like chacha20-poly1305@openssh.com so you could invent useless-empty@example.com and if anybody wants to agree to use that the consequences are on them.
- rsync 5y ago
  "So, it is technically possible to have a NO-OP encryption layer but just a bad idea." Not just technically possible - it actually exists. There is a NONE cipher that is part of the HPN-SSH patches, etc.: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/ https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/ "The NONE cipher switch disables data encryption AFTER you have been authenticated or logged into the remote host. This can significantly reduce the load on the CPUs of both machines and may improve performance even more. Its important to remember that the initial authentication process is still fully encrypted." If we're sending data over a private point-to-point link we always consider the NONE cipher ... especially if the underlying data was created by borg or restic anyway ...

tialaramex 5y ago

And in consequence although many people will experience it no longer working, it might still "work" for you (or it might never have "worked") since anybody who is between you and GitHub can decide what happens instead. If you've insisted on building something that insists on using git:// this way, you can proxy it to the safer supported system seamlessly, since you had no way to know before it was correct and you'll have no way to know if the proxy worked either. Somebody might already make a tool to do that, if not you could roll your own.

WorldMaker 5y ago
Git itself has a config flag to tell it to always use https:// https:// instead of git://. It's often been recommended for Windows users of git as sometimes the only way out of some peculiar submodule holes (on a platform where SSH was a second class citizen for many decades). git config --global url."https://".insteadOf https://".insteadOf git:// There are versions of that config line more specific to individual hosts if you didn't want to blanked cover every git host, but it's probably a good idea at this point to instead ask those other hosts if they would consider adding https:// https:// support.

u801e 5y ago

I've read that for fetching and pushing, the http protocol is less efficient compared to the git protocol. Could a remote helper be used to establish a TLS connection to the server and use the git protocol over that connection?

zozbot234 5y ago
> I've read that for fetching and pushing, the http protocol is less efficient compared to the git protocol. This was true in the past, but the newer "smart" http protocol has content negotiation similar to the git and ssh protocols.

superkuh 5y ago

Like most crimes, the biggest and most common dangers come from the people/software you already know. It's going to be a company's profit incentive or a lone dev's hissy fit expressed through softare you implicitly trust that gets you. Unencrypted internet transfers have worked and will continue to work for a very long time with very few problems for the vast majority of people. Requiring encryption might be okay, but requiring CA based TLS is not okay. It is another strong force of centralization and shortly thereafter, control. http is fine. git:// is fine. TLS CA based git and https are great. But CA TLS only to "fix" the problem introduces more security problems than it fixes.

purkka 5y ago
If you're using GitHub, you've already centralized. git:// support is not being removed from Git or self-hosted repos of any kind.
- superkuh 5y ago
  https://indieweb.org/POSSE https://indieweb.org/POSSE > POSSE is an abbreviation for Publish (on your) Own Site, Syndicate Elsewhere, the practice of posting content on your own site first, then publishing copies or sharing links to third parties (like social media silos) with original post links to provide viewers a path to directly interacting with your content.
- CRConrad 5y ago
  > git:// support is not being removed from Git or self-hosted repos of any kind. ...quite yet. Because that's the third 'E' in the strategy, and they're not quite finished with the second one.
piaste 5y ago
> Requiring encryption might be okay, but requiring CA based TLS is not okay. It is another strong force of centralization and shortly thereafter, control. CA-based TLS is a requirement that a client can enforce on the servers, not viceversa (except for client certificates which are obviously not the case here). When a server (Github in this case) chooses to acquire a CA-based TLS, the client isn't forced to depend on the CA in any way - it can even choose not to verify the certificate authenticity. If the official git implementation started requiring TLS, thus forcing free private git servers (including your personal selfhosted gitea or whatever) to centralize under a recognized root CA, then your comment would make sense.

DarylZero 5y ago

github is a MITM, so not exactly.