> Those arguments are invalid.

Your individual statements are correct, but they do not add up to valid argument in this case.

Kazakhstan forces their citizens to install government-issued certificate to use SSL. This allows Kazakhstan to track their citizens. Which proves, that a regime can track it's citizens even in presence of SSL encryption. In other words, using SSL/PKI does not inherently prevent tracking by powerful entities. You need to create your own government for that.

It is naive to think, that regimes like egypt/syria/US can't track people, while at the same time being able to exert overwhelming physical force over the exact same people. If you can force someone to hand over encryption keys, you can track them. Different countries do the same thing, everyone just picks their preferred ways: physically controlling Certificate Authorities in case of US, handing over encryption keys in case of Great Britain.

> Compare that to yum/rpm which use secure https and signed rpm and signed metadata

No, using more "secure" technologies does not amount to better security.

> Kazakhstan forces their citizens to install government-issued certificate to use SSL.

So why debian/ubuntu vulnteer to remove this layer? Why doing the equivalent of installing random certs for every gov/isp on every user?

Yes, government can force someone to install it, but it won't use force on every single person.

> Regimes like egypt/syria can track people who try install tor and they can cherry-pick block repos based on package name.

They say https would not add privacy in this context because the package size (almost) uniquely determine the package name. Why is this invalid?

You can block based on a name because you see the name before the package is sent.

You can't block based on package length, because you need to let the entire update through before you know the length. At that point, it's too late to block. Buffering the entire message doesn't work because TCP expects ACKs.

A) you can buffer and send acks to the server and then trickle the data to the client

B) in the interest of memory usage, you could not buffer, and send selective acks to the server -- once you decide to allow it, stop blocking the first data packet, and let the client ack that without the sack and let the server retransmit.

c) b, but for network efficiency, actually let the client receive all packets but the first, and sack them itself --- then when you do allow the first packet, the rest of the packets won't need to be retransmitted.

Ah, I confused the hierarchy between TLS and TCP. I thought the acks were protected by TLS, but they are not.

There are still timeout issues with the buffering, but it is a lot weaker defense.

You can just buffer one packet and reject it if you want at the end.

That'd pop up a mention of 'failed update' whereas in plaintext you can simply refuse to provide any packages.

That doesn't make sense? If you have the capability to refuse all http packages, you can still refuse all https packages coming from debian. My comment was for refusing specific packages in https. Buffer the first package and ack. Then wait the rest, count the bytes. If bytes == N then I know this person is downloading tor, refuse the first package such that they can never download tor.

At that point, the client has initiated a specific update or install that fails. This is different from simply censoring the existence of a package.

"Why do you need a speedometer when you can just calculate your current speed using tachometer, odometer and time, it's real simple man"

It is. You want to download Tor in some hard to track way, you probably shouldn't use an easily trackable source. There are better options including getting sent an email and torrents.

And given the scope of the attacker, fingerprinting by size and server is trivial so easily https adds nothing related to anonymity nor security.

Ok, fair enough.

This would have been prevented

https://www.debian.org/security/2019/dsa-4371