Relation between Cipher-Suite and Key-type of server certificate
I must noticed/learned these days, that specific allowed ciphers are useless if they are not matching with the key-type of the server-certificate from the clientSSL profile. I think it's not unusual that most server-certificate will still be generated with RSA 2k or 4k key-type. And those (older) certificates, which are already renewed a couple of times with the same key have even a higher chance to be a RSA type. But with this for example only the following two ciphers could be selected: ECDHE-RSA-AES128-GCM-SHA256/TLS1.2 ECDHE-RSA-AES256-GCM-SHA384/TLS1.2 If a client for example only supports the following two ciphers: ECDHE-ECDSA-AES128-GCM-SHA256/TLS1.2 ECDHE-ECDSA-AES256-GCM-SHA384/TLS1.2 Neither of these two will be choose, even if they are allowed/provided in the cipher-rule configuration of the BIG-IP. Is this really the case or are there any other dependencies, which are responsible for the „No shared ciphers between SSL peers“ log entry? I'm wondering, because I've never read about that in any of the tons of cipher documents and articles, I've read so far. => So can please someone share some detailed information about this relation? And if this behavior is true, does it makes sense and is it technical possible to create two different clientSSL profiles, one with a RSA-key and the other with a ECDSA-key and assign both to the VIP? Can the BIG-IP handle this and will choose the correct certificate/profile depending on the provided cipher-list from the client? Thank you! Regards Stefan :)Solved67Views0likes2CommentsBlock CBC
Hi there, I'm having a challenge on Blocking entirely the CBC cipher. The ciphers I'm using are: ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305-SHA256 ECDHE-RSA-CHACHA20-POLY1305-SHA256 ECDHE-ECDSA-AES128-SHA256 The problem is that even the above ciphers are selected, the testing shows that the F5 can communicate with CBC. Any further configuration needed here Thank you A36Views0likes1CommentCBC 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 🙂Solved2.1KViews1like13CommentsCipher Suite Ordering
I need to order my ciphers in a very specific way. Using this command 'tmm --clientciphers 'ECDHE+AES-GCM:ECDHE+AES:' I get; ID SUITE BITS PROT METHOD CIPHER MAC KEYX 49200 ECDHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDHE_RSA 49199 ECDHE-RSA-AES128-GCM-SHA256 128 TLS1.2 Native AES-GCM SHA256 ECDHE_RSA 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 Native AES SHA384 ECDHE_RSA 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1 Native AES SHA ECDHE_RSA 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.2 Native AES SHA ECDHE_RSA 49191 ECDHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 ECDHE_RSA 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.1 Native AES SHA ECDHE_RSA 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.2 Native AES SHA ECDHE_RSA What I need, however, is; ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-CBC-SHA ECDHE-RSA-AES128-CBC-SHA AES256-GCM-SHA384 AES128-GCM-SHA256 AES256-SHA256 AES128-SHA256 AES256-SHA AES128-SHA Which means moving line 7 in the original to line 4. How can I specify the EXACT order I want them in? Thanks in advance376Views0likes3CommentsStrong cipher suite
Hi we are testing a url on sslab test and the current setup on our f5 have these ciphers: DEFAULT:!SSLv2:!SSLv3:!TLSv1:!RSA:!ECDHE-RSA-AES256-CBC-SHA:!ECDHE-RSA-AES128-CBC-SHA:!ECDHE-RSA-DES-CBC3-SHA:!EXPORT:!DHE+AES-GCM:!DHE+AES:!DHE+3DES:ECDHE+AES-GCM:ECDHE+AES:RSA+AES-GCM:RSA+AES:ECDHE+3DES:RSA+3DES:-MD5:-SSLv3:-RC4 but when we tested it on sslab test, it says: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ( 0xc028 )ECDH secp384r1 (eq. 7680 bits RSA) FSWEAK 256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ( 0xc027 )ECDH secp384r1 (eq. 7680 bits RSA) FSWEAK128 anyone knows how to address this?382Views0likes2Comments01070312:3: Invalid keyword 'ecdhe-ecdsaaes256- gcm-sha384' in ciphers list for profile
Hi Guys! Does anyone experience the same issue? We are experiencing SSL/TLS Vulnerabilities per our Security Team we need to apply the certain cipher configuration and it includes this string SHA384:ECDHE-ECDSAAES256- GCM-SHA384 however our F5 doesn't accept it. 01070312:3: Invalid keyword 'ecdhe-ecdsaaes256- gcm-sha384' in ciphers list for profile /Common/xxxxxx Thank you!486Views0likes3CommentsCipher string mismatch ??
Hi, I configured SSL cipher string, to support 6 different ciphers: config tmm --clientciphers TLSv1_2+ECDH-RSA-AES256-GCM-SHA384:TLSv1_2+ECDH-RSA-AES256-SHA384:TLSv1_2+ECDH-RSA-AES256-SHA:TLSv1_2+DHE-RSA-AES256-SHA256:TLSv1_2+DHE-RSA-AES256-SHA:TLSv1_2+DHE-RSA-AES256-GCM-SHA384 ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 49202 ECDH-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 ECDH_RSA 1: 49194 ECDH-RSA-AES256-SHA384 256 TLS1.2 Native AES SHA384 ECDH_RSA 2: 49167 ECDH-RSA-AES256-SHA 256 TLS1.2 Native AES SHA ECDH_RSA 3: 107 DHE-RSA-AES256-SHA256 256 TLS1.2 Native AES SHA256 EDH/RSA 4: 57 DHE-RSA-AES256-SHA 256 TLS1.2 Native AES SHA EDH/RSA 5: 159 DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA I used that string in ClientSSL profile, but when I tested my page with SSLlabs, only ciphers 3,4,5 are supported. Any idea where is the problem?? Best regards, Spella723Views0likes5CommentsHow to find which cipher suit is used or not?
For example we have cipher suite as below ECDHE-RSA-AES128-GCM-SHA256 (0xc02f) SHA256 ECDHE-RSA-AES128-CBC-SHA (0xc013) SHA ECDHE-RSA-AES128-SHA256 (0xc027) SHA256 How can we know which cipher suit is used or not used? Can we see how many times that cipher suit is using? I saw F5 keep statistic about ssl exchange key algorithm (ECDHE, DES, etc) but no statistics about specific cipher suit.1.3KViews0likes1CommentStrategy for updating large amount of SSL profiles associated with a single virtual server
I'm looking to shed some of the older ciphers that are a part of the DEFAULT cipher string in our SSL profiles. The problem is, we host quite a few SSL profiles (100+) with a single virtual server. I discovered that I'm unable to update a single profile that's applied to a virtual server that has others with a (then) mismatched security policy. The support article from F5 says that I will have to remove all of the client SSL profiles from the server, update them all, and then re-add them all back. (https://support.f5.com/csp/article/K04316654) Is it possible that something like this could be scripted so that 1) I can reduce the amount of hand-work editing each of these individual profiles and 2) more importantly reduce the maintenance window that I'll inevitably need to schedule as removing the profiles will cause an interruption in my production web traffic. Or any other angles to this that I'm not seeing that might make this a smoother adjustment?458Views0likes1Comment