Forum Discussion
Stefan_Klotz
Cumulonimbus
CumulonimbusCBC ciphers in relation to RFC7366 Encrypt-then-MAC
Good morning,
there is a recommendation from German federal security office to still allow CBC-mode ciphers as long as TLS extention "Encrypt-then-MAC" (RFC7366) is in use. But I can't find any information how F5 currently behaves in this regards. Is there any special setting we have to care about or is this already active by default? For your reference, we are running 15.1.8.
Can someone share some more details here? And what are your recommendations/experiences with CBC-mode ciphers?
Thank you!
Regards Stefan 🙂
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.
- Stefan_Klotz
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 🙂
- MegaZone
SIRT
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.
- Nergalex
Employee
Apart 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".
- Paulius
MVP
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.
- Stefan_Klotz
Thanks MegaZone 🙏👍
This is really a clear and useful answer, exactly what I'm was looking for!!!.
And as CCM is not supported from F5 (we are running v15.1.8), the following cipher-string should be good to go for:
TLSv1_3+AES-GCM:ECDHE_ECDSA+AES-GCM:ECDHE+AES-GCM:DHE+AES-GCM:DHE_DSS+AES-GCM
Or would you recommend to keep TLS1.3 disabled or at least move it to the end of the cipher-string?
Thank you!
Regards Stefan 🙂
- MegaZone
Note that ECDSA & DSS will only work if your CERT supports them. If you configure the ciphers, but the CERT doesn't allow it, they simply won't be offered/supported. See https://my.f5.com/manage/s/article/K10340213 and https://my.f5.com/manage/s/article/K24121074
There shouldn't be a problem with TLSv1.3 first - personally I think that's a good idea as any client that supports TLSv1.3 will use it, and only those that can't will fall back to TLSv1.2. You may want to use !TLSv1:!TLSv1_1 - I'd also recommend disabling them on the Options for the VIP, and make sure TLSv1.3 is *enabled* (it is disabled by default): https://my.f5.com/manage/s/article/K33000012
Some scanners may ding you for DHE as it defaults to a 1024-bit key (while the key is rotated periodically scanners can't tell that). We added support for larger DHE keys, but not until 16.1.3 and 17.0.0: https://my.f5.com/manage/s/article/K79342815
- Stefan_Klotz
One final question regarding the "Options List" in the clientSSL profile, which setting will be used if I specify different values in the "Cipher" string and the "Options List"? E.g. the "Options List" includes "No TLSv1.3" (default), but in the "Cipher" string I include "TLSv1_3". Which setting has precendence?
Thank you!
Regards Stefan 🙂
- MegaZone
The Options List will always win. Think of it this way - the Options List dictates which protocols are offered/accepted at all. And then the Cipher configuration specifies which ciphers can be used by those protocols.
If a protocol is disabled in Options, it won't be agreed on in the handshake - so it doesn't matter if ciphers that work with it are enabled. Conversely, if a protocol is enabled in Options it can be agreed on - but of no supporting ciphers are available to agree on.
The keywords in the Cipher config are not actually doing anything with regard to enabling/disabling the protocol, they're just shorthand to refer to *all* compatible ciphers. So '!TLS1_1' doesn't actually turn off TLSv1.1, but it does mean no compatible ciphers will be available - and thus no connection can succeed. Whereas 'No TLSv1.1' disables the entire protocol. (This is also how people get themselves in trouble when they do things like "TLSv1.2" in ciphers, thereby enabling *all* compatible ciphers - including the truly awful ones.)
So you need to both remove 'No TLSv1.3' from Options *and* ensure the required ciphers are enabled for it to actually be used.
- Paulius
Stefan_Klotz The following links might assist you with your task.
https://my.f5.com/manage/s/article/K13431424
https://my.f5.com/manage/s/article/K28345461
https://community.f5.com/t5/technical-articles/cipher-suite-practices-and-pitfalls/ta-p/291127
- Stefan_Klotz
Thanks again MegaZone for this another very useful and clear answer. This was indeed new for me, although I think I have a could knowledge about SSL and ciphers. Is there any other useful command other than "tmm --clientcipher '<cipher string>' " to not only verify which ciphers will be available based on the cipher string, but also include all settings from the option list, e.g. mentioning the clientSSL profile name?
Regards Stefan 🙂
- MegaZone
You're welcome.
Unfortunately, no, I'm not aware of any comprehensive command that would account for all variables. For example, you can configure those ECDSA and DSS/DSA ciphers, and they'll show up with the 'tmm --clientcipher', but if the cert connected to that VIP doesn't support ECDSA/DSA then those ciphers will not actually be offered at all. They just silently get disabled.
With the Options the ciphers are technically enabled and available, but since the protocol version is disabled they're just never called for.
- Stefan_Klotz
MegaZone another question came up during checking clienssl profile statistics.
I see some profiles, which have counters for TLS1.0 and/or TLS1.1, although they are disabled in the cipher string list (with !TLSv1:!TLSv1_1:!3DES). Where is this coming from? Shouldn't this be all zero?!?! Or do I have to disable TLS1.0 and TLS1.1 via the Options List? Any more details would be very helpful.
Thank you!Regards Stefan 🙂
- MegaZone
It's hard to say, but if they're not disabled in the Options List it could be that the handshake is agreeing on TLSv1.0 or v1.1 as the protocol, and then failing when they can't find a cipher (since no cipher is enabled for those protocols). Disabling then in the cipher configuration is not turning off the entire protocol, it is only disabling the ciphers - which means it will effectively fail to connect, but it may fail in a different way than if the protocol is disabled.
