Drop successful SSLv3 connections using IPtables

PoodleIptables

# Matching 'SSL SERVER HELLO' packets using IPtables
# Using some connection tracking to make sure not 
# to match randomly in the middle of some huge SSL 
# session. 

iptables --insert INPUT -p tcp --sport 443 \
  -m connbytes --connbytes-mode bytes --connbytes-dir both --connbytes 0:500 \
  -m state --state ESTABLISHED \
  -m length --length 46:375 \
  -m u32 --u32 "\
      0>>22&0x3C@ 12>>26&0x3C@ 0&0xFFFFFF00=0x16030000 && \
      0>>22&0x3C@ 12>>26&0x3C@ 4&0x00FF0000=0x00020000 && \
      0>>22&0x3C@ 12>>26&0x3C@ 8&0x00FFFF00=0x00030000" \
  -j LOG --log-prefix "SSLv3 Server Hello Handshake"
  
# Results in log messages such as:

#SSLv3 Server Hello Handshake

Taking the first 500 bytes of the connection is a good performance boost 👍
However, in mitigating POODLE, it was shown that the attacker is downgrading the secure connection from TLSv1+ to SSLv3. Does it require to set up a new TCP connection (and thus resetting the counter) for a client to downgrade in protocols? If not, then you'll probably be missing out on the actual SSLv3 handshake caused by the downgrade attack and only catching the 'regular' SSLv3 handshakes.

"However, in mitigating POODLE, it was shown that the attacker is downgrading the secure connection from TLSv1+ to SSLv3. Does it require to set up a new TCP connection (and thus resetting the counter) for a client to downgrade in protocols?"

I believe that this is required yes. But as I have not seen PCAP data of this part of the attack in progress I cannot be 100% sure.