Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft failed to rotate certificates for winget CDN on time

cdn.winget.microsoft.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Microsoft failed to rotate certificates for winget CDN on time

#21

Post by derefr »

t0mas88 wrote: post #17
moremetadata wrote: post #13

Earlier quoted context omitted.

You are forgetting something. If you want to reinstall some old software, lets say MS Small Business Server 2000 or Small Business Server 2003 today, the certificates in the installation files prevent the installation of said software. So you wouldnt even get as far as being able to remove any certs. Your only recourse is change the system date and time back to before the certificates in installation files would have…

What? 2 seconds? That sounds crazy. It either breaks ongoing connections or wastes addresses since you would have to keep your old one until all connections are closed.

It probably wasn't really "issuing a new IP address" per se, but rather CGNAT, where your apparent IP from the perspective of an IP reflector would be the IP of whichever NAT gateway your outgoing connection had been round-robin-load-balanced onto. Under CGNAT, you don't really have any single public IP; or rather, in another sense, you (and 100k other people) "have" all N public IPs at once — just like devices on a NATed home network all share the one IP address assigned to the gateway router in front of the NAT, and would all "have" multiple addresses if that gateway-router were multi-homed.

Re: Microsoft failed to rotate certificates for winget CDN on time

#23

Post by Thorrez »

moremetadata wrote: post #13
8organicbits wrote: post #11

Earlier quoted context omitted.

When a certificate expires, it can be removed from the CRL. If certificates never expire then the CRL grows without bound. Also, checking CRL is implemented in different ways. Some checks may be "soft", where a connection failure to the CRL is ignored. You probably want this anyway, if the CRL goes offline you don't want the internet to break. An expiry check, on the other hand, works as long as your clock is accurat…

You are forgetting something. If you want to reinstall some old software, lets say MS Small Business Server 2000 or Small Business Server 2003 today, the certificates in the installation files prevent the installation of said software. So you wouldnt even get as far as being able to remove any certs. Your only recourse is change the system date and time back to before the certificates in installation files would have…

>If you want to reinstall some old software, lets say MS Small Business Server 2000 or Small Business Server 2003 today, the certificates in the installation files prevent the installation of said software. So you wouldnt even get as far as being able to remove any certs.

I think at least in some cases it'll still work. What matters is that the signature was created while the cert was still valid, not that the installation happens when the cert is valid. How do we prevent backdating attacks? By using a separate timestamp signature.[1]

TLS is different. It requires the cert-holder (aka webserver) to be online at all times. You don't need to be able to validate a signature created in the past. So TLS doesn't have this problem and thus doesn't need its solution (timestamp signatures).

[1] https://stackoverflow.com/a/3428386

Re: Microsoft failed to rotate certificates for winget CDN on time

#25

Post by voytec »

josephg wrote: post #20
Uvix wrote: post #5

Earlier quoted context omitted.

The maximum expiration time is now down to 13 months, for certs that need to be valid in a browser. And if you want to cycle yours more frequently, you can. But there's enough places that can't set up automated processes that trying to make it 90 days for everyone would be a lot of pain and a lot of broken sites.

> But there's enough places that can't set up automated processes Why can't they be automated? And anyway, this is the exact problem that short expiration times avoid! Systems that aren't set up for automation, and rely on someone once a year remembering some creaky, error prone process to get a new cert. Much better to force short expiration times so manual cert renewal is a thing of the past.

DV is not the only kind of certificates validation. I don't want to have to go through the OV/EV validation process several times a year, nor to validate 4 certificate issuances a year in advance.

But if I wanted to, I can do so even now without being forced - request new certificate during it's validity period, and revoke the former one.

Re: Microsoft failed to rotate certificates for winget CDN on time

#26

Post by cookiengineer »

josephg wrote: post #4

I think the default certificate expiration time (2 years) is a terrible idea. Its long enough that there's a good chance whoever registered the cert last time has left the team or the company. Its long enough that I've forgotten how to generate a certificate with openssl on the command line. And its long enough that each time, I (and everyone else) can justify not bothering to automate the process. But 2 years is sti…

Advantage of certbot: a systemd timer that runs every other week is very easy to write, because "certbot renew" doesn't need any user interactions.

So it's literally < 10 lines of systemd unit file to automate it.

Re: Microsoft failed to rotate certificates for winget CDN on time

#27

Post by janoc »

josephg wrote: post #4

I think the default certificate expiration time (2 years) is a terrible idea. Its long enough that there's a good chance whoever registered the cert last time has left the team or the company. Its long enough that I've forgotten how to generate a certificate with openssl on the command line. And its long enough that each time, I (and everyone else) can justify not bothering to automate the process. But 2 years is sti…

If you don't automate, don't document and don't check that it is actually working your process from the get-go it is only your own fault, especially when working on industrial scale like this.

Rotating the certificates constantly works for personal websites but it is not ideal in places where one can't easily update things - like behind corporate firewalls or where corporate processes permit updating/replacing things only in fixed cycles, which are often much longer than 90 days.

Don't remember the Let's Encrypt root certificate expiring fiasco from year ago? Granted, that wasn't really Let's Encrypt's fault but it shows well that these things can be a tad more complicated than just running a script every 90 days.

Re: Microsoft failed to rotate certificates for winget CDN on time

#28

Post by janoc »

Jamie9912 wrote: post #22

Aaaand it's still not fixed. I think this just goes to show how much red tape there is around processes at Microsoft.

You realize it is Sunday, right? And that probably a lot of relevant people are not in the office today, even if the techops grunts who are on call are scrambling.

Re: Microsoft failed to rotate certificates for winget CDN on time

#30

Post by linsomniac »

Hamuko wrote: post #18
phpisthebest wrote: post #6

Earlier quoted context omitted.

>>to set up processes which automate renewal. that is all fine and good for things that have the ability to automate that process, plenty of hardware and device do not. Some are not even legacy are still actively being sold and developed It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process, sure you could do your own internal PKI and…

> It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process Why not? Just use DNS validation.

Yep, I do this for internal names, works great. I've used acme.sh to update the names in a public zone that is isolated from the rest of the zone and has it's unique AWS credentials to update via Route53.
Post reply on HN