But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented.
Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.
>Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.
Oh definitely, GCM (or another AEAD cipher) is a much better choice - I wouldn't argue in favour of CBC in production TLS cipher suites. I just wanted to comment on the technical details of where padding oracle vulnerabilities actually arise.
GCM is only a better choice if you have hardware support for it. I'd recommend Chacha20-Poly1305 for anything that might have to cope without hardware support.
Of course a problem with encrypt then authenticate is that you can verify the identity of the sender without decrypting the content, which is of course why A then E happened in the first place - the threat model turned out to be incorrect. For messaging platforms I would still lean towards authenticate then encrypt as I think the attack model is different.
Also: nobody uses SHA1 anymore, SHA1 and SHA2 aren't MACs (you're thinking of HMAC), and even MD5 is still unbroken in HMAC.