Breaking Down the Quantum Challenge: Why Post-Quantum Cryptography Can't Wait
The Quantum Challenge is Now Post-quantum cryptography represents the next steps of our digital security evolution. Sure, quantum systems capable of breaking current encryption may still be an a few years away, but those beginning their transition now will be well-positioned for when the crypto hits the fan. Nation-state adversaries and sophisticated private entities may be collecting data today hoping to decrypt it tomorrow so it's never to early to start solving the problem now. It's an excellent time to get ahead of the curve with quantum-resistant cryptography. What does this mean for your organization? Any sensitive data encrypted today using standard methods (RSA, ECDSA) could potentially become readable to future quantum-powered attackers. F5 Community Evangelist Chase Abbott discusses the real world implications of quantum computing, and how you can prepare and migrate to NIST-approved hybrid PQC standards. The transition to post-quantum cryptography represents a perfect opportunity to modernize enterprise PKI practices. Those of you that begin planning today have ample time to implement these changes thoughtfully and strategically, positioning yourselves as leaders in the next generation of cybersecurity; high fives all around. The Business Impact: Beyond Technical Considerations Regulatory and Compliance Pressure Government regulations across the globe are creating concrete deadlines for migration strategies: NSA CNSA 2.0 mandates quantum-resistant algorithms for classified systems by 2030 NIST has standardized post-quantum cryptography algorithms (FIPS 203, 204, 205) Industry regulations in finance, healthcare, and defense are beginning to incorporate quantum-safety requirements adhering to the update FIPS governance Your Quantum-Ready Roadmap: A Manageable Transition Phase 1: Assessment and Inventory Action items for leadership: Conduct cryptographic inventory across all systems and applications Identify critical data requiring long-term protection Assess vendor and third-party quantum readiness Establish quantum cryptography governance and budget allocation Phase 2: Pilot Implementation Strategic focus areas: Deploy quantum-resistant algorithms in non-critical environments Train IT and security teams on post-quantum cryptography Establish partnerships with quantum-ready technology vendors Begin updating security policies and procedures Phase 3: Production Migration Enterprise-wide deployment: Implement hybrid classical/quantum-resistant systems and software Migrate critical applications and PKI aggregation points to quantum-safe algorithms Update business continuity and disaster recovery plans Achieve full compliance with regulatory requirements as a priority over other systems Key Takeaways for Business Leaders Start planning now: The quantum threat timeline is uncertain, but the need for preparation is immediate Prioritize critical assets: Focus initial efforts on protecting your most sensitive and long-lived data Invest in capabilities: Quantum cryptography expertise will become as essential as any other IT security skill Engage stakeholders: Quantum security requires coordination across IT, compliance, procurement, and business units Monitor developments: Stay informed about quantum computing advances and regulatory updates Mahalo! Further Reading: Post Quantum Cryptography Coalition: PQC Migration Roadmap Post Quantum Cryptography Coalition: International PQC Requirements Post Quantum Cryptography Coalition: Inventory Workbook Essence of Linear Algebra Quantum Computing for the Very Curious Looking Glass Universe: Why I Left Quantum Computing Research US National Quantum Initiative
How to set top priority for TLS 1.2 protocol over TLS 1.0 for client ciphers in BIG-IP v11.6.x
Problem: The F5 (version 11.6.x) establishes a TLS 1.0 connection for a client browser even if protocols TLS 1.2 and TLS 1.1 are part of the supported ciphers on both sides (client browser and F5 client-side). How can I force the F5 to use the highest protocol available? How can I reorder the ciphers/protocols to put TLS 1.2 at the top of the protocol negotiation mechanism? How does the F5 perform the TLS protocol negotiation? The cipher string: DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:!SSLv3:!DTLSv1 tmm --clientciphers 'DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:!SSLv3:!DTLSv1' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 51 DHE-RSA-AES128-SHA 128 TLS1 Native AES SHA EDH/RSA 1: 51 DHE-RSA-AES128-SHA 128 TLS1.1 Native AES SHA EDH/RSA 2: 51 DHE-RSA-AES128-SHA 128 TLS1.2 Native AES SHA EDH/RSA 3: 57 DHE-RSA-AES256-SHA 256 TLS1 Native AES SHA EDH/RSA 4: 57 DHE-RSA-AES256-SHA 256 TLS1.1 Native AES SHA EDH/RSA 5: 57 DHE-RSA-AES256-SHA 256 TLS1.2 Native AES SHA EDH/RSA The client browser is Safari 11.1 (the latest version at time of writing).
SSLlabs strong ciphers only with tls 1.2 running
Hopefully this saves someone else a few hours of searching trying and reconfiguring the F5 Cipher Suites to get an "A" and only use strong ciphers with only tls 1.2 with ssllabs.com. F5's implementation of cipher suites and chosing which to use could be greatly improved for ease of use. I was able to achieve an "A" on SSLlabs.com with Strong Ciphers Only by doing the following: Note- with having only these 2 ciphers selected older versions of Internet Explorer 11 on Win 7, Win8.1, Win Phone 8.1, and Safari 6, 7, 8 cause handshake_failures. First create the rule: Under Local Traffic > Ciphers: Rules > Create Under Rule Creation> Give it a RULENAME To the right of Cipher Suites: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384 Second the group: Under Local Traffic > Ciphers: Groups > then Create Give the group a GROUPNAME, then on the right under Available Rules select the RULENAME you created and click << box and then click finish. Third - assign the group to an ssl profile: Under Local Traffic > Profiles> SSL> Client> Select your exisitng SSL Client, Ie EXAMPLE. Once within the profile click the drop down to the right of Configuration: to show Advanced. Make sure your Ciphers has a check in the box on the right. Click the drop down next to ciphers and select the GROUPNAME you created and then click Update at the bottom. ---- We were also able to achieve an "A" but with weak cipher suites showing on SSLlabs.com . We were using for our cipher suites: !NONE:!EXPORT:!DHE+AES-GCM:!DHE+AES:ECDHE+AES-GCM:ECDHE+AES:!RSA+AES-GCM:!RSA+AES:-MD5:-SSLv3:-RC4:!3DES:!TLSv1:!TLSv1_1:TLSv1_3
Ciphers list '' for profile /Common/SSL_Test denies all clients
Hi folks, Need help in configuring custom ciphers to attach to the SSL profile. I've configured the Cipher rule with following ciphers and then created Cipher Group. ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA256 when I am trying to add the Cipher group name to SSL profile then it gives the above error.
SSLv3 Cipher support
I have a old SSL client that use the following ciphers: Secure Sockets Layer SSLv3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: SSL 3.0 (0x0300) Length: 49 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 45 Version: SSL 3.0 (0x0300) Random Session ID Length: 0 Cipher Suites Length: 6 Cipher Suites (3 suites) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) F5 error: Jul 9 15:09:19 MainFrontEnd warning tmm[11852]: 01260009:4: Connection error: ssl_hs_rxhello:7527: unsupported version (40) Packet trace error: Alert Message Level: Fatal (2) Description: Handshake Failure (40) Does F5 still support these Ciphers? Using "ALL" or insecure-compatibility ciphers does not do the trick: !SSLv2:ALL:!DH:!ADH:!EDH:@SPEED Ciphers on F5: tmsh run util clientssl-ciphers SSLv3 ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 57 DHE-RSA-AES256-SHA 256 SSL3 Native AES SHA EDH/RSA 1: 56 DHE-DSS-AES256-SHA 256 SSL3 Native AES SHA DHE/DSS 2: 58 ADH-AES256-SHA 256 SSL3 Native AES SHA ADH 3: 53 AES256-SHA 256 SSL3 Native AES SHA RSA 4: 22 DHE-RSA-DES-CBC3-SHA 168 SSL3 Native DES SHA EDH/RSA 5: 27 ADH-DES-CBC3-SHA 168 SSL3 Native DES SHA ADH 6: 10 DES-CBC3-SHA 168 SSL3 Native DES SHA RSA 7: 51 DHE-RSA-AES128-SHA 128 SSL3 Native AES SHA EDH/RSA 8: 50 DHE-DSS-AES128-SHA 128 SSL3 Native AES SHA DHE/DSS 9: 52 ADH-AES128-SHA 128 SSL3 Native AES SHA ADH 10: 47 AES128-SHA 128 SSL3 Native AES SHA RSA 11: 24 ADH-RC4-MD5 128 SSL3 Native RC4 MD5 ADH 12: 21 DHE-RSA-DES-CBC-SHA 64 SSL3 Native DES SHA EDH/RSA 13: 5 RC4-SHA 128 SSL3 Native RC4 SHA RSA 14: 4 RC4-MD5 128 SSL3 Native RC4 MD5 RSA 15: 26 ADH-DES-CBC-SHA 64 SSL3 Native DES SHA ADH 16: 9 DES-CBC-SHA 64 SSL3 Native DES SHA RSA 17: 98 EXP1024-DES-CBC-SHA 56 SSL3 Native DES SHA RSA 18: 100 EXP1024-RC4-SHA 56 SSL3 Native RC4 SHA RSA 19: 8 EXP-DES-CBC-SHA 40 SSL3 Native DES SHA RSA 20: 3 EXP-RC4-MD5 40 SSL3 Native RC4 MD5 RSA list /sys httpd ssl-ciphersuite sys httpd { ssl-ciphersuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA } list /sys httpd ssl-protocol sys httpd { ssl-protocol "all -SSLv2 -SSLv3" }
Recommended Exchange 2016 ciphers settings?
After setting up our Exchange 2016 environment behind the F5 using the iApp, the SSL scan through Qualys SSL Labs gave us a big red F. Started a case with F5, to get the recommended cipher settings for Exchange 2016, but Support is telling me they don't know, and can only recommend different general settings to try to get rid of insecure ciphers. So first thing I'm recommended to try is: DEFAULT:!RSA I'm really surprised over this poor support, and hoping someone else out there has an Exchange 2016 server tightened down, without tighten it too much, to still be able to use Outlook Anywhere/OWA/ActiveSync etc. If you would be willing to share your ciphers settings, it would be much appreciated!
ECDSA Cipher help on LTM
Hello f5 experts, I am trying to add below cipher to a SSL profile but the customer is not able to see it on SSLlabs, I checked few solutions and tried adding it but the ECDSA part is missing. Can someone please help me enable it? f5 version we use is - 11.5.5 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_ Thanks, R
