At some point browsers will stop allowing certificates that are not logged through CT
Makes sense. So to be sure nobody issued a cert for one of my properties I would have to check regularly on CT logs to be sure that only certs requested by me are issued. But in that case, if someone requests a cert for one of my properties, and that cert was not requested by me, what do I do?
Do I tell mozilla and google that "someone issued cert id 4d8effdd25 for my nextcloud installation (or my forum where some rebellious users meet up sometimes) to mitm me, but it was not me". Will they belive me? And it will be probably to late anyway, because propagation to a CT log can take up to one day, so they got data on all the traffic for a whole day.
Couple that with most providers requiring you to prove your domain via DNS or organizational status and you narrow the attack window.
Also I'd assume that as the owner of a domain, you'd be able to revoke any certificate for your domain that you didn't create.
This is where a TLSA record would help to prevent malicious certificates. At least, if the client (browser) validates TLSA records.
If a government was coercing a CA, they'd just tell them to disable this check. If this can be proven it's grounds to start the distrust process. At the very least, they should fail their next WebTrust audit.
You would indeed, which is part of the reason I released this service + libraries, so some enterprising developer can build a nice alerting service with it for folks just like you!
> Do I tell the mozilla that "someone issued cert id 4d8effdd25 for my nextcloud installation
Not exactly, I believe you'd probably contact the certificate issuer who issued the original certificate to have them issue a revocation, but my sincere hope is that folks running CAs will eventually come up with some better method for flagging certificates as bad/malicious than "just email Symantec support", since I wouldn't wish that on anyone.
I launched https://ctadvisor.lolware.net/ some time ago.
Basically. You'd send a report to the CA telling them there was a misissuance, and if their answer isn't to your satisfaction, you can report it to Mozilla and the other browsers on the public mailing list, claiming a misissuance by the CA. The browsers would then force the CA to follow up.
They're almost exclusively used for digital ID servives (and, according to some sources, MitM), and are in browsers anyway. CT won't help with that.
Do you have any source for that certificate being used for MitM?
There are a few stories about this in the 2013 Snowden data actually, the SPIEGEL published stories about that back then, too.
I'm far more enraged by the decision of the Bundesdruckerei to not offer on-card signing features for the ePerso anymore.
Instead, you have to use their web service to sign, and it costs you even more money. And is obviously ridiculously insecure.
Yes, this is exactly what you should do. There's a very active list by mozilla ("dev-security-policy") where CA missteps are discussed on a regular basis, that's a good place to bring up all issues with CAs (however most of them are much more minor than a mitm attack with a fake cert - the day to day business is more "this cert violates RFC something").
> Will they belive me?
Well, the malicious issuance of a certificate is high profile enough that they will at least investigate and the CA will have to show some evidence how the cert has been issued.
> And it will be probably to late anyway, because propagation to a CT log can take up to one day, so they got data on all the traffic for a whole day.
That is in principle true. CT does not directly prevent attacks. But the general idea is this: CT makes it very likely that attacks get detected. A malicious attack by a CA is almost certainly the end of their cert business. So while an attack is still possible, it becomes very expensive, you basically have to sacrifice a working business.
CertSpotter does this for you automatically: https://sslmate.com/certspotter/
In most countries, law enforcement are disinclined to use tools that will only work once - because what if they need that tool tomorrow for something more important? So this provides you with a bit of herd immunity, there is probably someone doing something naughtier than you who would be a better target.
It is also legally easier to get away with demanding that somebody do something they already _can_ do than to demand they come up with a way to do something they can't already do. British courts for example asked Internet Service Providers "Do you have a way to block web sites, e.g. for having child pornography on them?" and all the big ISPs said "Oh yes, we have that" and then the courts said "Aha. OK, then you must use that to also block copyright infringements, Hollywood will tell you what to block". But for the tiny ISPs like mine that said "No, we just move bits - nazis, child porn, bomb making, if it's illegal then you should convict the people doing it, not our problem" the courts said "Then it would be outrageous for us to demand you do as Hollywood asks, carry on as you were".
Because CT logging is mandated by Google, most CAs are building systems that automatically log everything. So then "Issue this but don't log it" becomes a huge ask, the front line guy the secret police get to says "I don't have a way to do that, it always logs everything" and that increases the chance the spooks get forwarded to an executive who says "Woah, this suicides my whole company, you better get yourselves a warrant, and I am calling my lawyer right now".
The Coinbase Engineering blog actually just put out an article on this very topic today - https://engineering.coinbase.com/moving-to-expect-ct-d0d26a0....
I see two issues with that:
1) the browser vendors know each site and subdomain I visit. This seems to be a privacy issue.
2) every new visits adds a lot of latency because they need to check the certificate every time I request a site (now it becomes: dns, ssl handshake, cert check, http transfer).
3) when the cert check server is down, what is supposed to happen? Fail every ssl request? This adds a new point of failure. Just allow it? An attacked could black-hole the dns or block the IP address.
The web server sends a Signed Certificate Timestamp in the TLS Handshake¹. The browser will check that.
Apache support is coming², and other web server vendors are probably working on it as well.
Chrome is scheduled to do start doing this in April 2018