Thanks for the links, rugk. These attacks are very theoretical and far from really affecting current connections. Especially using AES in hardware (AES-NI), whatever its performance may be, should save you from the timing attacks. And as far as I understand it, the other attacks released by Bruce Schneier in 2009 don’t apply at all to regular TLS connections and make very specific assumptions about nonstandard round length, known plaintext and related-key knowledge.
However, I don’t want to go into a debate about the presence or absence of AES256 security qualities. What I wanted say is that it is useless to enforce server-side cipher order (SSLHonorCipherOrder On) and list the AES256 ciphers behind their AES128 counterparts if all browsers which implement AES256 also implement AES128. So only those clients who tweak the ClientHello disallowing AES128 and only offering AES256 would actually ‘benefit’ from supporting this said-to-be weaker encryption based on AES256. Then, why have it on the list at all?
So, presuming “SSLHonorCipherOrder On”, if someone still feels safe with these discovered AES256 weaknesses he should actually put the AES256 ciphers in front of the respective AES128 ciphers – otherwise they’re never used at all. On the other hand, if he doesn’t trust AES256 for some reason, he should just throw these ciphers off the list instead of just moving them to lower priority.
Point is: Don’t use magical pattern matching in the SSLCipherSuite entry. Keep the list explicit and as short as possible. Understand (and possibly document) each used cipher’s strengths and weaknesses and which cipher is used by which browsers and what you think would be an appropriate time to drop it. Use SSL Labs tests early, use them often. Keep an eye on security mailing lists, and check your settings whenever you do an upgrade of any of your SSL/TLS related components (e.g., Apache/nginx, OpenSSL/LibreSSL, CPU with/without AES-NI, certificate renewal, key family upgrade RSA/ECDSA).