4 ms·

I keep trying to imagine a way that a website could inform a user "only these certificates are valid for me", but with a trusted MITM, it just doesn't seem like

by mabbo 6y ago

I keep trying to imagine a way that a website could inform a user "only these certificates are valid for me", but with a trusted MITM, it just doesn't seem like it's possible. Whatever content or data the website included, the MITM can just alter it accordingly. Short of a browser knowing what Certificates are allowed for what websites (and the trusted MITM not modifying THAT content) there just isn't a simple way to know that your connection is being monitored or modified. Short of quantum encryption, is there any simple way to detect such an attack once the user trusts the MITM's CA?

arkadiyt 6y ago
> it just doesn't seem like it's possible Mobile apps can do this with certificate pinning. Web apps used to be able to do this with HTTP Public Key Pinning (HPKP) [1], but it was deprecated because it was too much of a footgun. Instead you can monitor for certificates for your domain that aren't expected via Certificate Transparency logs. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...
nijave 6y ago
>know that your connection is being monitored or modified Probably some low hanging fruit here are 1. Inspect the CA used by a few different websites 2. Try visiting the website from different countries (vpns and proxies) to see if the same cert is used Theoretically a MITM could tamper with the software download but I think for most cases this would be reasonable
Edmond 6y ago
A "trusted MITM" is just that, a trusted MITM...You kind of accept the compromises that come with such a setup. A CA that can issue a certificate to a third-party without the consent of the domain owner is not a trusted CA by definition. In other words the issue in Kazakhstan should probably not be viewed as a technical issue...authoritarian governments will always get their way if the only recourse against them is a technical solution. In the case of Kazakhstan, they are forcing their citizens to accept the compromised CA, that is not a technical problem to solve.
NicolaiS 6y ago
It is possible using a "Certification Authority Authorization" (CAA) DNS record to specify which CA is allowed to sign certs for your domain and using DNSSEC you get a separate channel of trust. However CAA (and DNSSEC) is rarely used, so most likely the MITM-part will just block lookups.
- schoen 6y ago
  Also, CAA is explicitly specified to only constrain certificate issuance, not certificate acceptance. Only the issuing CA is supposed to check it, not the browser. RFC 8659: A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain name. Since certificates are valid for a period of time, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying Parties MUST NOT use CAA records as part of certificate validation.
- Melkman 6y ago
  CAA is not the record for this. As @schoen already replied, it is only used by CA's to check if they are allowed to issue a certificate to a domain. But with DANE TLSA Resource Records you can pin a public key to a website. Alas the implementation of TLSA-RR checking in browsers is dependent on extensions at this time. I wish it was native in browsers with a big red sign when violated. When done in combination with DNSSEC it's very hard to fake certificates. Or more precisely asymmetric cryptography key pairs used by servers. Certificates for TLS would not be needed anymore if TLSA-RR's were standard practice. A company might still use a certificate to attest it's identity beyond internet domain ownership. Edit: This is for TLSA 3 1 1 and 3 1 2 records. That's what I have experience with. Just read on Wikipedia a lot more is possible with TLSA-RR's including certificate and CA pinning. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_RR https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
  - tptacek 6y ago
    It's unlikely ever to be native in browsers. Native DANE code was proposed in Firefox and actually landed in Chrome, which later removed it, because it (a) didn't work reliably on the actual Internet, and (b) in fallback mode, amounts to adding just one more CA to the pile of CAs Chrome already has to trust. When a CA can be shown to have misissued a certificate, Google can (and has, as it did in the Symantec case) distrust it, nuking the CA from orbit. It has no such powers with a CA baked into the DNS; Google can't distrust .COM. People should be careful what they wish for. But not too careful in this case; DNSSEC is moribund, and unlikely to be revived.
cesarb 6y ago
> Short of quantum encryption, is there any simple way to detect such an attack once the user trusts the MITM's CA? If the website uses client certificate authentication, any MITM attempt will fail authentication unless either the website trusts the MITM's CA, or the MITM somehow has access to the private key of the client certificate; the browser trusting the MITM's CA is not enough. Unfortunately, client certificate authentication in websites is rare (unlike for instance ssh, where public key authentication of both the server and the client is common). Another way to detect MITM attempts would be if TLS channel binding were used for authentication, since any MITM would be using separate connections for the server and the client and therefore the authentication (bound to the TLS connection) would fail. I don't know if newer authentication protocols like WebAuthn support it, and if they do, how common is the support for it in browsers.

by mabbo 6y ago

arkadiyt 6y ago

> it just doesn't seem like it's possible Mobile apps can do this with certificate pinning. Web apps used to be able to do this with HTTP Public Key Pinning (HPKP) [1], but it was deprecated because it was too much of a footgun. Instead you can monitor for certificates for your domain that aren't expected via Certificate Transparency logs. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...

nijave 6y ago

>know that your connection is being monitored or modified Probably some low hanging fruit here are 1. Inspect the CA used by a few different websites 2. Try visiting the website from different countries (vpns and proxies) to see if the same cert is used Theoretically a MITM could tamper with the software download but I think for most cases this would be reasonable

Edmond 6y ago

A "trusted MITM" is just that, a trusted MITM...You kind of accept the compromises that come with such a setup. A CA that can issue a certificate to a third-party without the consent of the domain owner is not a trusted CA by definition. In other words the issue in Kazakhstan should probably not be viewed as a technical issue...authoritarian governments will always get their way if the only recourse against them is a technical solution. In the case of Kazakhstan, they are forcing their citizens to accept the compromised CA, that is not a technical problem to solve.

NicolaiS 6y ago

It is possible using a "Certification Authority Authorization" (CAA) DNS record to specify which CA is allowed to sign certs for your domain and using DNSSEC you get a separate channel of trust. However CAA (and DNSSEC) is rarely used, so most likely the MITM-part will just block lookups.

schoen 6y ago
Also, CAA is explicitly specified to only constrain certificate issuance, not certificate acceptance. Only the issuing CA is supposed to check it, not the browser. RFC 8659: A set of CAA records describes only current grants of authority to issue certificates for the corresponding DNS domain name. Since certificates are valid for a period of time, it is possible that a certificate that is not conformant with the CAA records currently published was conformant with the CAA records published at the time that the certificate was issued. Relying Parties MUST NOT use CAA records as part of certificate validation.
Melkman 6y ago
CAA is not the record for this. As @schoen already replied, it is only used by CA's to check if they are allowed to issue a certificate to a domain. But with DANE TLSA Resource Records you can pin a public key to a website. Alas the implementation of TLSA-RR checking in browsers is dependent on extensions at this time. I wish it was native in browsers with a big red sign when violated. When done in combination with DNSSEC it's very hard to fake certificates. Or more precisely asymmetric cryptography key pairs used by servers. Certificates for TLS would not be needed anymore if TLSA-RR's were standard practice. A company might still use a certificate to attest it's identity beyond internet domain ownership. Edit: This is for TLSA 3 1 1 and 3 1 2 records. That's what I have experience with. Just read on Wikipedia a lot more is possible with TLSA-RR's including certificate and CA pinning. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_RR https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
- tptacek 6y ago
  It's unlikely ever to be native in browsers. Native DANE code was proposed in Firefox and actually landed in Chrome, which later removed it, because it (a) didn't work reliably on the actual Internet, and (b) in fallback mode, amounts to adding just one more CA to the pile of CAs Chrome already has to trust. When a CA can be shown to have misissued a certificate, Google can (and has, as it did in the Symantec case) distrust it, nuking the CA from orbit. It has no such powers with a CA baked into the DNS; Google can't distrust .COM. People should be careful what they wish for. But not too careful in this case; DNSSEC is moribund, and unlikely to be revived.

cesarb 6y ago

> Short of quantum encryption, is there any simple way to detect such an attack once the user trusts the MITM's CA? If the website uses client certificate authentication, any MITM attempt will fail authentication unless either the website trusts the MITM's CA, or the MITM somehow has access to the private key of the client certificate; the browser trusting the MITM's CA is not enough. Unfortunately, client certificate authentication in websites is rare (unlike for instance ssh, where public key authentication of both the server and the client is common). Another way to detect MITM attempts would be if TLS channel binding were used for authentication, since any MITM would be using separate connections for the server and the client and therefore the authentication (bound to the TLS connection) would fail. I don't know if newer authentication protocols like WebAuthn support it, and if they do, how common is the support for it in browsers.