Where do you think that client.reconnect command originated anyway? It was not sent by your legitimate stratum servers, that's for sure. And not just anyone can send it, it must arrive on your open stratum connection, or forged to look like it, in order to be processed. Or the attacker must have been able to break your active stratum connection, or wait for it to break naturally, and then redirect you to a rogue server in order to send you that client.reconnect command.
I watched the attack occur and did some analysis (apparently unlike yourself?), and I don't believe there was any prior 'redirect' to a rogue server. My prior comments are more then just speculation... The client.reconnect command appeared to come from the legitimate stratum server. Aka, was "forged to look like it" as you suggest above. I explained above in reasonable detail exactly how such an attack could be potentially replicated. Go try it yourself if you have enough knowledge.
The only other attack method I can imagine based on what I observed, would be TCP injection at (a) key router(s) (by modifying packets and re-calculating header checksums). But, I highly doubt this is the case (else it probably would have been more wide-spread).
I can also assure you that it is still possible at this moment to capture the TCP headers of traffic destined for other servers on OVH right now - more complicated then it was a few months ago since they have been patching their switches, but still possible. The TCP header of course contains the miner IP, port, and current TCP sequence number - which, given the right setup, would be sufficient to counterfeit a packet from the stratum server. You might want to read about TCP injection attacks relating to TCP sequence prediction, if you were not aware this is possible:
http://en.wikipedia.org/wiki/TCP_sequence_prediction_attackFYI: I don't talk about things I am not knowledgeable about. I have nothing to prove (obviously unlike yourself), but I can assure you my knowledge of networking is higher then you might like to believe.
What/where is this patch?
It is not a complete solution, but it does help to a degree, if the next attack mirrors the previous one. Client.reconnect commands were included in the stratum mining protocol for a reason. The 'patch' to which you are referring is built into the latest versions of kalroth cgminer and veox sgminer. Just check their docs for use of no-client-reconnect option. But be forewarned, some pools might legitimately utilize the command, either now or in the future, so to enable it could break certain functionality. But poolwaffle has stated that he does not ever use it, so safe to use here.
It is a complete solution tho... If a pool wants to re-direct my miners somewhere else before the pool goes offline or something, I don't care - that's what fail-overs are for. There is no overly useful case for Client.reconnect that I can imagine. The stratum commands client.reconnect and client.get_version were added to cgminer in v2.8.2, as an aside.
In the copy of sgminer I am running, I simply disabled the client.reconnect ability entirely. Was a 5 second patch.
The reason Slush added client.reconnect to the protocol, btw:
* Implemented method client.reconnect(host, port), so pool can now easily balance clients between backends or gracefully shutdown a backend without a miner outage.
You are missing the point completely and if you cannot imagine another attack scenario, then your imagination is limited. If you happen to look back through this thread, you will find that I was the first to suggest that client.reconnect was being used as part of the attack. And if you look closely, you will find that I spelled out the exact potential attack scenario that you are preaching as gospel, and ironically enough now "teaching" me how it could be carried out. And also that mostly all of the ideas you presented as your own were only summaries of ideas that others had posted here before you -- with the notable exceptions of your misconceptions, that is.
It is all in the thread history. I am not going to correct your errors, as you can continue to believe whatever it is you wish to believe, but
Simply stated, you are drawing false conclusions from an incomplete set of actual facts.
FYI: I don't talk about things I am not knowledgeable about. I have nothing to prove (obviously unlike yourself), but I can assure you my knowledge of networking is higher then you might like to believe.
This is the reason that I included some relevant wisdom from Hawking in my earlier reply. You're funny -- as in you amuse me like a clown, for those readers here who are fans of Joe Pesci in Goodfellas.