Skip to main content
Tweeted twitter.com/StackSecurity/status/1386923095894728708
Became Hot Network Question
Typo
Source Link
fgrieu
  • 1.3k
  • 8
  • 21

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies (or equivalently, route B's traffic thru a router under control of M). M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop M from having their router perform a MitM attack, where the router holds a rogue certificate for A's FQDN, uses it to impersonatesimpersonate A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which M has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attack on TLS? What method(s) does it use?

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies (or equivalently, route B's traffic thru a router under control of M). M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop M from having their router perform a MitM attack, where the router holds a rogue certificate for A's FQDN, uses it to impersonates A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which M has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attack on TLS? What method(s) does it use?

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies (or equivalently, route B's traffic thru a router under control of M). M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop M from having their router perform a MitM attack, where the router holds a rogue certificate for A's FQDN, uses it to impersonate A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which M has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attack on TLS? What method(s) does it use?

change Eve to M and other polish
Source Link
fgrieu
  • 1.3k
  • 8
  • 21

Ongoing effort to detect MitM attacksattack on TLS?

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies (or equivalently, route B's traffic thru a router under control of M). M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop EveM from having her routerstheir router perform a MitM attack, where the router (or something it routes thru) holds a rogue certificate for A's FQDN, uses it to impersonates A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which EveM has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attacksattack on TLS? What method(s) does it use?

Ongoing effort to detect MitM attacks on TLS?

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies. M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop Eve from having her routers perform a MitM attack, where the router (or something it routes thru) holds a rogue certificate for A's FQDN, uses it to impersonates A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which Eve has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attacks on TLS? What method does it use?

Ongoing effort to detect MitM attack on TLS?

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies (or equivalently, route B's traffic thru a router under control of M). M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop M from having their router perform a MitM attack, where the router holds a rogue certificate for A's FQDN, uses it to impersonates A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which M has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attack on TLS? What method(s) does it use?

Source Link
fgrieu
  • 1.3k
  • 8
  • 21

Ongoing effort to detect MitM attacks on TLS?

Client B connects to server A using TLS. B knows A by it's FQDN (e.g. www.alice.tld), and by a root certificate for a CA that issued a certificate to A for this FQDN. Say B uses HTTPS and a standard web browser, and the certificate A holds comes with a chain of certificates to a CA which is in B's browser's whitelist.

State actor M is able to coerce B's ISP to use routers M supplies. M also is able to get certificates that B's browser will trust for any FQDN, because M has foot in one of the myriad of CAs with this ability.

Correct me if I'm wrong, but AFAIK there's nothing built into TLS or HTTPS to stop Eve from having her routers perform a MitM attack, where the router (or something it routes thru) holds a rogue certificate for A's FQDN, uses it to impersonates A w.r.t. B, and connects to A as B would (here, unauthenticated). In theory, no public point-to-point protocol can be effective against such MitM attack.

However, in practice, that could be detected

  1. Some link from A to B with trusted integrity will do: A can publish the certificates it uses (or just their hashes/fingerprint), and B can check if the certificate it uses as being A's is in this list.
  2. Some public service could try to do just that instead of A, collecting certificate(s) A uses thru a variety of links hopefully out of the influence of M, and republishing it as tweets, radio broadcasts, printed handouts, or other hard-to-censor means.
  3. It's enough to pass that same info on top of the TLS link using a protocol against which Eve has not yet implemented countermeasures. For a start, a new experimental HTTP(S) header where A sends the hash of the certificate it currently uses would do.

Question: is there some ongoing effort to detect such MitM attacks on TLS? What method does it use?