Would it be possible to send a dummy ‘first packet’?

just a thought: Instead of dropping RST packets, maybe just hold them back? This ensures that legitimate RST packets get to the kernel and can properly close connections and injected packets (hopfully) arrive after the original packet. You’re out of luck if the ISP drops the original packet, which they probably will if the filter vendor notices this “delay” trick in wide use…

• First, only a fraction, a really tiny fraction, of torrents do include https-URLs for their trackers.
• Second, to circumvent omnipotent firewalls you would have to include your tracker’s fingerprint in those torrents or buy a signature for your certificate.
• Third, clients will need to talk https (the most recent ones, using their OS’s http-engine do).
• Fourth, handling thousands of connections per second suddenly becomes a problem when bignum arithmetics get involved. One would use an ssl proxy to do that, anyway and with an appropriate amount of money you can use crypto accelerators. Until now no open tracker seems to be willing to spend that amount of money or cpu ressources.

However, thanks for pointing out that option.

http://wiki.theory.org/BitTorrentSpecification#Tracker_HTTP.2FHTTPS_Protocol

Sending an RST to the client would be useless anyway, because this is easy to filter on the client-side. Sending it to the tracker is much more useful, because most tracker owners don’t care!