💡Man in the Middle (MITM) Attacks
Understanding MITM Attacks and how to prevent them.
Broadly speaking, defense against MITM attacks is rooted in Authentication and Tamper detection.
Authentication: How can we verify the user accessing a resource is the user intended to have permissions on that resource?
Temper Detection: How can we detect when the data we access has been altered by an unauthorized actor?
Below shows how MITM attacks can work, and Mallory is up to no good.
Authentication (Not Authorization)
Simply put, authentication is the process of verifying who someone is, whereas authorization is the process of verifying what specific applications, files, and data a user has access to.
(sited from SailPoint)
The authentication process may vary depending on the level of security required for a specific use case. We use public/private key pairs during the SSH authentication process to access our git repositories as well as our EC2 instances. The ssh-keygen and ssh-agent tools in Linux are used for these purposes.
The default behavior of most connections is to only authenticate the server. Lack of mutual authentication exposes the system to MITM attacks.
Secure Shell (SSH) is a way to securely access resources through cryptographic private/public key pairs for authorization into a secure shell connection.
We connect to our EC2 instances through SSH.
We connect to Git repositories through SSH (mandatory SSH enforced).
Alright, let's take a look at how to use this knowledge next.
Tamper Detection with Cryptographic Signatures
Cryptographic signatures allow authors to sign their work so that users can verify that the source code has not been modified since it was packaged. Authors should work to make their public credentials readily accessible so consumers can securely download signed and untampered data.
Gadget Engineering requires all commits to be signed using gpg keys. Unsigned commits will be rejected from all pull requests.
Public Key Infrastructure (PKI)
A PKI binds public keys to public identities.
Public key infrastructure (ie Transport Layer Security) allows signatures between clients and servers via certificates. A trusted third-party Certificate Authority (CA) issues and verifies the certificates.
From Wikipedia:
A public key infrastructure (PKI) is a set of roles, policies, hardware, software, and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption...
In cryptography, a PKI is an arrangement that binds** **public keys with respective identities of entities (like people and organizations).
PKI is a big topic, but the major takeaway here is a system where public signatures (keys) are linked to public identities. This system works to resolve vulnerabilities in authentication and tamper detection.
Fingerprints and Public Keys
Fingerprints and public keys are very similar in that they are public ways to verify, sign, or authenticate. Fingerprints and public keys are like digital ID cards (GitHub publishes theirs here).
Both keys in the private/public key pair are capable of generating the exact same fingerprint.
A fingerprint is just a short version of a public key. This makes for a convenient way to identify keys.
Compare the example public key and fingerprint from that key:
# public key
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEdTcR5uS1hg8ZzTuQDcm+rSewDgYBzmddJFRq3cOrVY kshultz@permitzip.com
# fingerprint
SHA256:6dvH2tSNL6vDYVSkDyWdTM8v6K+23WHSSkwLUTYLtZQLast updated