The difference between MACs vs. HMACs vs. PRFs I have some confusion regarding the difference between MACs and HMACs and PRFs and when to use which term. 

If the function is computed using a hash and secret key like the following, is this a HMAC or MAC?

MD5(master_secret + pad2 + MD5(handshake_messages + Sender + master_secret + pad1));


If I have a tag for verifying data, computed using a PRF in the form:
PRF(master_secret, finished_label, Hash(handshake_messages))

Again, my question, is this HMAC or MAC or none, just a PRF?

The above functions are what is used in the Finished messages for SSL 3.0 and TLS 1.2 respectively. The literature use MAC generally. I am not sure if this is the correct term used to refer to them. 

Can I refer to HMAC and PRF by MAC?
A PRF or pseudorandom function family is a family of functions $F_k\colon \{0,1\}^n \to \{0,1\}^m$ such that if $k$ is uniformly distributed, then $F_k$ appears to be uniformly distributed among all functions $G\colon \{0,1\}^n \to \{0,1\}^m$.  A PRF $F_k$ is secure if an adversary who does not know the key $k$ can't distinguish $F_k$ from a uniform random choice of function $G\colon \{0,1\}^n \to \{0,1\}^m$ with more than negligible probability of success beyond flipping a coin—the adversary's only strategy is to correctly guess the key $k$ which is usually drawn uniformly from a space of usually $2^{128}$ or $2^{256}$ possibilities, which no adversary will ever stumble upon by chance.

The existence of PRFs remains a conjecture, related to P = NP; at best we conjecture that function families are PRFs, and sometimes find counterexamples to the conjectures.  Some PRFs have long or variable-length inputs, e.g. keyed BLAKE2b; some PRFs have short inputs, e.g. ChaCha or the compression function inside MD5.

A MAC or message authentication code is a family of functions $M_k\colon \{0,1\}^* \to \{0,1\}^T$ with which one can construct and verify a $T$-bit tag $t = M_k(m)$ on a message $m$ with a secret key $k$.  A MAC is secure if an adversary, upon seeing some number of past (possibly adaptively) chosen messages and tags $(m_i, t_i)$ with $t_i = M_k(m_i)$, can't forge a tag $t' = M_k(m')$ for a message $m'$ not previously seen with better than negligible probability.

Many MACs are one-time authenticators, meaning the secret key can be used for only one message, such as Poly1305 and GHASH (of AES-GCM).  One-time authenticators are useful because they can be extremely fast and can come with an unconditional information-theoretic security proof of forgery probabilities, and it is easy to use a PRF with a nonce to create a new OTA key for each message.

A long-input PRF $F_k$ can also serve as a MAC, because an adversary having seen $\{F_k(m_i)\}_i$ can't even distinguish that from $\{G(m_i)\}_i$ for a uniform random choice of $G$, so the best strategy the adversary has is to pick some $k'$ uniformly at random, try forging $t' = M_{k'}(m')$ for some message $m'$, and hope that $k = k'$, whose success probability is bounded by the probability that $M_{k'}(m')$ happens to coincide with $M_k(m')$ or that $k = k'$, which are both negligible.

$\newcommand{\concat}{\mathop{\Vert}}$HMAC is a specific construction of a long-input PRF out of a short-input PRF chained in a Merkle-Damgård construction $H$, such as MD5 or SHA-256.  Naively using the function $$F_k\colon m \mapsto H(k \concat m)$$ for uniform random key $k$ does not give a PRF when $H$ is either MD5, SHA-1, SHA-256, or SHA-512, because even if I don't know $k$, knowing $F_k(m)$ enables me to easily compute $F_k(m \concat p \concat m')$ for some padding $p$ and an arbitrary suffix $m'$.  This is called a length extension attack.  HMAC works around this for an MD hash function $H$ by using $$F_k\colon m \mapsto H\bigl((\mathrm{opad} \oplus k) \concat H\bigl((\mathrm{ipad} \oplus k) \concat m\bigr)\bigr),$$ where $\mathrm{opad}$ and $\mathrm{ipad}$ are constant strings defined in the standard.

(The full details are finicky, e.g. if $k$ is not exactly the length of one block of the short-input PRF underlying $H$.  You can also use HMAC on non-MD functions such as SHA-3, but the usual reference for an HMAC security reduction relies on MD.  The security reduction story for HMAC is complicated, and there has been some more recent work on it; however, the strategy for modern designs like SHA-3 and BLAKE2 is to just make prefix-keyed $F_k\colon m \mapsto H(k \concat m)$ work as a PRF without the contortions of HMAC, and to define a standard domain-separated keyed PRF variant of the function.)

Since for certain fixed hash functions $H$, HMAC-$H$ is conjectured to be a PRF, and since a PRF always makes a MAC, you can use HMAC-$H$ to make a (rather slow) MAC.

Is your construction an HMAC for some fixed hash function $H$?  No.

Is your construction a PRF?  No: if an adversary can control $\mathrm{handshake\_messages}$, then they can almost certainly find a collision in $$\operatorname{MD5}(\mathrm{handshake\_messages} \concat \mathrm{Sender} \concat \mathrm{master\_secret} \concat \mathrm{pad}_1),$$ which would enable them to distinguish $F_k$ (your construction) from a uniform random $G\colon \{0,1\}^\ell \to \{0,1\}^T$ without knowing $k$ ($\mathrm{master\_secret}$) by simply evaluating it on the colliding messages and seeing whether it's the same, which for the overwhelming majority of functions $G$ will not be the case.

Is your construction a MAC?  Again, no, because if the adversary can find a colliding pair of handshake message sets, then they can ask you to make a tag on one of them, and then they can use the same tag to produce a forgery on the other one.

Does this mean you can immediately attack a system in practice that works this way?  Maybe, maybe not.  What it means is that the crypto is not engineered out of reliable well-understood parts that could give confidence in the security of the whole system.  Thus to understand the security of the whole system you cannot simply (a) assess the security of the parts, and (b) assess the security of how they are wired; you must assess the whole thing as a giant unit ball of hair.  And most cryptographers and auditors don't want to bother doing that because it's a lot more work than well-done crypto engineering.