We received the following email from Fastly today. They have also
included a customer report in .csv format that shows accesses to
snowflake-broker.torproject.net.global.prod.fastly.net and
moat.torproject.org.global.prod.fastly.net with a variety of front
domains including those we currently recommend.
---
Hello The Tor Project,
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.
During last week's meeting we had a conversation on the future of Pluggable
Transports. Our current pt protocol[0] have many limitations, the two main ones
are:
* We have to do hacks to do things like passing arguments, and they come with
many problems[1]
* There are not many SOCKS server implementations and many PTs end up needing
to implement their own (goptlib and proteus have done it)
We have being wondering if making a change from SOCKS to a HTTP based protocol
is the solution we need[2].
For mobile phones we will need PTs to be implemented as libraries, and some
projects like IPtProxy[3] have being created to work around that limitation. It
looks like we will want anyway a future were arti has PT plugins and PTs are
integrated in arti. We might want to extend that idea to implement all the
connect assist workflow there, so clients that use arti don't need to implement
all the logic themselves again and again.
With that future of PTs as plugins. Do we still need a inter-process PT
protocol? and need to make a new version of the pt-spec[0]? Or should we ditch
it and start working on what will that plugin API/ABI look like and how PTs will
be integrated there?
It looks like this conversation doesn't fit well in our irc weekly meetings,
let's have a voice meeting to discuss this. I have created a poll to see what
date next week will work better for all of us:
https://www.systemli.org/poll/#/poll/YRRF8K19Bq/participation?encryptionKey…
[0] https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/pt-spec.txt
[1] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/104
[2] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/130
[3] https://github.com/tladesignz/IPtProxy
--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.