Forum Discussion

THE_BLUE's avatar
Icon for Cirrostratus rankCirrostratus
Mar 26, 2024


does F5 has mitigation for CVE-2024-21410 ? 

based on microsoft document we must disble ssl offloding with load balancer , as below 

SSL Offloading scenarios

Extended Protection isn't supported in environments that use SSL Offloading. SSL termination during SSL Offloading causes Extended Protection to fail. To enable Extended Protection in your Exchange environment, you must not be using SSL offloading with your Load Balancers.


so does this mean disable https between WAF and Server (pool) and only https will be exist from Client to WAF 

10 Replies

  • Hi THE_BLUE,

    to my knowledge F5 does not provide an Attack Signature or a Threat Campaign that protects from CVE-2024-21410.

    Extended Protection is supported in environments that use SSL Bridging under certain conditions. That should solve your issue.
    IMHO the days of SSL offloading are anyhow over, also internal networks cannot be considered as secure any longer. Therefore, go for SSL Bridging.


    • THE_BLUE's avatar
      Icon for Cirrostratus rankCirrostratus

      Thank you for your clarification. 

      How to enable ssl bridging ? what i should configure in WAF ? , if i enabled https (port 443) from client to WAF with client ssl  and enable http (port 80) from WAF to server (pool) and no server ssl profile. Does this achieve ssl bridging ? 

      • Paulius's avatar
        Icon for MVP rankMVP

        THE_BLUE SSL bridging can be configured by using both the client and server SSL profile. By the end of this configuration the F5 will decrypt traffic using the SSL server profile and then re-encrypt using the SSL client profile.

  • F5 does not support Extended Protection in SSL Bridging Mode. There is an RFE to support this, but it is rather unlikely that it is implemted for BIGIP Classic.


    (Bug alias 758880) [RFE] [NTLM V2 SSO] Support MS IIS option "Extended protection" with value "required" during authentication

    • Daniel_Wolf's avatar
      Icon for MVP rankMVP

      Good to know, Juergen. Looking at the linked Microsoft article it says:
      "Extended Protection is supported in environments that use SSL Bridging under certain conditions. To enable Extended Protection in your Exchange environment using SSL Bridging, you must use the same SSL certificate on Exchange and your Load Balancers. Using different certificates cause Extended Protection Channel Binding Token check to fail and as a result, prevent clients from connecting to the Exchange server."

      That seems feasible, to have the same cert on both ends. That should at least do for satisfying the requirements for the Channel Binding Token to work.

      Do you have any insights why it is not supported? Cannot find the RFE here:
      Neither by ID 758880 nor by searching for the term "extended protection".

      Thx in advance.

      • Juergen_Mang's avatar
        Icon for MVP rankMVP

        I have tried using the same certificate on both ends and it has not worked. I opened a ticket and the support gave me the mentioned bug id and RFE. It seems these are only F5 internally accessible.

        I had unfortunately no time to debug into this issue further. My customer decided to move forward to modern authentication, disabling NTLM completely and do not invest time and money in legacy authentication mechanisms.

        Unfortunately I have no access to Exchange LAB environment. Digging into this issue deeper would  be very interesting!



        This is interesting:

        With enough time it should be feasible with an iRule.

  • During a brainstorming we came up with a simple solution for protecting against NTLM relay attacks, when using SSO with APM, you simply either block or remove the authorization header on the clientside. All NTLM should only be present between APM and Exchange.

    This will give you inside into who is compromised as you can log when you see any clientside NTLM headers. It will also stop any NTLM negotiation attempts from the client browser as that can be considered unwanted information disclosure. 

    If you are not deploying APM SSO you could make a semi proteted solution by picking up the first NTLM hash you see from the client and store it in a table. If you encounter a different hash later in the session you know it is bad and can either block it or start alarming. It is not bulletproof, but it is better than nothing.

    The word on the street is that EPA is expected to be supported in NEXT, late this year.

  • Since there are at least 3 threads for this... 

    If you are only using OWA - or ActiveSync - You can use form-based or basic-auth SSO with EAP and this will work. 


      • LiefZimmerman's avatar
        Icon for Admin rankAdmin

        Daniel_Wolf I can do some moderation/management to the other posts and close further comments > point them to the right/best post.
        To keep this thread clean - I'll send a group DM to you and P_Kueppers requesting the URLs for the other posts so I can try.