4d2.su: 4d2 dot org Security Status (Beta)
==========================================

About this application - click to show

The problem: We've recently seen privacy-oriented services come under attack in several ways, from legislative saber-rattling like the EU's Chat Control initiative to an extremely concerning Man-in-the-Middle TLS attack where major hosting companies likely cooperated with law enforcement to violate the privacy of jabber.ru users.

In the jabber.ru attack, hosting companies used their privileged network position to obtain phony TLS certificates for jabber.ru services. These were then secretly used to create an intermediate termination point for secure traffic. Users and site admins saw that connections were encrypted, but communication was presumably being decrypted and funneled elsewhere. This continued for months before it was noticed.

How we're defending ourselves: We already take industry standard precautions such as publishing restrictive CAA records. On this page we try to close some remaining gaps by testing the validity of our own certificates using as many mutually uncooperative parties as possible. This doesn't do anything to prevent an attack, but it makes it as difficult as possible for a MitM attack against us to go unnoticed. Here's how it works:

• This site uses a domain name registered in a different TLD from our other domains (.su), and runs on a different machine hosted with a different provider than our most popular services.
• Every few minutes, the servers hosting our public services (email, Matrix, CryptPad, etc.) export the SHA-256 fingerprint and validity dates of all their TLS certificates. This data comes from the local copies of these certificates on each application server. These fingerprints and validity dates are pushed to this machine via SSH with key-based authentication.
• Every few minutes, a client machine that we control makes a TLS client connection to each of our applications that supports TLS, and logs the SHA-256 fingerprint and validity date it receives from the server. The results are then sent to this machine using SSH.
• This app compares the data received by these two mechanisms. If certificate fingerprints or validity dates don't match, we flag that entry as "suspicious" on this page.
• Each exchange of certificate information between servers also exchanges a randomly-generated UUID. The UUIDs received by this machine are displayed here, and the UUIDs sent by each remote machine are linked directly from those machines for you to compare. An attacker who compromised this app to display fake data would have to compromise all our machines for the UUIDs to match.

This is not absolute protection from an impersonation attack, or anything close. It just tries to make such an attack as inconvenient, expensive and obvious as possible.

What attacks are still possible, and how do I mitigate them?

• This site or server could be compromised and our code changed to display false results
  • Verify the SHA-256 fingerprints on this page against your own browser and against the crt.sh database
  • Compare the sent and received UUIDs above to ensure they match and are rotating every 10 minutes
  • Verify that sent UUIDs are linked directly from remote servers, and that received UUIDs are embedded in this page
• The admins could be coerced into deliberately breaking this app
  • Keep an eye on the warrant canary
  • Keep your threat model realistic - this is unlikely as we're not a haven for criminality
• We could be an elaborate corporate honeypot hellbent on collecting your personal data
  • Only discuss sensitive topics over end-to-end encrypted services like Matrix or PGP email
• The SHA-256 algorithm could be broken in some way not yet publicly known
  • Relax, because you and the rest of the internet will soon have much bigger problems to worry about
• And infinitely many more, depending on your level of paranoia...
  • Consider a refreshing cup of chamomile tea

Back to 4d2 dot org