[rocqua]

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.

[toast0]

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.

[rocqua]

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.

[gnulinux]

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

[rocqua]

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

[gnulinux]

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.

[rocqua]

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.