Azure AAD B2C requests to API via Azure Front Door resulting in HTTP 412 (Domain Fronting)

Hi,
We have an Azure Active Directory B2C tenant where we have custom policies that send requests to an API. Requests to this API go through Azure Front Door. Our APIs are hosted in Azure Container Apps. We have had this integration working perfectly fine for months and we haven't really changed our Front Door configuration in a couple of months. All of a sudden today, Front Door in one of our environments started rejecting requests from Front Door with an HTTP 412 error.
After some research, we discovered Front Door started rolling out a security feature to prevent "Domain Fronting" a year ago. Documentation states we send a request to MS support to disable protection from Domain Fronting which we plan to do before we experience more problems. I'm reluctant to disable a security feature, especially when we do not know the root cause. Our B2C custom policies only ever send API requests to a single domain since all our APIs are behind Front Door.
Does anyone have any idea why this problem would have happened all of a sudden? Does anyone know how to avoid this problem? It is impossible for us to diagnose this problem as the network traffic is between AAD B2C and Front Door, so we can't inspect network traffic to see the SNI and HTTP host header of the requests.
Looking at the Front Door logs (AzureDiagnostics table) the host name (hostName_s) is exactly what we expect. As we have no visibility into traffic between AAD B2C and Front Door, we cannot see the SNI to confirm there is indeed a mismatch. Given the logs say the HTTP host name is correct, I suspect B2C is establishing an SSL connection to the wrong SNI but there's no way for us to confirm this.
Thanks in advance for any assistance!
@Jason Lee , I checked with the Azure Front Door Product group team, and they mentioned that domain fronting is only enabled by default on newly created AFD resources post Nov 8, 2022. For all existing resources, domain fronting is enabled only if customer requests for it. If not requested yet, then it will be implemented from Nov 8, 2023. Since the behavior started all of a sudden, it is better to create a support request and engage the backend team to have a look into the root cause.
So, if you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.
Regards,
Gita
Ok thanks @GitaraniSharma-MSFT . We do have a support plan and have raised a ticket. We're still suspicious that there was a patch fix or change to Front Door that caused this problem since the problem suddenly disappeared on Saturday without us changing anything. The error still appears in our logs but FD no longer returns that error. Anyway, I can report back on this thread the findings from the ticket.
@Jason Lee , thank you for the update. I found the support request which you have raised and see the support engineer has pulled the backend logs for the SNI mismatch. I will also track the support case from my end and add the final summary to this thread once the issue is resolved.
Sign in to comment