The CTCP VERSION command makes the mIRC user send a known plaintext encrypted though SSL which helps the BEAST attack.
This way, if the the attacker (Eve) is between the user (Alice) and the server (Bob) e.g. on the local network, then Eve will be able to decrypt all encrypted communications between Alice and Bob.
If I understand the attack correctly, both these statements are wrong.
First of all, Eve will not be able to decrypt all communication. All Eve will be able to do, is check whether the data immediately preceding the plaintext she injects, is equal what she already had in mind. The BEAST attack bruteforces one byte at a time by repeatedly tesing for this equality against all of the possibly byte values after cleverly manipulating block boundaries. That is: it has to repeat the same attack 256 times on the
same input to figure out
one byte of that input. In terms of IRC, that makes it useful only for some data that is sent over the IRC connection repeatedly -- possibly for bruteforcing oper or service passwords over time, but not for actual conversation text which is usually sent only once.
This could still be a problem in certain situations, but that brings me to your other claim. It is also not enough to have just
any known plaintext be sent, it has to be a piece of plaintext that is
completely controlled by the attacker, because the attacker must ensure that her plaintext when XOR'd with the previous two messages' IVs equals what she thinks might be the previous message's plaintext, so that she can test for equality after encrytion. The bottom line? The version reply does not help Eve at all.
Of course it would be much easier to attack the communication from the server to the client rather than the other way around, because in that case Eve need not solicit replies from mIRC and can just stick to sending things to it. But it seems that the linear, ASCII-oriented, command-prefixing IRC protocol makes any attack like the BEAST attack pretty much infeasible by nature anyway.
