Well, almost. AES-GCM is also "Cryptographically Broken" if you take into account software implementations using table lookup schemes that are subject to cache timing attacks. But the fundamental AEAD support in TLS1.2 is a much better place to be overall - and GCM tags are much better than the MAC-then-Encrypt HMACs elsewhere in TLS. For practical purposes; AES-GCM is the "least worst", by a long way.
"The end result is that Chrome talking to Google uses AES-GCM if there's hardware support at the client and ChaCha20-Poly1305 otherwise."
It seems to be specific to Chrome though, and all TLS clients would have to reimplement that choice.
Would be good if there was a way to tell the SSL library to give you the best cipher that works on your hardware
(i.e. don't give AES-GCM/AES-CBC when there is no hardware support and the software implementation isn't constant time).
What is frustrating is how many such servers have TLS 1.3 intolerance (even PayPal), and often the same servers are also affected by this bug. I wonder what TLS implementation is this.
POODLE worked not only against SSLv3, but also against any TLS implementations that check padding in SSLv3's style (e.g., just checking the last byte, and ignoring the rest of the padding). SSL accelerators from F5 and A10 were vulnerable. Thus, many of the world's largest sites were vulnerable.
So this means AES-GCM essentially?