Category: Services

  • The UK Online Safety Act & age verification

    The UK Online Safety Act & age verification

    The Matrix.org Foundation posted yesterday that “public Matrix servers will also have to uphold age verification laws, as misguided as they might be.” This is true for them. They’re based in the UK and subject to the Online Safety Act. But it is not true as a general statement, and it’s not true for us.

    Unredacted is a 501(c)(3) non-profit incorporated in Delaware that builds Internet infrastructure and services to help people access the open Internet and protect their right to privacy. We run Tor relays and bridges, operate FreeSocks to provide free VPNs to people in censored countries, run proxies for Signal and Telegram, and host free and open federated chat services, including our Matrix homeserver and XMPP.is. Our infrastructure is in the United States. We are subject to US law. The UK Online Safety Act does not apply to us, and no US law requires us to comply with it.

    The SPEECH Act (28 U.S.C. §§ 4101-4105) specifically prohibits US courts from enforcing foreign content-based judgments unless the foreign law provides at least as much free speech protection as the First Amendment. The Online Safety Act doesn’t come close. It mandates removal of constitutionally protected speech, imposes proactive content monitoring, and criminalizes content that is legal here. The SPEECH Act also incorporates Section 230, which shields platforms from liability for user-generated content. Every state has adopted laws that exclude foreign regulatory fines from enforcement. The US-UK Mutual Legal Assistance Treaty covers criminal matters only and explicitly excludes regulatory enforcement. There is no treaty or agreement that requires a US entity to comply with UK administrative regulations.

    The US government has taken this position too. FTC Chairman Ferguson warned tech companies in August 2025 that censoring Americans at the request of a foreign power could violate US law, naming the Online Safety Act specifically. 4chan and Kiwi Farms filed a federal lawsuit challenging Ofcom’s enforcement on First Amendment and SPEECH Act grounds.

    What about US age verification laws? Also not applicable.

    There is no federal age verification law for general Internet services. COPPA, the only relevant federal law, applies to commercial websites and online services. The FTC explicitly states it does not apply to nonprofit entities exempt from Section 5 of the FTC Act. We are a 501(c)(3). COPPA does not apply to us.

    At the state level, 25 states have passed age verification laws, but they target commercial pornography sites (where a third or more of the content is pornographic) and large commercial social media platforms (often with revenue thresholds of $100 million+). We are a non-profit running federated chat servers. None of these laws were written for us and none of them apply.

    The Supreme Court upheld age verification for adult content sites in Free Speech Coalition v. Paxton last June, but that ruling was narrow and specific to commercial pornographic websites. Courts have continued to block most social media age verification laws on First Amendment grounds.

    We prohibit illegal content and material that causes real harm across all of our services, Matrix and XMPP.is alike: no CSAM of any kind, no threats of violence, no content that harms humans or animals. Over the years we’ve put real work into responding to abuse reports and clamping down on misuse of our platforms. We do this because those are our values, not because a foreign regulator demands it and not because we’re legally required to age-gate our chat servers.

    We will not be implementing age verification. We will not be collecting government IDs from our users. These things are antithetical to why Unredacted exists. Our entire purpose is to help people communicate freely and privately, whether that’s someone in a censored country connecting to Signal through our proxies or someone joining a Matrix room on our homeserver. Building a surveillance apparatus on top of that would undermine everything we do.

    Matrix.org is right about one thing: in Matrix you have the opportunity to run your own servers as you wish. We encourage everyone to take them up on that. If you’re coming from Discord, don’t register on matrix.org. It’s UK-based and subject to the Online Safety Act. Register on a server that isn’t.

  • New rules for our chat services, and our efforts to moderate them

    Over the many years that we’ve operated our free and public federated chat services, XMPP.is and the Unredacted Matrix server, we’ve quickly and effectively responded to abuse reports and made great strides in clamping down on the blatant abuse of our services. This hasn’t come without a cost, as we’ve spent countless hours banning thousands of accounts and rooms involved in all sorts of nefarious behavior.

    Our moderation efforts

    While we attempt to moderate effectively, XMPP has been and is notoriously hard to develop moderation solutions for. For example, we have to perform all actions on the command-line and develop scripts that parse through the flat-file storage of our server (it doesn’t use a DB). Generally, XMPP users are much more well-behaved from our observations and lack of abuse reports. We haven’t had a huge problem with abusive users besides the occasional spammer. It’s also hard to keep tabs on statistics for XMPP moderation, so we don’t have many unfortunately.

    Matrix is a different story, with a proper database and a robust admin API – we are enabled to do much more. We’re able to look back at our stats, and see what we’ve done so far.

    We’ve compiled some information on our efforts below.

    • We have blocked over 600 rooms from external Matrix servers involved in the distribution of harmful content based on room names, descriptions and other observed patterns.
    • Locked nearly 500 user accounts which signed up to our Matrix server and engaged in nefarious behavior.
    • Installed the Draupnir moderation bot, which will enable us to properly moderate our rooms and protect against various spam attacks.
    • Began the exploration of new moderation solutions which allow us to automate parts of our work.

    New rules

    Although Unredacted advocates for free speech, objectively harmful or even dubiously harmful content that harms humans or animals is not welcome. It potentially jeopardizes the good natured people using our servers as a haven from the dragnet surveillance from governments and that which is employed by many of the corporate world’s unencrypted and insecure chat services.

    We spent a very long time thinking about what is fair, and attempting to not be too rigid at the same time. A part of this process was asking our community for feedback as well. We felt that we’ve come up with the right set of rules, and it’s time to implement them. Our goal here is to create communities that are as safe as possible, and without having to moderate each user and room closely. As such, users and rooms created on our chat services must comply with the following rules.

    Chat Service Rules

    • Illegal or objectively harmful content is not allowed.
      • No CSAM (including real/fictional/illustrations/AI/3D), threats of violence, or content that harms humans or animals.
    • Violence, gore, or disturbing imagery is not allowed.
      • No media, discussions or rooms that glorify violence, gore, abuse, or any extreme content that harms humans or animals.
      • No promoting, glorifying, encouraging, or normalizing behaviors, ideologies, or practices that are harmful, abusive, or illegal to humans or animals.
    • Don’t be a jerk in official Unredacted rooms and discussions.
      • This means no excessive trolling or lack of general civility.
    • NSFW themes are not allowed in Official Rooms.
      • No adult content which includes no clearly NSFW media, discussions, or profile pictures in official Unredacted rooms.
    • NSFW rooms have rules.
      • NSFW rooms on Unredacted server must comply to these rules. These rooms must:
        • Be and remain unpublished from the server’s room directory.
        • Room Owners are required to join the “Unredacted Room Owners” room. (Request an invite from a server admin or mod).
        • Moderate their rooms and ensure a zero tolerance rule for illegal content.
        • Report illegal content in the “Unredacted Room Owners” room or contact a server admin directly.

    Illegal acts and content will lead to an instant ban. Otherwise, we will issue you a warning if you are breaking any of the rules. If you continue to break the rules you will be banned.

    Our thought process

    As there will be some that disagree with our new rules and decision to implement them, we want to explain ourselves and our thought process going into this. We don’t intend to force a version of religious morality. We intend to be fair and just in our decisions, and want to promote peace.

    Part of our mission is to “operate with transparency, morality and empathy with the purpose of benefiting all living beings.” There is a lot of content on the Internet that is not in line with those values, and frankly; we want to keep it off our services (as we have always done in a legal context). Content which harms humans or animals is simply objectively abhorrent. It doesn’t promote goodness or civility. It actively subverts all of what we stand for.

    What’s next?

    As of the posting of this blog, the rules will have gone into effect. Over time, we will slowly reach out to users and room owners which violate these new rules (which are not illegal). Depending on the severity of the violations we will generally give existing room owners a grace period before removing their rooms. Any new rooms which violate these rules will be removed at our discretion.

    If you have any questions, please contact us.

  • FreeSocks is now open source

    Censorship on the Internet is getting worse, not better. The free flow of information is key to learning and making change. Because of this, we started FreeSocks, a service that provides free, open & uncensored Outline (Shadowsocks) proxies to people in countries experiencing a high level of Internet censorship late last year (2023).

    Since then, the service has seen a considerable amount of growth. Over 1,000 access keys have been issued to people all around the world wanting to hide their Internet traffic from oppressive governments, and access the open Internet without restriction. Seeing the impact that the service has made is inspiring, and it’s why we’ve been working towards something quite special. Today, we are open sourcing the code that makes FreeSocks work, the FreeSocks Control Plane (FCP), which runs entirely on the serverless Cloudflare Workers platform for free. This allows anyone to launch their own FreeSocks-like service.

    GitHub Repository: github.com/unredacted/freesocks-control-plane

    Understanding the FreeSocks flow

    A diagram showing how FreeSocks works

    Understanding the FreeSocks flow is key to understanding how FreeSocks really works. It’s designed with security in mind, while also being simple enough for any decently technical person to understand.

    Breaking down the flow:

    1. A user visits an HTTP endpoint such as freesocks.org/get on their web browser. The request is terminated in an edge network datacenter close to them.
    2. The user solves a captcha/challenge, and submits their request.
    3. The FCP calculates the latency between the edge network datacenter the user reached, and the available Outline servers by sending HTTP requests over QUIC tunnels to their API endpoints. The available endpoints are stored in and retrieved from a Workers KV namespace.
    4. The Outline server with the best latency and lowest access key count is chosen by the FCP.
    5. The FCP initiates another request to the Outline server’s API to create a new access key, which is returned to the user with a definable expiry date if they don’t use the access key at all.
    6. The user enters the access key in their Outline (or Shadowsocks) application and connects to the server, allowing them to access the open Internet. As long as they continue to use the access key, it won’t expire. If they stop using it, it will be deleted in definable number of days.

    FCP architectural design choices

    By now you know that the FCP is used for access key retrieval by users, and allows administrators to delete unused access keys from the Outline VPN servers they manage. The code behind it is written in JavaScript. The FCP is designed to be fast, flexible and expandable for the future.

    Operating the FreeSocks Control Plane (FCP) on top of a serverless platform was a core design choice for many reasons.

    • It allows others to run the FCP for free (as is the case with Cloudflare Workers).
    • It’s easy to stand up on multiple domains for optimal censor evasion. Let them play whack a mole.
    • It’s easier to manage with tools like Cloudflare Wrangler.
    • It’s more difficult for censors to block serverless edge networks, because they control a large portion of the Internet.
    • Serverless edge networks are beneficial in determining latency between edge and Outline servers to provide the lowest latency server to users without exposing servers to users. In that way, it’s hard for a censor to discover all available servers from their interaction with the FCP.

    While many may not trust large cloud providers to process potentially sensitive information, there’s no doubt that they make it harder for censors to block. FreeSocks is intended to circumvent censorship. At the same time, it makes the FCP very fast and efficient since requests are terminated all over the world in datacenters close to users. We believe the potential privacy tradeoff is worth it.

    While we have to place our trust in cloud infrastructure providers here, we can say with certainty that the FCP code itself does not trigger anything to store personally identifiable information (PII). This makes FreeSocks a fairly privacy friendly service to use.

    How can I run my own FreeSocks?

    Since the FCP is now open source, anyone can run their own FreeSocks-like platform to distribute access keys to people. As time goes on, we’ll write more documentation on how this can be done. For those that are tech-savvy enough, you might figure it out without our help. If you do, please let us know – we’re very interested in hearing your feedback. Contributions to the codebase are welcome too!

    Where does FreeSocks go from here?

    FreeSocks will continue to be developed and expanded based on demand. We’ll continue to gather user feedback, and implement features in the FCP so that we can fight censorship.

    However, we need your help! If you enjoy what we do, please consider making a donation. Unredacted is a non-profit organization that provides free and open services that help people evade censorship and protect their right to privacy.

  • How we accidentally broke our Tor exit relays

    Making technology work how you expect it to, and keep it working that way can be difficult at times. Changes in configuration or software updates can put services into a broken or half-broken state, and we had the latter happen to us.

    In the spirit of transparency, we are writing about the painful discovery that many of our Tor exit relays (at least 1/3) have been broken for (at the very least) weeks, and possibly months without our knowing.

    I’d like to thank the team at Tor Project for letting us know about the issue, and how to reproduce it, which ultimately led to it being discovered and fixed.

    Root cause

    Credit: https://itsfoss.community/t/its-always-dns-lol/10820

    Based on the image, you might suspect what the issue was.

    It was DNS. Specifically, it was Tailscale’s MagicDNS feature. DNS queries were not getting resolved for some reason that is unknown to us. This means that anyone who ended up connecting to our Tor exit relays failed to connect to nearly every domain/subdomain by failing to resolve hostnames. Connecting to IPs worked just fine.

    Before we go on blaming Tailscale, I want to state that we don’t know why MagicDNS failed in the way we observed, we just know that it did. Ultimately, disabling MagicDNS on our exit relays resolved the issue entirely. When we enabled it, and tested again, it failed. As a result, we’ve left it off.

    Technical analysis

    We knew the symptom was that DNS resolution seemed to fail, which was noted by the nice people at Tor.

    We started by attempting to reproduce the issue ourselves. This required pinning our Tor instance/daemon on our local computer to a specific exit relay’s fingerprint that was exhibiting this strange behavior. For example, by modifying our Tor daemon’s torrc file and adding the below line to it, we could force our local Tor daemon to exit all traffic on that relay.

    ExitNodes F34EE673122518873E717C128E35A389B72C7837

    This fingerprint corresponds to our UnredactedSnowden relay.

    We then pointed one of our browsers to use the local SOCKS proxy the Tor daemon listens on (127.0.0.1 port 9050) to send traffic through Tor.

    When attempting to connect to any website, it failed, but the reason was unclear and did not appear to display an error related to a DNS resolution issue.

    As DNS was still the suspect here, the easiest thing to do was to SSH into that exit relay and run a tcpdump to capture all inbound and outbound packets that used TCP or UDP port 53, such as the one below.

    tcpdump -i any -n port 53

    Once we did that, we discovered that nearly all DNS queries originated from Tor seemingly went out to the 100.100.100.100 MagicDNS IP, but nothing was returned on most queries. We knew at this moment, that it was indeed a DNS resolution problem.

    An anonymized example of what we saw:

    17:11:52.164204 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 40707+ A? domain.com. (45)
17:11:52.172049 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 33552+ A? domain.com. (33)
17:11:52.203409 tailscale0 In  IP 100.100.100.100.53 > 100.69.x.x.22065: 47343 NXDomain 0/1/0 (119)
17:11:52.321235 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 45366+ A? domain.com. (28)
17:11:52.321271 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 16617+ A? domain.com. (35)
17:11:52.321303 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 39612+ A? domain.com. (29)
17:11:52.352491 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 63111+ A? domain.com. (34)
17:11:52.383332 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 15513+ A? domain.com. (35)
17:11:52.501714 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 16308+ A? domain.com. (29)
17:11:52.532238 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 7697+ A? domain.com. (40)
17:11:52.540674 tailscale0 In  IP 100.100.100.100.53 > 100.69.x.x.22065: 22472 0/1/0 (89)
17:11:52.544683 tailscale0 Out IP 100.69.x.x.22065 > 100.100.100.100.53: 8052+ A? domain.com. (47)

    We tried several things;

    • Switching the MagicDNS nameservers to other ones & restarting Tor.
    • Rebooting the exit relay we were testing with to see if it was a strange Tailscale daemon/interface/routing issue.
    • Using dig via CLI on the test relay which queried the MagicDNS IP (100.100.100.100) which worked without issue.

    We were at a loss, and couldn’t figure out what was happening. We then decided to disable MagicDNS on the test relay to see what would happen. It worked, DNS queries started flowing and getting resolved responses via the same nameservers directly.

    We subsequently disabled MagicDNS on the rest of the exit relays with an adhoc Ansible shell command.

    Our conclusion

    The problem appeared to be with the abstraction that MagicDNS does, and queries originating from Tor did not appear to work 99%+ of the time when the feature was enabled. However, queries from dig via CLI appeared to always work. We suspect that MagicDNS fails in some sort of way when too many queries are directed at its 100.100.100.100 IP which is seemingly routed out the tailscale0 interface (& subsequently onto the physical interface). However, this doesn’t make complete sense, as we would expect queries from dig to fail as well.

    We may never know what happened exactly, and we don’t want to leave it in a broken state long enough to figure it out. At this point, it’s safe to say that we are leaving MagicDNS disabled on our Tor exit relays for the foreseeable future.

    Shortly after resolving the issue, our Tor exit relay traffic rate shot up beyond previously normal levels and hit our full capacity (as of writing this).

    In the near future, we will explore running our own local DNS resolver on each exit relay, which we’ve done in the past – but had to move away from due to an overload of bogus queries originated from Tor which also resulted in DNS resolution failures. DNS over HTTPS (DoH) or DNS over TLS (DoT) are also great options we may explore further.

    We hope you found this interesting and insightful. If you enjoy what we do, please consider making a donation. Unredacted is a non-profit organization that provides free and open services that help people evade censorship and protect their right to privacy.

  • New Tor bridge types for Operation Envoy

    In July of last year (2023) we launched Operation Envoy, our effort to deliver packets to and from the Tor network which helps defeat Internet censorship. This is achieved by Unredacted operating Tor bridges, also known as Pluggable Transports. Tor bridges obfuscate (bridge) the connection a user makes when connecting to Tor so that it looks like any normal connection and disguises the fact that they are connecting to the Tor network. Each Pluggable Transport has its own unique way of obfuscating the connection, such as WebTunnel which mimics HTTPS traffic, one of the most common types of traffic on the Internet.

    What a connection to the Tor network looks like with a bridge in the path
    Credit: robertheaton.com/2019/04/06/how-does-tor-work/

    Historically, and for a long time we’ve focused our efforts on deploying dedicated snowflake proxies around the world in strategic locations close to Internet users that face a high level of Internet censorship in their countries. Today, we’ve added a WebTunnel and meek bridge into the mix. Adding more Tor bridge types means that users have more ways to connect to the Tor network in the event that one protocol / obfuscation technique gets blocked.

    Our meek bridge

    How meek works, click the image to learn more

    To deploy our meek bridge, we worked with the team at Tor after volunteering to run a new bridge. Due to how meek works with Tor, there is some setup on their end as well because they use a technique called domain fronting. This is a technique to disguise a connection and route it through popular, and more painful to block CDN networks like Microsoft Azure. Meek bridges remain a crucial method to connect to the Tor network in several countries.

    To see our new meek bridge statistics, you can click here.

    Our WebTunnel bridge

    How HTTPT works, the proxy behind WebTunnel technology

    As described earlier in the post, WebTunnel is a bridge type which mimics HTTPS traffic, one of the most common types of traffic on the Internet. It’s based on HTTPT which resists active probing attacks that censors use to block censorship circumvention techniques. WebTunnel will likely, and ultimately become a very important bridge type for Tor as it rolls out and gains popularity due to the protocol it disguises itself as and its resistance to active probing.

    Our new WebTunnel bridge uses a unique configuration that we came up with to hide the IP of the bridge behind a TCP proxy service. This allows us to easily switch the ‘front’ of the WebTunnel bridge in case its IP gets blocked. In the future, we plan to write about how we did this once we’ve confirmed its stability over time.

    To see our new WebTunnel bridge statistics, you can click here.

    Current Operation Envoy stats

    As it stands today, we have a collective of virtual machines consisting of 31 CPU cores, 40GB of RAM and multi-gigabit unmetered links dedicated to serving Tor bridge traffic across the world.

    Past 7 days of CPU and memory usage, click the image to see live stats

    On an average day, we are pushing almost 2TB of symmetrical bandwidth per day. That’s almost 60TB per month!

    Past 7 days of bandwidth usage, click the image to see live stats

    We can’t make all of this possible without your help. If you like what we do, please consider making a donation. As time goes on, and with more funding we’ll continue to expand our Operation Envoy footprint by deploying more Tor bridges across the world. Your help can make a real impact for Internet censorship circumvention.

  • Introducing FreeSocks, proxies that circumvent censorship

    Easy censorship circumvention

    We despise censorship and human (& animal) rights abuses, and it’s time to fight back. In addition to Operation Envoy, our effort to provide stable and performant anti-censorship Tor bridges and snowflake proxies, we’re launching FreeSocks. FreeSocks is a free and open proxy service that aims provide an alternative to individuals that live in or are visiting countries with a heavily censored internet. With FreeSocks proxies, people that reside in countries with oppressive governments can access the open internet freely.

    An internet free of censorship is extremely important in countries where the internet is censored heavily. It provides access to information that individuals may never find out about, for example the Tiananmen Square massacre and countless other atrocities and injustices carried out by governments around the world. It also allows people to communicate freely amongst themselves, so that they’re not afraid to show their true selves. In the modern age, governments are only getting better at restricting access to content and services they deem ‘unpalatable’. China is one government which is particularly advanced in their censorship efforts, and is constantly tweaking their Great Firewall to block more and more content and services. This is why services like FreeSocks are important.

    A screenshot of the FreeSocks website

    Our tech stack

    The underlying technology that FreeSocks provides is Outline (Shadowsocks) proxies (deployed around the world), which encrypt and obfuscate user’s internet traffic. The website guides users on how they can retrieve and use the proxy access keys that we provide to them. We make an attempt to reduce the chance for abuse by preventing people from retrieving a proxy if they are not within an especially oppressive country. At a later date, we’ll detail exactly how we provide this service and the underlying code that FreeSocks uses. We think it’s pretty cool, as the functionality of retrieving and expiring proxy access keys (via the outline-server API) lives entirely on the Cloudflare Workers serverless platform. The entire FreeSocks platform is very flexible because of this. Something awesome is that our Workers cron triggers to expire access keys at defined intervals run only in datacenters that are powered by renewable energy.

    We do all of this in a privacy respecting way, and we don’t log the IPs of active users, or who might have even requested a proxy.

    Where do we go from here?

    We need your help to maintain FreeSocks, deploy more proxies and fight the censors! If you like to support organizations like ours, please consider making a donation.

    With your help we:

    • Plan to continuously deploy new Outline proxy servers in strategic locations.
    • Plan to translate all pages on the website to different languages, so that people who can’t translate or read English can use the service.
    • Plan to provide mirrors of the site in case the main URL is inaccessible.
    • Plan to extend the expiration time of access keys (30 days at the time of launch) based on reception and use.

    We’ve worked really hard on FreeSocks, and we hope that you can get good use out of the service. Share it with your friends who might be subjected to internet censorship. If you use the service, and have any trouble – please contact us.

  • What we’re doing in response to the jabber.ru MITM attack

    As you may have heard, jabber.ru, a popular XMPP service discovered a sophisticated MITM attack against their service that may have lasted for up to 6 months. They published a great blog post, going over all the details of the attack and measures to prevent this sort of attack from happening on other services.

    From reading the post, it was apparent that the same attack could also happen on XMPP.is, and potentially other Unredacted services. We’ve confirmed in multiple ways that this attack is not currently happening on XMPP.is infrastructure. However, it’s important for us to take precautions and be alerted to this sort of attack if it were to happen in the future.

    What we’ve done

    • We have utilized CertWatch, a service by xmpp.net to alert us to the potential fact that there is an ongoing MITM attack against our XMPP service. At the time of this post, there is no ongoing MITM attack according to their service.
    What it looks like if no MITM is active when manually checking CertWatch
    • To subscribe to CertWatch alerts for XMPP.is, you can open either link in your XMPP client:
    • We have verified that our XMPP.is certificate fingerprint transparency automation is working as intended.
      • If you wish to manually check that the certificate presented to your XMPP client is valid, we have a script that has been running for many years that outputs the fingerprints from newly issued certificates. The output can be found here and is automatically updated.
    A screenshot of the current fingerprints as of this blog post
    • We have signed up for Cloudflare’s Certificate Transparency Monitoring on all important domains, so that admins can be notified when new certificates get issued for Unredacted services. This allows us to have 2 sources in which we could be notified of a potential MITM attack.
    • We have double checked and ensured that we utilize CAA records across all domains.

    What we will explore

    • We are considering automating the monitoring of default gateway MAC address changes across our dedicated hardware infrastructure. We already ingest metrics via Prometheus node_exporter that allow us to track this historically.
    • We are planning on setting up Cert Spotter, and monitoring all important domains so that we can be notified of certificate changes when they happen.
    • We plan to ensure that all existing XEPs that are mentioned in this blog post (which are supported by Prosody) get implemented on XMPP.is. This will help support channel binding and other existing SASL issues.

    Our final thoughts

    It is concerning that any attack like this can go unnoticed, and it’s unfortunately something that’s easy to miss. People think as valid certificates as automatically trustworthy. However, in cases where someone has access to your physical infrastructure a lot of things are possible, including what happened with jabber.ru (issuing Let’s Encrypt certificates from their DNS A/AAAA record IP). It’s also equally worrying that there are many certificate authority failures. When they are the root of trust, and they are not trustworthy it creates the potential for many problems with TLS on the internet.

  • Operation Envoy: Defeating Censors

    Operation background

    Accessing the uncensored Internet in some countries has never been so difficult. Internet censorship is rising across the world, and content filtering is becoming more difficult to circumvent as technology and censors evolve. Even in countries you wouldn’t expect. However the worst offenders are the ones you would typically suspect, China, Russia and countries who rank low on the World Press Freedom Index.

    The organization, OONI (Open Observatory of Network Interference) monitors internet censorship around the world and produces reports which show that censorship is on the rise. Government censors (governments who implement Internet censorship) are insatiable in their quest to restrict Internet access and keep their citizenry blind and oppressed, just how they like it.


    The question is, what are we doing about it? That’s where Operation Envoy comes in. We want to help deliver messages (network packets) to and from the Tor network. For quite a while now, we’ve been running Tor exit relays which provide valuable bandwidth and processing power to the Tor network which helps people in heavily censored countries access services and information that people in the western world take for granted. While exit relays are an integral part of the Tor network, there’s another part that is critical for accessing it in many countries. Tor bridges and snowflake proxies are the first entry point into the Tor network for many people. What are they you might be wondering? Well, many countries block access to Tor and they’re very good at it, which makes Tor hard to access. That’s where Tor bridges and snowflake proxies step in, and so do we. Bridges and snowflake proxies allow Tor users to access the network via an obfuscated and seemingly normal-looking connection to the bridge or proxy. That bridge or proxy then acts as a literal bridge to the Tor network.

    Censors have even gotten so audacious that they’ve identified specific signatures of user to snowflake proxy traffic and blocked it. Thanks to the anti-censorship team at Tor, they are hyperaware of these issues and always trying to be a step ahead of the censors.

    Where the operation stands

    So, that’s where we’ve been focusing most of our censorship evasion efforts. The Tor network has plenty of bandwidth, but it has problems with accessibility and bridges/snowflake proxies help with that. At the time of writing we’ve ramped up to 29 high-bandwidth servers around the world that run Tor snowflake proxies 24/7/365. We have 34 CPU cores and 58GB of RAM at our disposal. Some servers are in strategic locations that help users within censored countries access the proxies themselves.

    Over the past 30 days, we’ve pushed over 93TB of symmetrical traffic on our bridges & proxies.

    See our stats

    The future of Operation Envoy

    Our goal with this operation is to run as many high quality dedicated bridges and snowflake proxies as possible, and become one of the largest operators. We believe Operation Envoy is essential, as many of the snowflake proxies are run via home networks which typically do not provide high upload and download speeds.

    To scale our growing bridge and snowflake proxy server infrastructure, we use automation software called Ansible and have started writing our own Ansible role to help with that. This allows us to update and maintain our Tor bridge and proxy fleet.

    To succeed in our mission, we ask for your help via donation. With your help, we can deploy more and more censorship evasion servers around the world. In an effort to fund our operations, if you make a recurring donation of $10/mo or more after reading this post, be sure to contact us and let us know – we will deploy a Tor bridge or snowflake proxy in your name!

    We plan to release updates on our operation as it expands, so stay tuned.

    Thanks for your support,
    Zach

  • What we’re doing in response to the invasion of Ukraine

    https://blog.torproject.org/tor-and-the-humans-who-use-it/

    The situation in Ukraine is unsettling, and requires the world to step in and help on every front. Whether you do your part and help with donations, use your cybersecurity skills or attending & staging protests, anything helps.

    In response to the invasion of Ukraine by the Russian military, we have expanded our operations on the Tor network.

    What exactly does this do, and how does it help, you might ask?

    Tor is a network of virtual tunnels that allows you to improve your privacy and security on the Internet. Tor works by sending your traffic through three random servers (also known as relays) in the Tor network. The last relay in the circuit (the exit relay) then sends the traffic out onto the public Internet.

    Source: https://tb-manual.torproject.org/about/

    This makes Tor critical infrastructure to those living in oppressive countries. Without Tor, they can’t access many sites and services that provide views that their governments don’t want them to see.

    While Tor is accessible in Ukraine (despite internet outages), and not being actively blocked, it is not the same in Russia. There are many Russians who do not agree with the decision to invade Ukraine, and they have been staging protests across Russia. As such, it’s very important that Russian protestors have a way to access the uncensored internet. For many years, Roskomnadzor, a Russian agency focused on censoring and controlling the media Russian’s consume, has been cutting Russians off from websites and services they deem unpalatable. Right now, Tor is blocked in Russia, and we want to help unblock it through anti-censorship Tor bridges. Everyone should have access to an uncensored internet.

    How specifically are we helping combat this now?

    Well, since the start of the invasion we’ve deployed 5 additional Tor bridges (our focus), and 4 exit relays. Our Tor bridges were deployed in strategic locations, close to but outside of Russia, for optimal latency.

    What exactly are Tor bridges?

    Tor bridges are the first hop onto the Tor network for many users in countries enforcing internet censorship. They use obfuscation to disguise Tor traffic to and from a user, & make it look unsuspicious to would-be snoopers looking to block connections to the Tor network.

    Since the deployment of our Tor bridges, we’ve seen high usage across the board. This doesn’t surprise us, as Tor usage has been spiking in Ukraine, and bridge usage is up in Russia.

    Source

    Since the invasion of Ukraine on February 24th to now (Feb 27th), our own metrics show that we have pushed over 100 TB of symmetrical traffic to and from the Tor network via all of our Tor relays and bridges.

    Source

    How can you help?

    You might be wondering, how can I help this effort to provide uncensored internet access. Well, it’s quite simple actually, and you don’t need to be tech-savvy at all. You can install Tor’s Snowflake browser add-on which helps censored users access the Tor network.

    https://snowflake.torproject.org/

    Additionally, you can donate to Unredacted. We will use any funds during the conflict to spin up new Tor bridges and expand our Tor footprint to help those experiencing internet censorship.

    Donate here: unredacted.org/donate

    You can also see the real world impact of your funding here (although Tor bridges produce much less traffic than other relay types): https://grafana.unredacted.net/d/ce-tor-bridges/unredacted-tor-bridge-metrics?orgId=1

    We wish the best for the people of Ukraine and Russia alike.

    Найкращі побажання
    Zach

  • Unredacted, a new Tor relay operator

    Unredacted is a new and special project. We’re focused on operating resilient, automated and security focused infrastructure. We’re dedicated to giving back to the community through open source and privacy focused projects. We’ve ran projects such as XMPP.is, a free and open XMPP/Jabber server and other projects under the Crypto World label for quite some time.

    We’ve maintained and operated Tor relays in the past, however, never under our own network. As an ARIN member, recently expanding our IP space we registered an ASN, AS399532. Putting it to good use, we established a BGP session with BuyVM who provides our bandwidth and connectivity. We love stability, so inbound traffic to our network is DDoS protected by Path.

    We have 3 locations in which we operate Tor relays:

    • Las Vegas, NV
    • New York, NY
    • Roost, LU

    All of which can be seen on our status page.

    As a start, we currently run 6 Tor exit relays and plan to add more: metrics.torproject.org

    • Our relays are named after whistleblowers, activists and people who uphold the values that we hold dear to our hearts.
    • For the configuration management of these Tor relays, we use Ansible, which makes it extremely flexible and easy to maintain a consistent configuration across all of our relays.
    • Along with a collection of our own custom Ansible roles and playbooks, we use a fantastic role called ansible-relayor which allows for easy config management and offline keys for our relays.
    • For monitoring we use UptimeRobot, Prometheus and AlertManager, all of which give us different levels of metrics and insight into performance and network latency.

    We hope that you enjoy our project! We’re proud to provide netizens of the world with stable and fast access to and from the Tor network through our relays.

    Til next time 🙂

    Zach

Donate