7 ms·

How is an attacker going to MITM an encrypted connection they don't have the keys for, without having rogue DNS or something similar, i.e. faking the actual tar

How is an attacker going to MITM an encrypted connection they don't have the keys for, without having rogue DNS or something similar, i.e. faking the actual target?

oconnor663 1y ago
They MITM the key exchange step at the beginning, and now they do have the keys. The thing that prevents this in TLS is the chain of signatures asserting identity.
- panki27 1y ago
  You can not MITM a key that is being exchanged through Diffie-Hellman, or have I missed something big?
  - Ajedi32 1y ago
    Yes, Mallory just pretends to be Alice to Bob and pretends to be Bob to Alice, and they both establish an encrypted connection to Mallory using Diffie-Hellman keys derived from his secrets instead of each other's. Mallory has keys for both of their separate connections at this point and can do whatever he wants. That's why TLS only uses Diffie-Hellman for perfect forward secrecy after Alice has already authenticated Bob. Even if the authentication key gets cracked later Mallory can't reach back into the past and MITM the connection retroactively, so the DH-derived session key remains protected.
  - oconnor663 1y ago
    If we know each other's DH public key in advance, then you're totally right, DH is secure over an untrusted network. But if we don't know each other's public keys, we have to get them over that same network, and DH can't protect us if the network lies about our public keys. Solving this requires some notion of "identity", i.e. some way to verify that when I say "my public key is abc123" it's actually me who's saying that. That's why it's hard to have privacy without identity.
- 2mlWQbCK 1y ago
  You can have TLS with TOFU, like in the Gemini protocol. At least then, in theory, the MTIM has to happen the first time you connect to a site. There is also the possibility for out of band confirmation of some certificate's fingerprint if you want to be really sure that some Gemini server is the one you hope it is.
simiones 1y ago
Connections never start as encrypted, they always start as plain text. There are multiple ways of impersonating an IP even if you don't control DNS, especially if you are in the same local network.
- gruez 1y ago
  >Connections never start as encrypted, they always start as plain text Not "never", because of HSTS preload, and browsers slowly adding scary warnings to plaintext connections. https://preview.redd.it/1l4h9e72vp981.jpg?width=640&crop=smart&auto=webp&s=1a453f59c190f69da9631fdd36db6e5497c33753 https://preview.redd.it/1l4h9e72vp981.jpg?width=640&crop=sma...
  - simiones 1y ago
    TCP SYN is not encrypted, and neither is Client Hello. Even with TCP cookies and TLS session resumption, the initial packet is still unencrypted, and can be intercepted.
    - haiku2077 1y ago
      Client Hello can be encrypted: https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello https://support.mozilla.org/en-US/kb/understand-encrypted-cl...
      - EE84M3i 1y ago
        Yes but this still depends on identity. It's not unauthenticated.
        ekr____ 1y ago
        The situation is actually somewhat more complicated than this. ECH gets the key from the DNS, and there's no real authentication for this data (DNSSEC is rare and is not checked by the browser). See S 10.2 [0] for why this is reasonable. [0] https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-unauthenticated-and-plainte https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.ht...
Ajedi32 1y ago
It's an unauthenticated encrypted connection, so there's no way for you to know whose keys you're using. The attacker can just tell you "Hi, I'm the server you're looking for. Here's my key." and your client will establish a nice secure, encrypted connection to the malicious attacker's computer. ;)
- notTooFarGone 1y ago
  There are enough example where this is just a bogus scenario. There are a lot of IoT cases that fall apart anyway when the attacker is able to do a MITM attack. For example if the MITM requires you to have physical access to the machine, you'd also have to cover the physical security first. As long as that is not the case who cares for some connection hijack. If the data you are actually communicating is in addition just not worth the encryption but has to be because of regulation you are just doing the dance without it being worth it.

How is an attacker going to MITM an encrypted connection they don't have the keys for, without having rogue DNS or something similar, i.e. faking the actual target?

oconnor663 1y ago

They MITM the key exchange step at the beginning, and now they do have the keys. The thing that prevents this in TLS is the chain of signatures asserting identity.

panki27 1y ago
You can not MITM a key that is being exchanged through Diffie-Hellman, or have I missed something big?
- Ajedi32 1y ago
  Yes, Mallory just pretends to be Alice to Bob and pretends to be Bob to Alice, and they both establish an encrypted connection to Mallory using Diffie-Hellman keys derived from his secrets instead of each other's. Mallory has keys for both of their separate connections at this point and can do whatever he wants. That's why TLS only uses Diffie-Hellman for perfect forward secrecy after Alice has already authenticated Bob. Even if the authentication key gets cracked later Mallory can't reach back into the past and MITM the connection retroactively, so the DH-derived session key remains protected.
- oconnor663 1y ago
  If we know each other's DH public key in advance, then you're totally right, DH is secure over an untrusted network. But if we don't know each other's public keys, we have to get them over that same network, and DH can't protect us if the network lies about our public keys. Solving this requires some notion of "identity", i.e. some way to verify that when I say "my public key is abc123" it's actually me who's saying that. That's why it's hard to have privacy without identity.
2mlWQbCK 1y ago
You can have TLS with TOFU, like in the Gemini protocol. At least then, in theory, the MTIM has to happen the first time you connect to a site. There is also the possibility for out of band confirmation of some certificate's fingerprint if you want to be really sure that some Gemini server is the one you hope it is.

simiones 1y ago

Connections never start as encrypted, they always start as plain text. There are multiple ways of impersonating an IP even if you don't control DNS, especially if you are in the same local network.

gruez 1y ago
>Connections never start as encrypted, they always start as plain text Not "never", because of HSTS preload, and browsers slowly adding scary warnings to plaintext connections. https://preview.redd.it/1l4h9e72vp981.jpg?width=640&crop=smart&auto=webp&s=1a453f59c190f69da9631fdd36db6e5497c33753 https://preview.redd.it/1l4h9e72vp981.jpg?width=640&crop=sma...
- simiones 1y ago
  TCP SYN is not encrypted, and neither is Client Hello. Even with TCP cookies and TLS session resumption, the initial packet is still unencrypted, and can be intercepted.
  - haiku2077 1y ago
    Client Hello can be encrypted: https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello https://support.mozilla.org/en-US/kb/understand-encrypted-cl...
    - EE84M3i 1y ago
      Yes but this still depends on identity. It's not unauthenticated.
      - ekr____ 1y ago
        The situation is actually somewhat more complicated than this. ECH gets the key from the DNS, and there's no real authentication for this data (DNSSEC is rare and is not checked by the browser). See S 10.2 [0] for why this is reasonable. [0] https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-unauthenticated-and-plainte https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.ht...

Ajedi32 1y ago

It's an unauthenticated encrypted connection, so there's no way for you to know whose keys you're using. The attacker can just tell you "Hi, I'm the server you're looking for. Here's my key." and your client will establish a nice secure, encrypted connection to the malicious attacker's computer. ;)

notTooFarGone 1y ago
There are enough example where this is just a bogus scenario. There are a lot of IoT cases that fall apart anyway when the attacker is able to do a MITM attack. For example if the MITM requires you to have physical access to the machine, you'd also have to cover the physical security first. As long as that is not the case who cares for some connection hijack. If the data you are actually communicating is in addition just not worth the encryption but has to be because of regulation you are just doing the dance without it being worth it.