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.
