Right, and that's a fundamental sea change in PKI security posture since the Iranian "ComodoHacker" and the Soghoian and Stamm compelled issuance paper! My point is just that some attackers might be willing to have their attacks show up in public logs if their victims are unlikely to ever notice that and if nobody else is likely to notice it either.
With Let's Encrypt we made a lot of people's certificate management a "fire and forget" thing, which is exactly what we hoped to do, but if they completely forget about it, it may be that there will be lots of targets against whom nobody would notice certificate misissuance.
I got every self-hosting sysadmin I know to run certificate monitors for sites they maintain but it certainly isn't a common thing to do. I know Cloudflare has a beta certificate monitoring feature which would certainly help a lot with this problem considering their market share if they enable it by default. (Although one problem with this is that they issue backup certificates from other CAs so it'd easily trigger warning fatigue!)
(I wasn't aware of your credentials when I made my previous comment so I assumed you didn't know about mandatory certificate transparency which is a mistake on my part, sorry! I'll make sure to check profile about sections before I assume again.)
Yeah, I think it's tricky to know how most sysadmins could make good decisions about this information, especially when misissuance is likely to be less than 1% of 1% of all CA issuance and automated renewal is working properly. Warning fatigue is a pretty big deal here!
Also, we made Certbot randomize the subject key by default every time it renews, so you have a huge amount of churn in subject keys, so you can't just say "oh, well, this public key has been used for a long time, so it's probably correct!". Every subject key is typically new and is unrelated to every previous subject key.
I hope that won't turn out to have been a poor trade-off. (We thought it was good to have more turnover of keys in order to reduce the impact of successfully stealing or cryptographically attacking one.)
Not only.
Example: Chrome on Android did change some time ago so if CA is in System store (which means it got here from manufacturer or from user which does have root access) - such CA MUST use Certificate Transparency. This rule doesn't apply if CA is in User store (installable by regular user) - https://httptoolkit.com/blog/chrome-android-certificate-tran...
Another example: Yandex Browser ONLY trust Russian NUC certs if they are in public CT logs,not otherwise (https://habr.com/ru/companies/yandex/articles/667300/ - text is in Russian) (as far as I understood, NOT trusting this CA al all is not option for them or their users, and if user is using chrome/firefox and needs access to sites which use this CA - CA will be just be installed manually so Yandex's solution is more secure, thanks to CTs).
Intel people really don't want to get caught (and whatever CA they use really does not want to get caught), CT turns the attack into a gamble. Even if nobody is checking most sites, CT still creates a deterence factor. Not perfect, but a lot better than the previous status quo.
There's definitely a lot of people watching CT for anomalies (I'm one of them), but more surveillance of it is also good and something I've been trying to advocate.
It's also why I'm personally against SMIME and think it's a bad idea.
Comments
Certificate transparency prevents this style of attack.
As long as the victims are checking it and know what to look for!
Chrom(e/ium) and Safari don't trust certificates that are not in public logs [0].
[0] https://en.wikipedia.org/wiki/Certificate_Transparency#Manda...
Right, and that's a fundamental sea change in PKI security posture since the Iranian "ComodoHacker" and the Soghoian and Stamm compelled issuance paper! My point is just that some attackers might be willing to have their attacks show up in public logs if their victims are unlikely to ever notice that and if nobody else is likely to notice it either.
With Let's Encrypt we made a lot of people's certificate management a "fire and forget" thing, which is exactly what we hoped to do, but if they completely forget about it, it may be that there will be lots of targets against whom nobody would notice certificate misissuance.
I got every self-hosting sysadmin I know to run certificate monitors for sites they maintain but it certainly isn't a common thing to do. I know Cloudflare has a beta certificate monitoring feature which would certainly help a lot with this problem considering their market share if they enable it by default. (Although one problem with this is that they issue backup certificates from other CAs so it'd easily trigger warning fatigue!)
(I wasn't aware of your credentials when I made my previous comment so I assumed you didn't know about mandatory certificate transparency which is a mistake on my part, sorry! I'll make sure to check profile about sections before I assume again.)
Indeed, the fact that Cloudflare emails out CT warnings due to their own backup certs is rather embarrassing.
Yeah, I think it's tricky to know how most sysadmins could make good decisions about this information, especially when misissuance is likely to be less than 1% of 1% of all CA issuance and automated renewal is working properly. Warning fatigue is a pretty big deal here!
Also, we made Certbot randomize the subject key by default every time it renews, so you have a huge amount of churn in subject keys, so you can't just say "oh, well, this public key has been used for a long time, so it's probably correct!". Every subject key is typically new and is unrelated to every previous subject key.
I hope that won't turn out to have been a poor trade-off. (We thought it was good to have more turnover of keys in order to reduce the impact of successfully stealing or cryptographically attacking one.)
The other argument is, why bother MITMing when you can go to Cloudflare and get them to share the data with you :)
Not just Safari, but all TLS connections instantiated on Apple OSes
Not only. Example: Chrome on Android did change some time ago so if CA is in System store (which means it got here from manufacturer or from user which does have root access) - such CA MUST use Certificate Transparency. This rule doesn't apply if CA is in User store (installable by regular user) - https://httptoolkit.com/blog/chrome-android-certificate-tran...
Another example: Yandex Browser ONLY trust Russian NUC certs if they are in public CT logs,not otherwise (https://habr.com/ru/companies/yandex/articles/667300/ - text is in Russian) (as far as I understood, NOT trusting this CA al all is not option for them or their users, and if user is using chrome/firefox and needs access to sites which use this CA - CA will be just be installed manually so Yandex's solution is more secure, thanks to CTs).
Even still, it turns it much more into a gamble.
Intel people really don't want to get caught (and whatever CA they use really does not want to get caught), CT turns the attack into a gamble. Even if nobody is checking most sites, CT still creates a deterence factor. Not perfect, but a lot better than the previous status quo.
There's definitely a lot of people watching CT for anomalies (I'm one of them), but more surveillance of it is also good and something I've been trying to advocate.
It's also why I'm personally against SMIME and think it's a bad idea.