Fastly announces plans to block domain fronting in February 2024

[wkrp]

Some Fastly users got an email saying that Fastly intends to stop allowing domain fronting on 2023-02-27.

Fastly is committed to improving the security of our platform for all our users. One area we are working on is in enforcing the association between a TLS certificate's SAN entries and the hostname in the HTTP request's host header. We will be forbidding domain fronting from happening by restricting it on a shared offset you might depend upon. This change will be applied during February 27th, 2024 . Here are a few things to highlight based on our previous conversations with customers:

Why block Domain Fronting now?

We want to block external malicious actors from utilizing domain fronting for our customers.

Does Domain Fronting cause immediate impact?

Existing domain fronting requests will be allowed. Any new domain fronting requests would be blocked. The exception for the existing domain fronting requests would be in place until the cert used for the request(s) expires or is replaced.

What does this mean?

The earliest cert expiration is shown in the "fastlycertificatedetail" column in the domain fronting report. This means that even if we block domain fronting today, you will have until the cert expires before impacts to domains will be seen. However, new domain fronting requests would be blocked.

What does the report show?

The purpose of the report is to provide visibility to you regarding external requests that are currently defined as domain fronting. These requests may be external requests that have explicit purpose to perform domain fronting and some requests may be requests that you currently use for the operations of your application.

Excluded from this report are services that are service chained or use shielding which will continue to work.

What is Fastly's ask?

Review the report and take action accordingly.

Actions may include but not limited to:

• Do nothing and allow new requests to be blocked after the certificate expires.
• Change Code to provide the necessary SNI and hostname in TLS requests. This needs to be completed before the certificate expires.
• Update Fastly TLS settings to ensure that your service domains have a corresponding Fastly TLS domains.

https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/000328.html

Previously: #67

[mmmray]

Do i get it right that "grandfathered in" domain fronting will stop working on 2023-02-27 and new domain fronting will stop working immediately? What is the significance of the cert expiry then, is it "feb 27 or that, whichever comes first"? Very confusing, I am also currently using domain fronting and have not received such an email, despite being affected.

[cohosh]

Do i get it right that "grandfathered in" domain fronting will stop working on 2023-02-27 and new domain fronting will stop working immediately? What is the significance of the cert expiry then, is it "feb 27 or that, whichever comes first"?

My read of this is that "new" domain fronting requests will stop working on 2023-02-27, where new here means that they do not have a record of any requests with the same Host header and front domain mismatch. The report they sent us contains a record of all such requests, so presumably any requests that have a different combination of Host header and front domain than those listed will be blocked after February 27th.

I can't speak for Fastly on the significance of the front domain certificate expiry, but if I had to guess, I would say that their implementation includes an exception for enforcing the match between the host and TLS certificate SAN entries if the certificate is older than February 27th (or some other date) in order to give their customers time to "correct" their requests. Once the certificates are renewed or updated, the timestamp would be newer than the cutoff date and requests to that front with mismatched hosts would begin to be blocked.

I am not sure how this will affect customers who have not received a report from them.

[ValdikSS]

Sorry to correct you all, but 2024 Feb 27. As of Jan 19, fronted requests still work.

[Wallperr]

Если я правильно понял,то перестанут работать бесплатнные аккаунты для фронтинга.

If I understand correctly, free accounts will stop working for fronting.

[ValdikSS]

Today is the day. Fronting still works as for 06:11 EST.

[mmmray]

@ValdikSS Same here. But I think this still tracks with @cohosh's explanation. Existing pairings of SNI to Host header still work but new deployments of domain fronting may not. It may also be that they are starting with only a few customers and will get to other accounts later. That would explain why only some customers have received emails.

[ValdikSS]

Well, now it stopped working. Fronting no longer works for me on Fastly.

Requested host does not match any Subject Alternative Names (SANs) on TLS certificate [e0b1ad3a7e7c0dccfce6f444920b7f483938b31f652d030b6f2291e01ba34da7] in use with this connection.

Visit https://docs.fastly.com/en/guides/common-400-errors#error-421-misdirected-request for more information.

[mmmray]

it still works here (using the same fronting domain i've been using for months though)

[Wallperr]

Fronting works.... Try changing the address if it doesn't work.

[ValdikSS]

I'm testing on www.techradar.com and www.wikihow.com as a fronted domain. It used to work all these months, today it doesn't.

However cdn.yelp.com, www.cosmopolitan.com, www.esquire.com, www.shazam.com still work.

[cohosh]

It will work for front domains that have been used for domain fronting before and whose certificates have not been renewed since before February 27th, 2024. I just took a look at foursquare.com, which is the front used for the snowflake builtin bridge lines and for Tor Browser's moat settings. Their certificate renewed today at 12:21:56 UTC: https://crt.sh/?id=12239699880

Sure enough, neither Connect Assist or the builtin Snowflake bridges are currently working.