5

A key/fingerprint change occurred on a friend's server to which I have access. So I text him and ask, "Did you change the certificates?" upon which he answer "Yes".

My initial thought is then to update my local fingerprint, but then it occurred to me: What if someone does a MITM attack simultaneously as my friend has done this legitimate change?

How do I proceed to make sure I'm not being tricked?

PS! In this particular case, my friend went from a self-signed certificate to using Let's Encrypt, but answers should reflect any situation involving a change of fingerprint.

forthrin
  • 1,741
  • 1
  • 13
  • 21

2 Answers2

3

Let's call your friend Bob.

Bob has updated his certificate, but since you've never seen it before, you're rightly concerned Eve may be in the middle. You've done the right thing by contacting him to verify your observation, but there is still no automated way of confirming the new key. I'm presuming you aren't using any signing authority and explicitly trusting the specific certificate on Bob's end?

You already trust him to confirm the key changes over text, so simply sending the fingerprint over another text would do the trick.

Essentially, you need to use some out-of-band method to confirm the new key (e.g. meet him in person), or find a way for him to deliver the key over another, established trusted channel e.g. signed e-mail, signed PGP, Text/WhatsApp, putting it on a website you know only he controls etc.

This is why a Certificate Authority is so useful - it's the root of your trust in the remote system. If you trust Let's Encrypt (which you should by default, as it's certificate is issued by another trusted root CA in most browsers/OSes) then this problem goes away.

Liam Dennehy
  • 587
  • 2
  • 8
  • The old certificate was a self-signed certificate that I assumed to be legitimate (arguably an act of carelessness on my part). The new certificate comes from a site called Let's Encrypt. So what you're basically saying is that the system administrator must give the user the fingerprint over an established secure channel (which in turn must have been established without any chance of MITM). If proper certificates were used that already had counterparts in my OS, I assume none of this would be necessary, right? – forthrin Jul 24 '17 at 21:57
  • If it was issued by a CA you already trust, then yes no action is required. – Liam Dennehy Jul 24 '17 at 22:04
  • If you merge this comment plus the specifics from Jakuje's comment into your initial suggestion this could be the accepted answer. – forthrin Jul 25 '17 at 08:15
  • Thanks, I've updated the answer to include the utility of CAs and the existing text channel as trusted. – Liam Dennehy Jul 25 '17 at 10:14
  • Am I to understand I should remove the local/manual fingerprint copy altogether (I'm using `fetchmail`), so that local certificates take priority (or fail if not present)? – forthrin Jul 25 '17 at 15:17
  • For clarity you can delete it, and of course to make sure nobody later uses that key for another purpose. In general as long as the new one is in your local configuration it will ignore the others. – Liam Dennehy Jul 25 '17 at 15:27
  • So certificate counterparts in the OS has precedence over explicitly specified fingerprint values in configuration files (`.fetchmailrc` in this case)? Be sure to add this to the answer, too. – forthrin Jul 25 '17 at 20:19
2

How do I proceed to make sure I'm not being tricked?

Your friend should not answer you "Yes", but "Yes, the new SHA-256 fingerprint is ...". In that case, you can remove the old key and manually verify the new host key.

Jakuje
  • 5,229
  • 16
  • 31