CirrostratusSupposedly AES-GCM should be the "best" cipher right now in terms of efficiency, however I noticed when enabling it on the F5, CPU goes up significantly. This is on a Viprion 2100 blade, 11.5.1 HF6. Anyone else seeing this?
I'm using "MEDIUM:!ADH:!RC4:@SPEED:RSA+3DES" for the cipher string. Adding a "!AES-GCM" to the line causes the CPU to immediately drop.
Are you still using the NATIVE SSL stack or did you change to COMPAT in the SSL profile? https://support.f5.com/kb/en-us/solutions/public/13000/200/sol13213.html
I think this confirms that:
https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13163.html
Looking at that solution, it has a command to run and verify that AES-GCM is in your NATIVE, but in 11.6 it is. If you do a "show ltm profile client-ssl can you tell which ciphers are mostly being used now that may be more efficient?
CirrostratusI'm using "MEDIUM" with a couple tweaks and all those ciphers, including anything AES-GCM, should be native. The statistics do confirm this:
We've had some issues in the past with the SSL acceleration on the Viprion 2100 blades, so I'm suspecting it's a performance bug.
CirrostratusI opened a support case and they confirmed it's been reported by a few customers and is likely a bug. The suggested work-around is put !AES-GCM in the cipher string.
Another work-around I discovered was prefer 256-bit AES over 128-bit. The major browsers don't support 256-bit AES-GCM, so they'll negotiate regular AES and essentially you'll never see the issue.
CirrusWere you provide with a bug ID?
CirrostratusNot yet - it sounded like they've just found out about this within the last couple weeks. I'll post the bug ID here when it's provided.
Cumulonimbus
EmployeeID 501045 - Add support for SHA256 and SHA384 to the Nitrox driver
ID 499946 - Nitrox reports bad record error on highly fragmented SSL records with aes-gcm ciphers
Cr. Erick, Piotr, Mike
Cirrostratus
NoctilucentID 501045 - Add support for SHA256 and SHA384 to the Nitrox driver
ID 499946 - Nitrox reports bad record error on highly fragmented SSL records with aes-gcm ciphers
Cr. Erick, Piotr, Mike
CirrostratusCirrostratusAh, so the problem isn't so much AES-GCM but rather SHA384 or SHA256 as the MAC. Indeed, you'll see similar results with ECDHE-RSA-AES256-SHA384 and ECDHE-RSA-AES128-SHA256. Quick work-around is use "ECDHE+AES+SHA" in the cipher string.
NacreousAdding !SHA256 and !SHA384 will do the trick too. If SHA256 and SHA384 are an issue, that makes AES-GCM ciphers unusable until its fixed.
Nitass, are those published BugIDs? I can't find them on askf5.com.
Employee