So the Untrusted CTL has an expiration of 25 hours. Your screenshot says "Did you know? ... the Untrusted CTL is updated once per day". Doesn't that explain it?
In the screenshot, it says that CTL was last modified in March. Judging by the date, I'd guess it has an expiration of 6 months after it is issued. So, it's been nearly 6 months since the daily updates stopped occurring.
Is that the time it was last modified or the time it was last signed?
The last high-profile mis-issued cert was last week, and didn't even escape the control of people who were entrusted with the CA private key. So MS might not even be manually revoking it. Before that, the last blog post on googleonlinesecurity.blogspot.com about a mis-issued certificate was ... March 23.
I would guess that it's re-signed daily, but only changes when there's an actual change to be made.
Following up: if anyone wants to poke around at the file, the download URL is http://ctldl.windowsupdate.com/msdownload/update/v3/static/t... , a CAB archive that contains a single file disallowedcert.stl. That file itself is DER-formatted ASN.1, evidently a PKCS7-signed "Certificate Trust List" (1.3.6.1.4.1.311.10.1). `openssl asn1parse -inform der -in disallowedcert.stl` reads it just fine.
There's a reference to the date 150923203626Z (2015-09-23 20:36:26 UTC) somewhere in there, but I'm having trouble figuring out what it applies to.
Actually it's the expiration timestamp of signing certificate "Microsoft Certificate Trust List Publisher". I intended to add this info in the blog post but can't do it right now.
It appears to be a signed message, and for these sorts of things, I'm more of a fan of signed data (and the transport being unimportant) than a signed transport and unsigned data: there's a lot less attack surface on both ends.
apt, yum, PGP, etc. work the same way. There remains a decent argument for a secure transport anyway for privacy / avoiding side channels, or a general desire for HTTP delenda est, but it's nowhere near as strong an argument, HTTPS only provides marginal benefit to the side channels (Tor to a hidden service is much more effective), and other engineering concerns can legitimately override these concerns.
I think that may be purposeful. If your local certificate management system is on the fritz, you don't want that rejecting updates to the core cert lists. Probably better to fall back on some other cryptological system on the files themselves, since the content is not private, it's just the authenticity you care about.
I don't think it's really a big deal. Since the list is signed, an active attacker would only be able to replay an old version of the list... but it's hard to see how that would be worse than just blocking the request entirely.
An older version of the list might be missing a recently compromised certificate, though. Of course, you need to both MITM someone and compromise an important cert, so that's not the sort of thing just anybody could pull off.
Right, but assuming Windows isn't dumb enough to accept a remotely downloaded version that's older than the one it already has locally, the effect would be the same as if the attacker just prevented you from receiving new updates. And HTTPS wouldn't make it any harder for them to do that.
> the effect would be the same as if the attacker just prevented you from receiving new updates.
True, but it might be slightly less visible because you'd get an "update" instead of a failure. Also, I wonder if anyone has actually tested that scenario?
I'd like to believe that's true and that should be true, but I'd also have to actually test it before trusting it to be true.
Additionally, old versions will expire, so there's a limit to how far back you can keep someone, even if you continuously intercept the update attempts.
I believe this is less about what one individual computer would do and more about what could happen to the millions of Windows users facing this problem in 25 hours.
Finding out what happens to one computer seems like a better start to informed speculation about millions of other computers than not finding out. Sure, it's no guarantee they're all the same, but we can more reasonably discuss whether the observed effects are plausibly widespread after observation...
Why does the app say you're at risk if the certificate is still valid, and why does it say that the last check for one of the lists in the future? Feels like the usual crypto-fearmongering to me.
Can you post a screenshot? "Updated" can mean different things in this context. For the issue to be resolved, Microsoft also has to update the signing certificate itself, which it hasn't done for the last 15 months.
I'm trying to get my head around what a CTL is anyway. I might be tired and a bit hungry (never helps my cognitive processes) but I was struggling to understand the Microsoft article I found here:
Right. What I meant was actually that they either support it or are in the process of supporting it. But I haven't heard anything about it from Microsoft.
