7 ms·

Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome.

Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome. For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long might such a compromise go undetected? Is there any reason to think it'd ever be detected? CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. For homogenous configurations (like the implementations of AWS, Azure, or GCM, or the deployment of routers, IOT devices, or gaming systems), it seems like a competent global adversary would simply figure out how to go unreported for that configuration, and nobody would particularly check.

akerl_ 3y ago
I'm not sure why you're so fixated on this idea of client systems monitoring CT logs. Operators who host infrastructure can and should be monitoring issuance in CT logs for domains they operate, which will allow them to identify and react to any unexpected issuance for those domains.
- matthew9219 3y ago
  In the attack DNSSec prevents, a client is compromised by a cert that doesn't appear in the CT logs, so infrastructure monitoring is irrelevant.
  - mjg59 3y ago
    Most browsers will reject such a certificate. See https://googlechrome.github.io/CertificateTransparency/ct_policy.html https://googlechrome.github.io/CertificateTransparency/ct_po... for the policy Chrome imposes - my understanding is that Safari is broadly similar. Right now I don't think Firefox performs this validation, so this is possible if you know in advance that your target runs Firefox.
    - matthew9219 3y ago
      That page explains that Chrome (which is best in class here - most IOT devices don't do any of this stuff) fails open: > If the installed version of Chrome has not applied security updates and has been unable to obtain an updated CT log list from the Component Updater for 70 days or more, then CT enforcement will be disabled. That means a global adversary need merely block the update channel to targeted devices and wait. How will a Smart TV behave?
      - mjg59 3y ago
        You're moving the goalposts to a ridiculous degree. Chrome will be incredibly angry at you if you haven't updated in 70 days. How will a smart TV behave? I've no idea. It's probably not paying any attention to dnssec (otherwise pihole and co wouldn't work), so I don't think you're presenting a credible alternative.
        matthew9219 3y ago
        That's just not what's happening. Reread the conversation. I started from here: > Certificate transparency is cool, but it's not clear it really works for many classes of devices Smart TVs aren't some gotcha I'm throwing in at the end. It's literally the first thing I said about CT. CT works ok for mobile phones, laptops, and other devices where you can make certain assumptions about multiple networks and frequent updates. If you want a technology that doesn't require these assumptions, you want DNSSec.
        mjg59 3y ago
        Once you've got a 70 day old browser you're just waiting for it to hit one domain you can MITM or serve content from and then you've got arbitrary code execution and who cares whether dnssec is involved or not. Attacking CT is just not the threat model to be concerned about.
        matthew9219 3y ago
woodruffw 3y ago
> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's never (or more accurately, never has to be) the client actually doing the reporting. Reporting is left to separate monitoring parties. In other words: a global adversary cannot surreptitiously use a novel CA against a particular configuration; they must first make themselves visible to one or more CT logs. Failing to do so means that their CA will be rejected outright by the client (or accepted by the client if the client doesn't do CT, but still with a loss of stealth).
- matthew9219 3y ago
  The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates. Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.
  - tptacek 3y ago
    That's not how any of this works. Clients don't download the CT logs.
    - matthew9219 3y ago
      Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding. The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.
tzs 3y ago
I don't think firmware updates for routers is a good example. That seems more like the kind of situation where you should actually be using your own PKI.

akerl_ 3y ago

I'm not sure why you're so fixated on this idea of client systems monitoring CT logs. Operators who host infrastructure can and should be monitoring issuance in CT logs for domains they operate, which will allow them to identify and react to any unexpected issuance for those domains.

matthew9219 3y ago
In the attack DNSSec prevents, a client is compromised by a cert that doesn't appear in the CT logs, so infrastructure monitoring is irrelevant.
- mjg59 3y ago
  Most browsers will reject such a certificate. See https://googlechrome.github.io/CertificateTransparency/ct_policy.html https://googlechrome.github.io/CertificateTransparency/ct_po... for the policy Chrome imposes - my understanding is that Safari is broadly similar. Right now I don't think Firefox performs this validation, so this is possible if you know in advance that your target runs Firefox.
  - matthew9219 3y ago
    That page explains that Chrome (which is best in class here - most IOT devices don't do any of this stuff) fails open: > If the installed version of Chrome has not applied security updates and has been unable to obtain an updated CT log list from the Component Updater for 70 days or more, then CT enforcement will be disabled. That means a global adversary need merely block the update channel to targeted devices and wait. How will a Smart TV behave?
    - mjg59 3y ago
      You're moving the goalposts to a ridiculous degree. Chrome will be incredibly angry at you if you haven't updated in 70 days. How will a smart TV behave? I've no idea. It's probably not paying any attention to dnssec (otherwise pihole and co wouldn't work), so I don't think you're presenting a credible alternative.
      - matthew9219 3y ago
        That's just not what's happening. Reread the conversation. I started from here: > Certificate transparency is cool, but it's not clear it really works for many classes of devices Smart TVs aren't some gotcha I'm throwing in at the end. It's literally the first thing I said about CT. CT works ok for mobile phones, laptops, and other devices where you can make certain assumptions about multiple networks and frequent updates. If you want a technology that doesn't require these assumptions, you want DNSSec.
        mjg59 3y ago
        Once you've got a 70 day old browser you're just waiting for it to hit one domain you can MITM or serve content from and then you've got arbitrary code execution and who cares whether dnssec is involved or not. Attacking CT is just not the threat model to be concerned about.
        matthew9219 3y ago

woodruffw 3y ago

> CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. Unless I'm misunderstanding you, this isn't really how CT works: the expectation for clients under a PKI with CT is that the presented certificate is already present in one or more logs, meaning that it's never (or more accurately, never has to be) the client actually doing the reporting. Reporting is left to separate monitoring parties. In other words: a global adversary cannot surreptitiously use a novel CA against a particular configuration; they must first make themselves visible to one or more CT logs. Failing to do so means that their CA will be rejected outright by the client (or accepted by the client if the client doesn't do CT, but still with a loss of stealth).

matthew9219 3y ago
The client has to get the CT log from somewhere, like an update channel (typically TLS). An attacker would compromise both the target and the process by which the client gets CT log updates. Such an attack would be detected if some clients reported which certs they actually saw the next time they connected to an uncompromised network (as Chrome does) but if no clients report, such an attack could go undetected.
- tptacek 3y ago
  That's not how any of this works. Clients don't download the CT logs.
  - matthew9219 3y ago
    Clients get pre certificates (which are portions of the log) as claims in certificates. It's correct that they never download the whole log - I'm simplifying for clarity, not out of lack of understanding. The fact remains - an adversary with a CA private key that can mitm all of the internet connections for a device can forge a fake CT log and go undetected, if that clients never uses a non-mitm network again.

tzs 3y ago

I don't think firmware updates for routers is a good example. That seems more like the kind of situation where you should actually be using your own PKI.