Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Microsoft Azure announces intention to stop domain fronting #67

Open
wkrp opened this issue Mar 29, 2021 · 5 comments
Open

Microsoft Azure announces intention to stop domain fronting #67

wkrp opened this issue Mar 29, 2021 · 5 comments

Comments

@wkrp
Copy link
Member

wkrp commented Mar 29, 2021

The Microsoft Security blog has a post on 2021-03-26, saying that they plan to disable domain fronting on Azure.

https://www.microsoft.com/security/blog/2021/03/26/securing-our-approach-to-domain-fronting-within-azure/ (archive)

As a company that is committed to delivering technology for good, supporting certain use cases that support free and open communication are an important consideration when weighing the potential impacts of a technique like domain fronting. However, we know that domain fronting is also abused by bad actors and threat actors engaging in illegal activities, and we’ve become aware that in some cases bad actors configure their Azure services to enable this.

When it comes to situations like this, Microsoft—as a security company—leads from a place of providing greater simplicity for our customers when they face increased complexity. Our mission is to give our customers peace of mind and help them adapt quickly to a rapidly shifting threat landscape. Therefore, we’re making a change to our policy to ensure that domain fronting will be stopped and prevented within Azure.

Changes like this one are not made lightly, and we understand that there will be impacts across a number of areas:

  • Our engineering teams are already working to ensure the platform will block anyone from practicing the domain fronting technique on Azure, while also continuing to ensure our products and services provide the highest levels of protection against domain fronting based threats.

I was alerted to this by @cohosh and the Tor anti-censorship-team mailing list.

@wkrp
Copy link
Member Author

wkrp commented Mar 29, 2021

Something similar happened with Google and Amazon in April 2018. Here are some articles for background:

@wkrp
Copy link
Member Author

wkrp commented Mar 29, 2021

A promising alternative to domain fronting is TLS Encrypted Client Hello (ECH, formerly ESNI).

In 2018, I made changes to meek to make it possible to run meek using ESNI in place of domain fronting (archive), taking advantage of the ESNI support in the headless Firefox browser meek can use for TLS camouflage). I haven't tried it lately, and Tor Browser no longer uses (archive) the version of meek that supports a headless Firefox, but back then it worked with Cloudflare's ESNI server support, and in principle should still work with ECH. Firefox 85 now supports ECH (archive), though as far as I am aware ECH is not publicly deployed in servers yet.

I also made a demo of using a browser as an external engine for making HTTP requests separately from the meek code base, using a browser extension in Firefox and Chromium:

You may be interested in this essay anticipating how things will be different when something like ESNI or ECH is more ubiquitous. It predicts that as circumvention technologies become more resistant to direct attack by censors, the next weakest point will be third-party intermediaries such as CDNs and app stores.

@xiaokangwang
Copy link

xiaokangwang commented Jun 30, 2021

The usage of TLS extensions like ECH is still detectable by adversaries. Since browsers and tools are very likely to retry with an unencrypted handshake message, the censorship tools are likely to block ECH as well.

I believe a more viable option for using cloud infrastructure as a censorship resistance tool will be: the usage of shared domain names and disposable domain names.

In AWS, the endpoint for AWS Lambda is something like lambda.us-west-1.amazonaws.com. For censorship tools, the domain name is the same for all customers.

Similarly, the URL for each API Gateway is something like https://zzzzzzzzzz.execute-api.us-west-1.amazonaws.com/. There is no customer id in the URL. The censorship tools will not be able to know which domain name belongs to which customer. Tools like meek can create a new URL for each user session and delete it after usage.

Cloud providers will need to change the URL scheme to make it possible for censorship tools to know the relationship between a domain name and their related customers.

This method could work on cloud providers other than AWS as well.

(This post express the personal opinions of the author, instead of the affiliated V2Ray/V2Fly organization.)

@wkrp
Copy link
Member Author

wkrp commented Jan 28, 2023

In November 2023, some Azure customers got an email informing that domain fronting will be disabled in Azure on 2023-11-08.

Action required: Azure Front Door/Azure CDN blocking domain fronting

Please take action to stop domain fronting on your application before 8 November 2023 You're receiving this email because you currently use Azure Front Door or Azure CDN Standard from Microsoft (classic).

Since 29 April 2022, we've changed the behavior of Azure Front Door and Azure CDN from Microsoft to align with our commitment to stop allowing domain fronting behavior on our platform. With that change, we offered the option to enable blocking domain fronting for existing or newly created Azure Front Door, Azure Front Door (classic) and Azure CDN Standard from Microsoft (classic) resources, through opening a support request. See details in Generally available: Controls to block domain fronting behavior on customer resources | Azure updates | Microsoft Azure.

To continue our commitment, we're making changes in two phases to stop allowing domain fronting behavior on our platform.

  1. Beginning 8 November 2022, all the newly created Azure Front Door, Azure Front Door (classic) or Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. Previously existing Front Door, Front Door (classic) and CDN from Microsoft (classic) resources aren't affected by these changes.
  2. Beginning 8 November 2023, all existing Azure Front Door, Azure Front Door (classic) and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior.

Recommended action Between now and 7 November 2023, if you want to block domain fronting for any existing Azure Front Door or Azure CDN Standard from Microsoft (classic) resources created before 8 November 2022, please open a support request. Provide your subscription and Azure Front Door, Azure Front Door (classic), or Azure CDN Standard from Microsoft (classic) resource information in the support request. Once blocking of domain fronting has been enabled, Azure Front Door, Azure Front Door (classic), and Azure CDN Standard from Microsoft (classic) resources will block any HTTP requests that exhibit this behavior.

If your application uses a different TLS SNI extension during the TLS negotiation from the request Host header, you should prioritize changing this behavior on your application by 7 November 2023 to ensure they match. Otherwise, your application or API may be impacted by this change on 8 November 2023.

If you have any questions, please open a support request and provide your subscription details along with your Front Door or Azure CDN from Microsoft resource information.

If you have any questions, please contact us.

@wkrp
Copy link
Member Author

wkrp commented Nov 9, 2023

In November 2023, some Azure customers got an email informing that domain fronting will be disabled in Azure on 2023-11-08.

The announced date of 2023-11-08 (yesterday) has been pushed back to 2024-01-08 in a new email announcement.

Take action to stop domain fronting on your application before 8 January 2024

You’re receiving this email because you’re currently using Azure Front Door or Azure CDN Standard from Microsoft (classic).

We’ve been making progressive changes to Azure Front Door and Azure CDN from Microsoft to align with our commitment to prevent domain fronting behavior. Starting from 8 January 2024, all existing Azure Front Door and Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. The block implementation will start roll out on 8 January 2024 and will take one week or two weeks for the change to roll out to all regions.

The following is a summary of the changes related to blocking domain fronting behavior on Azure Front Door and Azure CDN Standard from Microsoft (classic) in the past 18 months:

Recommended action

If your application or API uses a different TLS SNI extension than the request Host header, and these two values aren’t added as domains to Azure Front Door in the same subscription, you’ll need to update your application or API by 8 January 2024, to avoid any potential impact from this change.

If you need any further assistance, please submit a support request with your subscription details and your Front Door or Azure CDN from Microsoft resource information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants