1

Say there's a server and a client. Normally to connect and establish an end-to-end encrypted session, they'd have to carry out key exchange, which potentially gives an attacker the opportunity to perform an MITM attack.

Say that the client has the server's public key fingerprint or public key hard coded. (Which is better?) Upon connection, the server sends over its public key and the client compares the fingerprints. If they match, the client then sends over its public key and a secure session is established.

Is this a better solution than a key exchange? Are there any potential drawbacks? Will it work? Is there a better way?

  • You can add hard-coded keys or fingerprints to the client. However, you might get into trouble if you need to revoke the key, because you then have to update all the clients. – Lukas Jun 7 '16 at 22:46
  • Key exchange (done properly) is completely secure. Yes, you can hard code a public key if you want, but the downside is that you can never revoke it if the private key becomes compromised. – adelphus Jun 7 '16 at 23:14
  • …and thus it is preferible to include several in your pinning. One for the actual operation and the rest stored offline for the case should you need to replace your certificate. – Ángel Jun 7 '16 at 23:25
  • 1
    SSL is trustworthy. Just use it. No need to craft new solutions (actually you've just reinvented HPKP tho it is used to enhance SSL, not replace it) – Neil Smithline Jun 8 '16 at 3:24
  • 1
    @Aurora SSL strip only affects browsers and other clients that can automatically downgrade to non-SSL. If you're writing a custom client, just support SSL with HPKP and you're secure. – Neil Smithline Jun 9 '16 at 15:01
1

Potentially yes it does protect from man in the middle attacks but there are 2 issues with it

  1. How do you get the software to the user? This connection needs to be secure too.
  2. What happens if the private key is revealed? There is no way of revoking the certificate.

HSTS (HTTP Strict Transport Security) works by having certificate fingerprints hard coded into browsers. This assumes that the chain to get your browser was either secure or using HSTS (eg. you get windows 10 read only disk from a trusted source which has IE11 and Edge which both support HSTS, you use them to download chrome from https://www.google.com/chrome/ which uses HSTS) To mitigate 2, you add two certificate's fingerprints, only use one then if that cert is no longer secure you start using the other and revoke the first.

Why is this potentially overkill? This only adds protection from active MITM attacks, normal certificate exchanges work in protecting you from passive MITM. Active MITM attacks are very expensive to do because you either need a CA to give you a certificate for a domain you dont have (this should be impossible but has happened on more than one occasion) or put your own CA cert on the victim's PC.

  • What you describe is HPKP; HSTS only 'hardcodes' the requirement to use HTTPS and not HTTP. Windows programs like Chrome are protected by codesigning (Authenticode) instead of or in addition to protecting the download. – dave_thompson_085 Oct 29 '16 at 6:14
  • Could you clarify the differences between active and passive MITM? – Awn Oct 29 '16 at 12:48
  • Passive is where only listening happens, active involves changing the data. – Topher Brink Oct 31 '16 at 10:43
1

TLS key exchange does not allow undetected MITM

The existing protocols e.g. HTTPS/TLS do not really provide an opportunity for MITM, the key exchange is secure. The certificate signing authorities might be compromised, but existing techniques such as key pinning prevent that - you might think of HPKP standard as the recommended implementation of "a hard-coded public key or fingerprint".

The drawbacks are simple - first, if a particular public key is hardcoded in the client, then it becomes very hard for the legitimate owner to change their public key when needed, e.g. to periodically rotate it, or to revoke a compromised key; and second, you still need to get the initial key from every server to the client which brings you right back to all the key distribution / key exhange problems.

0

Here is how it worked back in the old days of computers:

  1. Alice sends UNENCRYPTED data to a server, via a ROUTER

  2. The server sends back UNENCRYPTED, UNSIGNED data back to Alice

Bob can, if his network card is good enough, say "I am now the router," and easily read ALL DATA that Alice sends to the server

Then a man in the middle attack can easily happen.

Here is how it was, before security was implemented

Here is how it is now:

  1. Alice sends ENCRYPTED DATA to a server via router
  2. The server then decrypts the data, with a VERIFIED, SIGNED key.
  3. ENCRYPTED data is sent back to Alice.

A man in the middle is now quite hard to do, but then someone can get into that first connection to the security authority, and change it to his own.

All you are doing is to change the 2nd part to another verification step. Using face recognition is probably the best way to encrypt that data.

You can look up Computerphile Network Security if this does not help.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.