Comment by 0xbadcafebee
3 years ago
> All issued SSL/TLS certificates are subject to certificate transparency.
Until the nation state tells a CA within their borders to issue a cert without publishing the CT logs, along with a gag order. If they don't comply they go to jail. You think Billy Bob Sysadmin wants to go to jail to protect a russian jabber server?
The malicious certificate either won't have a SCT (which in itself would be highly suspicious and cause some clients to reject the certificate directly), or it will have one but it won't be recorded in the log.
In the latter case, the malicious certificate + any CT log issued after that certificate should have been included are evidence of the attack that is easily verifiable and would likely cause browsers to drop the (edit) CT log unless provided with a very plausible excuse that isn't "we complied with a court/gag order".
Also, this would require the police etc. to compel 2-3 different entities: The CA and two log operators (I think one of them could be the CA itself).
Using different logs than normal would stand out, so it'd typically be two specific log operators that would have to be compelled to hide this. The US may get lucky and have jurisdiction over all of them, other countries are much less likely to.
> and would likely cause browsers to drop the (edit) CT log unless provided with a very plausible excuse that isn't "we complied with a court/gag order"
a) Browsers aren't the only clients that matter. Will any XMPP client even look at the CT log? Probably not.
b) Browsers are not going to drop all US-based certificate authorities. And if they tried they might just get their own national security letter (reminder: all major browsers are US-based).
You can't work around the government using centralized infrastructure.
Even if the US got lucky, those SCTs wouldn’t match the CT chain and would still be discoverable misissuance.
Yes, assuming someone captured the malicious certificate and checked. Which would have happened in this case now (after someone forgot to renew), but likely not before.
Browsers would happily accept it and IIRC they don't check against the logs.
1 reply →
If the certificate isn't logged in CT, it's not supposed to be trusted. That's the whole point. If it is logged, then the site owners would notice (Cloudflare, for example, has a service that emails when certificates are issued for your domains).
Browsers will check if a certificate is in the transparency log, and alert the user if it isn't if I am not mistaken.
But XMPP clients do not, as far as I'm aware? and browsers aren't connecting to XMPP server ports.
Yeah usually the TLS libraries used by XMPP clients don't check SCTs. Not even all browsers do it. Chrome does it, Firefox does not for example.
Source?
https://developer.mozilla.org/en-US/docs/Web/Security/Certif...
As the other commenter already pointed out, Firefox does not require this. Safari and Chrome do. This indeed is not directly applicable to this situation, since XMPP don't involve browsers. But for websites, the parents attack scenario is not applicable.
Just to be clear (with better details already given by other comments), addressing this is specifically part of the threat model for Certificate Transparency. You could argue that CT policies should be strengthened in various ways, but the threat model does intend to address detecting the compelled misissuance scenario.
CA being in one country and hosting in another greatly complicates this. Ideally the two countries shouldn't be part of Five Eyes or some such.