Forum Discussion
AltostratusForce Client-SSL Profile to X25519, Instead of Post-Quantum Cryptography
There is a TLS implementation that was working perfectly before, even though, there is SSL ClientHello extension addition, by a middle-box device.
With Clienthello packets of 540bytes, this worked perfectly. An example is the "Extension Unknown Type 17516" added there.
Recent tests show the extension addition is no longer working. The only significant change is that CLIENTSSL HELLO packets are now fragmented on TLS 1.3 with the Post-Quantum Cryptography implementation on clients (browsers), with CLIENTSSL HELLO now regularly abover 1500 bytes causing fragmentation.
How is it possible if F5 is Client-side server to force all clients to use X25519 ciphers instead of X25519Kyber512Draft00 and X25519Kyber768Draft00 to ensure that full flow is not broken. is there any changes on CLIENTSSL Profile to implement this. Traffic Flow is Mobile browser--Mobile Packet gateway (header enrichment)-- F5 (Server)
2 Replies
- Jeff_Granieri
Employee
Hi Kazeem_Yusuf ,
Enabling PQC ciphers can increase the size of the Client_Hello, reference https://datatracker.ietf.org/doc/draft-ietf-uta-pqc-app/ See Section 4.1
" Challenges: - The size of the hybrid key exchange algorithm key share may exceed the Maximum Transmission Unit (MTU), potentially causing the ClientHello message to be fragmented across multiple packets. In TLS, this results in multiple TCP segments. In DTLS, handshake messages are explicitly fragmented at the record layer as specified in [RFC9147], with each fragment sent in its own UDP datagram. In both cases, larger ClientHello messages increase latency and the risk of handshake delay, especially in lossy networks."
Have you tried any custom cipher groups?
Here is something to test out in a lower / non-prod environment:This locks down DH groups to only X25519, it will disable the Kyber Drafts. *** Older SSL Clients might have issues with these settings ***
tmsh create ltm cipher rule rule_X25519_only cipher DEFAULT dh-groups X25519 signature-algorithms DEFAULT
tmsh create ltm cipher group group_X25519_only allow add { rule_X25519_only }
tmsh modify ltm profile client-ssl <your_client_ssl_profile_name> ciphers group_X25519_only
If you need to add support for secp256r1(P-256) for older SSL clients then add this string to the DH groups "X25519:secp256r1:secp384r1" 1st tmsh line above.
Give that a go hopefully it helps
Kazeem_YusufHello Jeff_Granieri ,
Thank you for your concise reply. I implemented the instruction as directed. However, i noticed the client sent in X25519MLKEM,alongside X25519, that the F5 is supposed to only accept. That means, irrespective of whatever is done on F5, as long as the client browsers sends both key shares together, the F5 will accept it. Is there a way to force the Client to only send X25519, and probably force a HelloRetryRequest or something if it sends both. The problem is that with large ClientHello's, middleware boxes (that do DPI) are unable to cope with the sizes and then have to fragment traffic.
