4 ms·

Everyone should standardize on HTTPS to pull repositories instead of plain (non-certificate) SSH. A username and password (often called an API token) are used i

Everyone should standardize on HTTPS to pull repositories instead of plain (non-certificate) SSH. A username and password (often called an API token) are used instead of an SSH key. - An SSH key can be revoked on the server, but the client won't register it immediately, and all clients must manually verify the new key signature and update their local configuration. This doesn't happen with HTTPS; the client just works with the server's new cert, no user intervention is required. - A username can be used in the HTTPS URI to tell both your client and the server what credential to use. SSH method requires the user to load the correct SSH key first. - Most servers like GitHub allow more fine grained access control for HTTPS tokens than SSH keys. - HTTPS access method works on all HTTP proxies, whereas SSH is often blocked. - HTTPS can be faster than SSH. - HTTPS allows a client and server to use specific ciphers to address regulatory and other requirements. - HTTPS tokens are supported in a wider range of password managers/keychains than SSH keys. - Most users don't password protect their SSH keys, but they often have a password manager with a master password that they can keep HTTPS token in. - SSH key management is much more complex on the user end than HTTPS token management. The former requires ssh-agent, a key generator, and instructions for use, as well as specific filesystem permissions for keys. - The user often doesn't understand the idea that they shouldn't share their private key. But everyone basically gets they shouldn't share their password. - Virtually no one ever checks the fingerprint of ssh server keys. Often entire companies have configuration that disables host key checking, completely eliminating the security SSH is supposed to provide. With HTTPS the user is implicitly protected with no actions necessary. - Nobody ever commits a private TLS key to a GitHub repo, but apparently they do with SSH private keys...

organman91 4y ago
> Nobody ever commits a private TLS key to a GitHub repo Oh how I wish this were true...
xign 4y ago
> - Most users don't password protect their SSH keys, but they often have a password manager with a master password that they can keep HTTPS token in. Are there password managers that actually seamlessly do that? GitHub's official docs (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#using-a-personal-access-token-on-the-command-line https://docs.github.com/en/authentication/keeping-your-accou...) for example recommends using the GitHub CLI to cache your authentication token for you and as far as I can tell the token is stored unencrypted (https://github.com/cli/cli/issues/1773 https://github.com/cli/cli/issues/1773), unlike SSH keys which should be encrypted behind a password. If you don't do this you have to enter your password every single time you use you Git, which is not good even if you have a password manager (it adds steps, and passwords aren't great to begin with because you send them in plain text to the server and it is why Apple etc are moving away from password-based authentication for websites). > - Nobody ever commits a private TLS key to a GitHub repo, but apparently they do with SSH private keys... I think the key issue here is this really shouldn't have happened. There is no reason why GitHub couldn't secure their SSH private key just like their TLS key. --- Edit: Thinking more about it, I think the situation would have been much worse if GitHub leaked a TLS key instead. With SSH, an attacker who stole GitHub's private SSH key actually *cannot* MITM the user. They can pretend to be GitHub to the user, but they cannot pretend to be the user to GitHub, because with SSH both sides have a private/public key known to the other side. In a normal usage scenario, it would actually take some social engineering to do a real attack, because a simple Git fetch from the attacker would fail when trying to fetch a private repo (since the attacker does not have the permission to fetch it from GitHub). With HTTPS, under current setups of username/password or an auth token, the user has no real way to protect themselves from a MITM attack. The token isn't a private key as it's shared directly to the server. That means the attack could actually MITM the server/user connection and do much much more damage.

organman91 4y ago

> Nobody ever commits a private TLS key to a GitHub repo Oh how I wish this were true...

xign 4y ago

> - Most users don't password protect their SSH keys, but they often have a password manager with a master password that they can keep HTTPS token in. Are there password managers that actually seamlessly do that? GitHub's official docs (https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#using-a-personal-access-token-on-the-command-line https://docs.github.com/en/authentication/keeping-your-accou...) for example recommends using the GitHub CLI to cache your authentication token for you and as far as I can tell the token is stored unencrypted (https://github.com/cli/cli/issues/1773 https://github.com/cli/cli/issues/1773), unlike SSH keys which should be encrypted behind a password. If you don't do this you have to enter your password every single time you use you Git, which is not good even if you have a password manager (it adds steps, and passwords aren't great to begin with because you send them in plain text to the server and it is why Apple etc are moving away from password-based authentication for websites). > - Nobody ever commits a private TLS key to a GitHub repo, but apparently they do with SSH private keys... I think the key issue here is this really shouldn't have happened. There is no reason why GitHub couldn't secure their SSH private key just like their TLS key. --- Edit: Thinking more about it, I think the situation would have been much worse if GitHub leaked a TLS key instead. With SSH, an attacker who stole GitHub's private SSH key actually *cannot* MITM the user. They can pretend to be GitHub to the user, but they cannot pretend to be the user to GitHub, because with SSH both sides have a private/public key known to the other side. In a normal usage scenario, it would actually take some social engineering to do a real attack, because a simple Git fetch from the attacker would fail when trying to fetch a private repo (since the attacker does not have the permission to fetch it from GitHub). With HTTPS, under current setups of username/password or an auth token, the user has no real way to protect themselves from a MITM attack. The token isn't a private key as it's shared directly to the server. That means the attack could actually MITM the server/user connection and do much much more damage.