Azure AAD B2C requests to API via Azure Front Door resulting in HTTP 412 (Domain Fronting)
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!
Hello @Jason Lee ,
Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.
I understand that you have an Azure Active Directory B2C tenant with custom policies that send requests to an API via Azure Front Door, but these Azure AAD B2C requests to API via Azure Front Door are resulting in HTTP 412 error.
As you rightly mentioned, it looks like Front Door has enabled the block for ‘domain fronting’ behavior.
Any new Microsoft Standard CDN (classic) or AFD (any SKU) profile created after November 8, 2022 will have the domain fronting block feature enabled by default. And if your Azure Front Door profile was created before November 8, 2022 and you want to enable the Domain Fronting fix for your profile, you can create a support request for same.
Domain fronting is a networking technique that enables a backend domain to utilize the security credentials of a fronting domain. For example, if you have two domains under the same content delivery network (CDN), domain #1 may have certain restrictions placed on it (regional access limitations, etc.) that domain #2 does not. By taking the valid domain #2 and placing it into the SNI header, and then using domain #1 in the HTTP header, it’s possible to circumvent those restrictions. To the outside observer, all subsequent traffic appears to be headed to the fronting domain, with no ability to discern the intended destination for particular user requests within that traffic. It is possible that the fronting domain and the backend domain do not belong to the same owner.
If your application is sending a mismatch between the TLS SNI extension and the host header inside the HTTP session, then that request will be blocked with a 421 response from CDN/AFD.
Not sure why your Front Door started rejecting requests all of a sudden.
But as mentioned in the below Azure Front Door FAQ doc,
When Front Door blocks a request due to a mismatch:
- The client will receive an HTTP "421 Misdirected Request" error code response.
- Azure Front Door will log the block in the diagnostic logs under the "Error Info" property with the value SSLMismatchedSNI.
Could you check the Azure Front Door diagnostic logs and see if you have any additional details logged?
I will also check internally and try to find some more information on this issue.
But if there are no additional details in the log, then our best approach would be to create a support request and engage the AFD backend/PG team for further assistance. 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.
@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.
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