Forum Discussion
CBC ciphers in relation to RFC7366 Encrypt-then-MAC
- May 17, 2023
To my knowledge BIG-IP does not support/use the 'Encrypt-then-MAC' RFC7366 TLS extension. In fact, I can't find any mention of this RFC in our internal systems, so it is probably safe to say it is not supported. I think that, in general, the industry moved to AEAD ciphers instead.
As for AES-GCM - while it might be possible to configure a modern client NOT to use it, that'd very much be the exception and not the rule. Any browser old enough to lack AES-GCM support would be old enough to have many other issues (and probably wouldn't support TLSv1.2 anyway), so you're better off not allowing those to connect in the first place.
Especially has TLSv1.3 only has five supported cipher suites - and two of those are AES-GCM:- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_CHACHA20_POLY1305_SHA256
So AES-GCM support is basic table stakes for TLS these days.
Thanks Paulius for sharing these links, especially the article from MegaZone (although I already know the summary PDF).
But I still can't find any hints regarding this "Encrypt-then-MAC" thing. So let's ask the other way round, as TLS1.0 and TLS1.1 shouldn't be used anyway, is there any other drawback of AES-GCM? I mean can ALL clients support GCM as long as they support TLS1.2 or might there be configurations out there, which can only support TLS1.2 with CBC-mode ciphers?
Thank you!
Regards Stefan 🙂
- MegaZoneMay 17, 2023SIRT
To my knowledge BIG-IP does not support/use the 'Encrypt-then-MAC' RFC7366 TLS extension. In fact, I can't find any mention of this RFC in our internal systems, so it is probably safe to say it is not supported. I think that, in general, the industry moved to AEAD ciphers instead.
As for AES-GCM - while it might be possible to configure a modern client NOT to use it, that'd very much be the exception and not the rule. Any browser old enough to lack AES-GCM support would be old enough to have many other issues (and probably wouldn't support TLSv1.2 anyway), so you're better off not allowing those to connect in the first place.
Especially has TLSv1.3 only has five supported cipher suites - and two of those are AES-GCM:- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_CHACHA20_POLY1305_SHA256
So AES-GCM support is basic table stakes for TLS these days.
- NergalexSep 22, 2023EmployeeApart from the reference of Encrypt-Then-Mac in this vuln K55462146, I found nothing too. It seems MegaZone is right when he says "I think that, in general, the industry moved to AEAD ciphers instead": regarding wikipedia "the Encrypt-and-MAC (E&M) approach has not been proved to be strongly unforgeable in itself".
- PauliusMay 17, 2023MVP
Stefan_Klotz Sadly I'm not 100% on this behavior but it is possible to change the cipher suite depending on what you see in the TCP connection utilizing an iRule. I am not positive if the iRule can be made to search for the "Encrypt-then-MAC" in the connection but a lot is possible via iRules so smoeone else who has a bit more experience with this setting might be able to assist you with the iRule in question.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com