Git Connections: HTTPS vs. SSH

When managing your source control on platforms like GitHub, you’ll have two options for connecting to remote repositories: HTTPS and SSH. Both methods have their advantages and complexities… but which one do you choose?! 🤔

HTTPS

HTTPS, is the default method due to its simplicity. It involves authenticating using a URL prefixed by https://. Most source control platforms have discontinued usernames and passwords in favour of access tokens. The URL communicates over your source control's web protocol and will look something like this:

https://github.com/folder/RepositoryName.git

Note. The folder is the username or org in Github.

SSH

Next we have SSH (Secure Shell) which uses a similar format to connecting to an SSH-enabled server. Most source control platforms require you to connect with the “git” user. SSH also facilitates SSH agent forwarding, which allows a remote server to forward authentication from your local machine without exposing your private keys. This is an example of what you would use at the command line:

git@github.com:folder/RepositoryName.git

Note. The folder is the username or org in Github.

Deep Diving into the Protocol 🤿 🛜

To give you an idea of the connectivity differences between these protocols, here is a depiction of what takes place when you attempt to clone your repository:

HTTPS Flow

1. Estabilish TCP Connection: Your git client sends the server a SYN packet, which responds with a SYN ACK packet and a connection is established.
2. SSL/TLS Handshake: Your client will attempt a message to the server. The server will reply, presenting its certificate to the client to prove its authenticity.
3. Auth: If you're interacting with a private repository, then the server needs authentication. So the client submits its token to the server over the encrypted channel and the server verifies it. The secure, encrypted channel is then established.
4. Payload: The client requests the data and the source control server gathers and sends it to the client. 🤑
5. Reconstruction: The client will receive the data, reconstruct it and check out to the default branch. 🏗️

SSH Flow

1. SSH Handshake: Your git client attempts the connection to the git server. The server in turn presents its host key to the client which verifies the server's identity. It also sends a random message for the client to reply to it with.
2. Auth: The client will need to trust the host's certificate (known_hosts file), it will then encrypt the random message with its private key and send this back to the server. The server will decrypt this key with its public key and the secure, encrypted channel has been established.
3. Payload: The client requests the data and the source control server gathers and sends it to the client. 🤑
4. Reconstruction: The client will receive the data, reconstruct it and check out to the default branch. 🏗️

HTTPS Benefits:

• Prevalence of Access: HTTPS uses Port 443, which is usually open on most firewalls, ensuring accessibility.
• Simplicity across Devices: No need to manage different SSH keys for different devices.
• Caching: HTTPS supports caching mechanisms which is likely to help with data retrieval speeds. 🚀
• Granularity: Most source control platforms grant you the ability to associate specific permissions with your token, further isolating access.

HTTPS Drawbacks:

• Cred Management: Unless you are using a credential manager for your credentials, you have to input the token each time you interact with your repository.
• Man-In-The-Middle Attacks: If the CA is compromised, an attacker can use this to expose data or redirect traffic. Your token is passed through over the wire each time you interact with your repository. 😰
• Proxy/Firewall Issues: If you work in a large corporate environment, then it's likely you will experience complications or performance issues as your org's proxy & firewall infrastructure inspect your traffic. 🚧

SSH Benefits:

• Enhanced Security: SSH keys are lengthy, complex and unique which means it's generally more secure. 🛡️
• No Server-side Storage: Your private key remains with you, never transmitted during authentication which helps reduce exposure.
• Multi-Device Management: You can have different keys for different devices and different accounts.
• Ease of Use: Apart from your initial setup, it all gets real simple when your config file handles every authentication attempt going forward.

SSH Drawbacks:

• Initial Setup: If you aren't paying attention or don't know the difference between a private and public key, then this bit can get messy. 🤦‍♂️
• Misshandling of Private Key: If your machine is compromised, or if you expose your private key mistakenly then this can lead to unauthorized access. 🚨
• Port Blocking: Most firewalls and proxies don't play nice with SSH, they exist to know what you're doing and SSH makes that a little more difficult for them.

So which one takes the crown?! 👑

Well, hopefully you've made that decision yourself by now. But if you haven't here is a small guide that might help:

• You are handling monorepos
• You are a working for a conglomerate and dare not question the firewall/proxy
• The energy getting fired up is wasted and you consider yourself a Tesla
• You are a reckless human and just want simplicity

Firstly, you have my sympathies but HTTPS is for you. Set forth and tokenise your life! 🚀

• You value your security above all else
• You like being organized to save yourself the annoying repeated admin things in life
• You don't have to fight with the proxy/firewall gang

SSH is the one for you. Let those cryptographic keys guide you to safe shores! ⛵

More on the topic

Whether you chose HTTPS or SSH, it's important to understand their strengths and weaknesses so you can lead an informed and professional life. 🎓