Forum Discussion

Kazeem_Yusuf's avatar
Kazeem_Yusuf
Icon for Altostratus rankAltostratus
Aug 07, 2026

Force 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)

Client Hello
clientssl
F5
Post Quantum Cryptography
ssl
tls1.3

1 Reply

  • Jeff_Granieri's avatar
    Jeff_Granieri
    Icon for Employee rankEmployee
    Aug 17, 2026

    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

     

     

     

     

Related Content