GPG has been the de facto standard for file encryption for decades, but its age shows. The OpenPGP specification (RFC 4880) carries decades of backward compatibility baggage: configurable cipher suites that invite downgrade attacks, a web-of-trust model that almost nobody uses correctly, a keyring/keyserver architecture that leaks metadata, and a UX so hostile that even security professionals routinely misconfigure it. The attack surface is enormous — not because the cryptography is weak, but because the decision space presented to the user is.

OpenSSL's enc command is another common choice, but it's even worse from a usability standpoint: no native public-key encryption, no authenticated encryption by default (CBC mode without HMAC), and easy-to-forget flags that silently produce insecure output.

age was created by Filippo Valsorda (former Go cryptography lead at Google) to solve exactly this problem: provide a file encryption tool that is secure by default, with no configuration knobs to turn wrong, explicit key management, and UNIX-style composability. When combined with age-plugin-yubikey, it delivers hardware-backed key protection with a fraction of GPG+smartcard complexity.

2. What is age

age (pronounced "ah-geh", from the Italian word) is a file encryption tool, file format, and library. Its design philosophy can be summarized in four principles:

• No configuration. No config files, no keyrings, no keyservers. Keys are explicit arguments.

• No algorithm negotiation. One cipher suite, chosen by the developers, not the user.

• Small explicit keys. Recipients are short strings (age1...) that fit in a chat message.

• UNIX composability. Reads from stdin, writes to stdout, pipes cleanly.

The format specification lives at age-encryption.org/v1 and has multiple interoperable implementations: the reference Go implementation (filippo.io/age), rage in Rust, typage in TypeScript, and others in Python, Java, Kotlin, and Swift. The plugin system (introduced in v1.1.0) enables custom recipient types — hardware tokens, cloud KMS, post-quantum hybrids — without touching the core format.

3. Cryptographic Primitives

age uses a deliberately small, modern cryptographic suite with no user-selectable options:

How it fits together

1. A random 16-byte file key is generated per encryption operation.

2. The file key is wrapped (encrypted) independently for each recipient — using X25519 ephemeral ECDH for public-key recipients, scrypt for passphrases, or a plugin-specific mechanism for hardware tokens.

3. Each wrapped copy becomes a stanza in the ASCII header.

4. HKDF-SHA-256 derives two keys from the file key: one for the header MAC (authenticating the header stanzas) and one for the payload stream key.

5. The payload is encrypted as a stream of 64 KiB chunks using ChaCha20-Poly1305, where each chunk is independently authenticated.

This design provides forward privacy (ephemeral ECDH keys mean a compromised long-term key cannot decrypt past ciphertexts) and multi-recipient support without re-encrypting the payload — only the 16-byte file key is wrapped once per recipient.

For post-quantum resistance, age now supports hybrid ML-KEM-768 + X25519 keys (recipients starting with age1pq1...), though this is still experimental.

4. Basic age Usage

Key generation

# Generate a new X25519 key pair
age-keygen -o key.txt
# Output:
# Public key: age1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# The file contains the secret key (AGE-SECRET-KEY-1...)
# The public key is printed to stderr

Encryption and decryption

# Encrypt to a recipient's public key
age -r age1recipient... -o secret.txt.age secret.txt

# Encrypt to multiple recipients
age -r age1alice... -r age1bob... -o shared.age document.pdf

# Encrypt with a passphrase (interactive prompt)
age -p -o backup.tar.age backup.tar

# Decrypt with a key file
age -d -i key.txt -o secret.txt secret.txt.age

# Pipe-friendly usage
tar czf - ./project | age -r age1recipient... > project.tar.gz.age
age -d -i key.txt < project.tar.gz.age | tar xzf -

SSH key compatibility

# Encrypt to an existing SSH public key
age -R ~/.ssh/id_ed25519.pub -o secret.age secret.txt

# Decrypt with the corresponding SSH private key
age -d -i ~/.ssh/id_ed25519 secret.age > secret.txt

5. YubiKey Integration

This is where age genuinely outclasses GPG. Setting up GPG with a smartcard involves generating keys on the host, moving subkeys to card slots, managing trust databases, and configuring gpg-agent. With age-plugin-yubikey, the entire flow is: install the plugin, run one command, encrypt.

How age-plugin-yubikey works

The plugin uses the YubiKey's PIV (Personal Identity Verification) applet — the same applet used for smart card authentication in enterprise environments. Specifically:

• It generates an ECDSA P-256 key pair directly on the YubiKey.

• The private key never leaves the hardware.

• The key is stored in one of the 20 "retired" PIV slots (82–95), which avoids conflicts with standard PIV slots (9a, 9c, 9d, 9e) that may hold RSA keys for other purposes.

• An age identity file is produced that contains the slot reference and YubiKey serial number — enough for the plugin to locate the key at decryption time, but not the key material itself.

The plugin acts as a bridge: age clients discover it via the naming convention (age-plugin-yubikey in $PATH), delegate key operations to it, and the plugin communicates with the YubiKey via the PC/SC interface.

HMAC-SHA1 Challenge-Response vs. PIV: Two Approaches Compared

The YubiKey Shell Toolkit implements both approaches. Understanding the tradeoffs is important:

The HMAC approach is simpler and works on YubiKeys without PIV support, but it relies on OpenSSL's enc command in CBC mode (not authenticated encryption) and requires managing an auxiliary .yk.challenge file. The challenge file alone is not sensitive — without the physical YubiKey to compute the HMAC response, it's useless — but losing it means losing the file.

The PIV approach is strictly superior for most use cases: authenticated encryption, multi-recipient support, a standardized format, and configurable PIN/touch policies. Use HMAC only when PIV is unavailable (e.g., YubiKey NEO).

HMAC approach (for reference)

The yk-encrypt-file.sh script demonstrates the HMAC flow:

#!/usr/bin/env bash
set -euo pipefail

INPUT="\({1:?Usage: \)0 <file>}"
FILE="\((cd "\)(dirname "\(INPUT")" && pwd)/\)(basename "$INPUT")"
SLOT=2

# Generate random challenge
CHALLENGE=$(openssl rand -hex 32)

# YubiKey computes HMAC — secret never leaves hardware
HMAC=\((ykman otp calculate 2 "\)CHALLENGE" 2>/dev/null) || {
    echo "[!] YubiKey did not respond." >&2; exit 1
}

# Derive AES-256 key from challenge+HMAC
KEY=\((echo -n "\){CHALLENGE}${HMAC}" | openssl dgst -sha256 -binary | xxd -p -c 256)

# Encrypt with AES-256-CBC + PBKDF2
openssl enc -aes-256-cbc -pbkdf2 -iter 600000 \
    -k "\(KEY" -in "\)FILE" -out "${FILE}.yk.enc"

echo "\(CHALLENGE" > "\){FILE}.yk.challenge"

Installation and Setup

Prerequisites

# Debian/Ubuntu
sudo apt-get install pcscd age libpcsclite-dev

# Fedora
sudo dnf install pcsc-lite age pcsc-lite-devel

# Arch
sudo pacman -S pcsclite pcsc-tools yubikey-manager age

# Ensure pcscd is running
sudo systemctl enable --now pcscd

Install age-plugin-yubikey

# Homebrew (macOS/Linux)
brew install age-plugin-yubikey

# Cargo (Rust 1.70+)
cargo install age-plugin-yubikey

# Arch Linux
pacman -S age-plugin-yubikey

Pre-built binaries for Windows, Linux, and macOS are available on the releases page.

Generate a YubiKey identity

Interactive mode (recommended for first-time setup):

age-plugin-yubikey

This launches a text-based wizard that:

1. Detects connected YubiKeys and lets you select one.

2. Shows available PIV slots and selects a free "retired" slot (e.g., slot 82).

3. Prompts you to name the identity.

4. Asks for PIN policy (never, once, always) and touch policy (never, always, cached).

5. If default PINs are detected, prompts you to change them.

6. If the default management key is detected, generates a random one and stores it in PIN-protected metadata.

Programmatic mode:

age-plugin-yubikey --generate \
    --slot 1 \
    --name "backup-encryption" \
    --pin-policy once \
    --touch-policy always \
    > ~/.config/yk-toolkit/age/yubikey-identity.txt

Extract the recipient (public key) for sharing:

# List all age recipients from connected YubiKeys
age-plugin-yubikey --list

# Or extract from a specific slot
age-plugin-yubikey --identity --slot 1 2>/dev/null \
    | grep "^# recipient:" | cut -d' ' -f3 \
    > ~/.config/yk-toolkit/age/yubikey-recipient.txt

Practical Examples

Single-recipient encryption with YubiKey

The yk-age-encrypt.sh script wraps age with sensible defaults:

# Encrypt using the stored YubiKey recipient
./yk-age-encrypt.sh document.pdf
# → document.pdf.age

# Encrypt with an explicit recipient
./yk-age-encrypt.sh -r age1yubikey1qfmj3... -o secrets.age secrets.env

# Decrypt (requires physical YubiKey + PIN/touch)
./yk-age-decrypt.sh document.pdf.age

The script automatically resolves the recipient by checking (in order):

1. The -r flag.

2. ~/.config/yk-toolkit/age/yubikey-recipient.txt.

3. Live query via age-plugin-yubikey --list.

Direct age commands (no wrapper)

# Encrypt
age -r age1yubikey1qfmj3... -o report.age report.xlsx

# Decrypt — the plugin handles YubiKey interaction transparently
age -d -i yubikey-identity.txt -o report.xlsx report.age

When the touch policy is set to always, the YubiKey's LED will blink during decryption — physical touch is required to authorize the cryptographic operation.

6. Multi-Recipient Encryption

This is where age + YubiKey truly shines for team workflows. Since age wraps the file key independently for each recipient, you can encrypt a single file to multiple YubiKeys, software keys, or a mix of both.

Use cases

• Team access: Encrypt shared secrets to every team member's YubiKey.

• Redundancy: Encrypt to both a primary and backup YubiKey in case one is lost.

• Hybrid recovery: Encrypt to your YubiKey and a passphrase-protected software key stored in a safe.

• CI/CD pipelines: Encrypt to a hardware key for humans and a software key for automation.

Multi-recipient scripts

The yk-age-encrypt-multikeys.sh script supports multiple recipients via -r flags or a recipients file:

# Encrypt to multiple recipients via flags
./yk-age-encrypt-multikeys.sh \
    -r age1yubikey1qfmj3...   \
    -r age1yubikey1q2xk7...   \
    -r age1ql3z7hjy54pw...    \
    secrets.tar.gz

# Or maintain a recipients file
cat ~/.config/yk-toolkit/age/recipients.txt
# Primary YubiKey
age1yubikey1qfmj3...
# Backup YubiKey
age1yubikey1q2xk7...
# Software fallback key
age1ql3z7hjy54pw...

# Encrypt using the recipients file (auto-loaded)
./yk-age-encrypt-multikeys.sh secrets.tar.gz

The corresponding yk-age-decrypt-multikeys.sh tries multiple identity files:

# Decrypt with multiple identity files
./yk-age-decrypt-multikeys.sh \
    -i ~/yubikey-primary-identity.txt \
    -i ~/yubikey-backup-identity.txt \
    secrets.tar.gz.age

# Or maintain an identities file
cat ~/.config/yk-toolkit/age/identities.txt
/home/user/.config/yk-toolkit/age/yubikey-identity.txt
/home/user/.config/yk-toolkit/age/backup-identity.txt

# Decrypt using the identities file (auto-loaded)
./yk-age-decrypt-multikeys.sh secrets.tar.gz.age

age will try each identity until one succeeds — you only need one matching YubiKey inserted.

Practical redundancy pattern

# Setup: generate identities on two YubiKeys
age-plugin-yubikey --generate --slot 1 --name "primary" \
    --pin-policy once --touch-policy always > primary-identity.txt

# Swap YubiKeys
age-plugin-yubikey --generate --slot 1 --name "backup" \
    --pin-policy once --touch-policy always > backup-identity.txt

# Also generate a software recovery key
age-keygen -o recovery-key.txt

# Collect all recipients
age-plugin-yubikey --list > all-recipients.txt
grep "^# public" recovery-key.txt | cut -d: -f2 >> all-recipients.txt

# Encrypt backups to all three
tar czf - ~/documents | age -R all-recipients.txt -o backup.tar.gz.age

If the primary YubiKey is lost, decrypt with the backup or the software key. Then re-encrypt with a new set of recipients.

7. Security Considerations and Best Practices

Hardware-backed key advantages

• Non-extractable private keys: The PIV applet does not allow exporting generated private keys. Even with physical access to the YubiKey and the PIN, the key material cannot be read.

• PIN brute-force protection: After 3 failed PIN attempts, the YubiKey locks. After 3 failed PUK attempts, the PIV applet is permanently locked (requires a full reset, destroying all keys).

• Touch confirmation: With --touch-policy always, every cryptographic operation requires physical contact — malware cannot silently decrypt files even if it has access to the identity file and the YubiKey is plugged in.

Best practices

1. Change default PINs immediately. The default PIV PIN is 123456 and PUK is 12345678. age-plugin-yubikey prompts for this, but verify.

2. Use --pin-policy once --touch-policy always as a baseline. "Once" means the PIN is cached for the session (avoiding repeated prompts during batch decryption), while "always" touch prevents silent use.

3. Always encrypt to at least two recipients — your primary YubiKey and a recovery mechanism (backup YubiKey or software key in secure storage).

4. Protect identity files. While the identity file doesn't contain the private key, it tells age which YubiKey and slot to use. Treat it as sensitive metadata: chmod 600.

5. Store software recovery keys offline — printed on paper, in a safe deposit box, or on an encrypted USB drive stored separately.

6. Rotate keys when a YubiKey is lost. Re-encrypt all accessible data to a new recipient set that excludes the lost key.

7. Pin caching caveat: On YubiKey 4 series, PIN cache preservation does not work due to how the serial number is obtained — the plugin performs a soft reset that clears the cache. YubiKey 5 series handles this correctly.

Threat model boundaries

age with YubiKey protects data at rest. It does not provide:

• Signing or authentication (use SSH or FIDO2 for that).

• Forward secrecy for stored files — if a file was encrypted to a recipient, compromising that recipient's key allows decryption of that specific file. Forward privacy applies to the encrypting side (ephemeral ECDH), not the recipient's long-term key.

• Deniability — the header reveals the number of recipients (stanza count) and the recipient type (plugin name).

8. Ecosystem and Tooling

Core tools

Integration tools

• SOPS — Mozilla's secret manager supports age as a backend. Combine with age-plugin-yubikey for hardware-backed secret management in GitOps workflows.

• YubiKey Shell Toolkit — Bash scripts for both HMAC and age-based YubiKey encryption, including multi-recipient support, setup automation, and verification.

• passage — A password store (like pass) built on age instead of GPG.

• awesome-age — Curated list of age ecosystem projects.

Relevant scripts from YubiKey Shell Toolkit

9. Conclusion

age represents what encryption tooling should have been all along: a single correct cipher suite, explicit key management, no footguns. Adding YubiKey via age-plugin-yubikey elevates it from "good software encryption" to "hardware-rooted key protection" with remarkably little ceremony — age-plugin-yubikey --generate, then age -r as usual.

For teams, the multi-recipient model is the real differentiator. Encrypting shared secrets to every team member's YubiKey (plus a recovery key) is a one-liner, not a GPG keyring management odyssey. When someone leaves the team, re-encrypt to the updated recipient list. When a YubiKey is lost, the PIN lockout protects against brute force while you rotate.

The combination is particularly compelling for:

• Encrypted backups — hardware-keyed, with software recovery fallback.

• Secret management in Git — via SOPS + age + YubiKey.

• Sensitive file exchange — share a short age1yubikey1... string, not a GPG key fingerprint ceremony.

• Compliance environments — hardware-backed key storage with touch confirmation satisfies many audit requirements.

If you're still wrapping files with gpg -c or openssl enc, it's time to upgrade.

References

• age — github.com/FiloSottile/age

• age format specification — age-encryption.org/v1

• age-plugin-yubikey — github.com/str4d/age-plugin-yubikey

• YubiKey Shell Toolkit — github.com/Esl1h/yubikey-shell-toolkit

• awesome-age ecosystem — github.com/FiloSottile/awesome-age

Escrevi mais a respeito dele em https://esli.blog.br/age-criptografia-de-arquivos-simples-moderna-e-segura

Em resumo, o uso é o seguinte:

# Encrypt
age -r age1ql3z7hjy8zmrj2kg5sfn9aqmcac8p -o file.enc file.txt

# Decrypt
age -d -i key.txt -o file.txt file.enc

age + YubiKey PIV — como funciona

O plugin age-plugin-yubikey usa o slot PIV da YubiKey (não o HMAC challenge-response) para encrypt/decrypt:

• Gera um key pair diretamente no YubiKey (chave privada nunca sai do hardware)

• Exporta a identity (referência ao slot PIV) e o recipient (chave pública)

• Encrypt usa a chave pública (não precisa da YubiKey)

• Decrypt exige a YubiKey fisicamente presente + PIN + touch

Comparativo

Criei dois .sh:

Um usando openssl com a chave Yubikey (HMAC): https://github.com/Esl1h/yubikey-shell-toolkit/blob/main/yk-encrypt-file.sh

E o outro, usando o age com a chave Yubikey: https://github.com/Esl1h/yubikey-shell-toolkit/blob/main/yk-age-encrypt.sh

Caso de uso prático

• Cifrar backups no servidor sem a YubiKey presente (só a chave pública)

• Decifrar só na tua máquina com a YubiKey plugada

• Compartilhar arquivos cifrados com múltiplas pessoas (cada uma com seu recipient)

Instalação do plugin

# age-plugin-yubikey (Rust, via cargo ou release binário)
cargo install age-plugin-yubikey

Encriptando com mais de uma chave Yubikey

Segundo as recomendações, você deveria ter duas chaves Yubikey. Como encriptar permitindo o acesso ao arquivo posteriormente, com qualquer uma das duas?

Além disso, outra possibilidade com o age é encriptar um arquivo que possa ser desencriptado usando 5 ou 6 chaves específicas, trabalhando em equipe por exemplo.

Isto é nativo no age, a flag -r aceita múltiplos recipientes:

age -r "\(RECIPIENT_1" -r "\)RECIPIENT_2" -r "$RECIPIENT_3" -o arquivo.age arquivo  

O age encripta uma chave de sessão efêmera para cada recipiente separadamente e qualquer uma das chaves privadas correspondentes consegue decriptar. É o mesmo modelo do PGP (--recipient múltiplo).

Utilizando o script para múltiplas chaves:

https://github.com/Esl1h/yubikey-shell-toolkit/blob/main/yk-age-encrypt-multikeys.sh

https://github.com/Esl1h/yubikey-shell-toolkit/blob/main/yk-age-decrypt-multikeys.sh

# Encrypt para 3 YubiKeys
yk-age-encrypt-multikeys.sh -r age1yubikey1q... -r age1yubikey1q... -r age1... arquivo.txt


# Ou via recipients.txt (recomendado)
yk-age-encrypt-multikeys.sh arquivo.txt


# Decrypt com YubiKey específico
yk-age-decrypt-multikeys.sh -i ~/.config/yk-toolkit/age/yk2-identity.txt arquivo.txt.age

O age gera uma chave de sessão única e aleatória para o arquivo (usando ChaCha20-Poly1305).

Essa mesma chave de sessão é encriptada várias vezes: uma vez para a Chave A, uma para a Chave B, etc. Todas essas "versões" encriptadas da chave de sessão são guardadas no cabeçalho do arquivo .age.

Ao decriptar, o age testa as identidades que você possui. Se a sua YubiKey conseguir abrir qualquer um dos "cadeados" do cabeçalho, ela libera a chave de sessão e o arquivo é aberto.

Vantagens dessa abordagem:

• Redundância: Se você perder sua YubiKey principal, mas tiver configurado uma YubiKey de backup, você recupera seus dados.

• Colaboração: Você pode encriptar um arquivo que tanto você quanto outros consigam abrir com suas respectivas chaves físicas.

• Performance: A velocidade de encriptação e decriptação não muda quase nada, pois o arquivo em si é encriptado apenas uma vez; apenas o cabeçalho cresce alguns bytes para cada chave extra.

Conclusão

O primeiro script (yk-encrypt.sh) usa o YubiKey como um gerador de senhas complexas que são transformadas em uma chave pelo OpenSSL; já o segundo (yk-age-encrypt.sh) através do age utiliza criptografia de chave pública (Piv), separando a chave pública da privada (guardada no hardware).

No age, a segurança é reforçada pelo uso do algoritmo ChaCha20-Poly1305, que além de esconder os dados, garante que ninguém altere sequer um bit do arquivo sem ser detectado, algo que o OpenSSL do primeiro script não faz automaticamente.

Para um atacante, o nível de risco de conseguir abrir seu arquivo sem possuir fisicamente o seu YubiKey é extremamente baixo, beirando o impossível com a tecnologia atual. No entanto, o script que usa o age é superior porque exige um PIN (senha numérica) para liberar o acesso ao hardware, adicionando uma camada extra de proteção: se alguém roubar seu YubiKey, ainda precisará da sua senha. Já no primeiro script (yk-encrypt.sh), a segurança depende totalmente de manter o arquivo de "challenge" guardado; se um atacante copiar seu arquivo encriptado e o arquivo de challenge, a única barreira restante é a posse física do YubiKey.

Portabilidade: O age é um binário único e estático. Você consegue decriptar esse arquivo em praticamente qualquer OS apenas instalando o age e conectando a chave.

Recuperação: Com PIV no YubiKey, é vital ter o PIN e o PUK anotados, pois se o PIN for bloqueado por excesso de tentativas, o acesso à chave privada é perdido permanentemente.

Identidade: A "chave pública" gerada pelo age (começando com age1...) pode ser compartilhada ou publicada sem medo — ela serve apenas para que as pessoas (ou seus scripts) possam encriptar arquivos para você. Inclusive, a minha está no perfil do meu GitHub.

Embora o uso de HMAC e OpenSSL seja uma solução funcional, o age foi projetado especificamente para ser simples, seguro e à prova de erros humanos. Ao usar o age-plugin-yubikey, você eleva o nível do seu workflow: elimina a necessidade de gerenciar arquivos de "challenge" extras, ganha proteção por PIN nativa do hardware e utiliza algoritmos de criptografia de última geração. Para quem busca proteger segredos em servidores, backups ou arquivos sensíveis no Linux, a combinação age + YubiKey é hoje um padrão-ouro de praticidade e segurança.

Foi exatamente essa dor que motivou a criação do age.

O que é o age

O age (pronuncia-se com "g" duro, como o italiano "aghe" — e sim, sempre em minúsculas) é uma ferramenta de criptografia de arquivos criada por Filippo Valsorda e Ben Cox. Filippo não é um nome qualquer: ele foi o responsável pela equipe de criptografia do Go na Google e mantém atualmente a infraestrutura criptográfica do ecossistema Go.

O age é três coisas ao mesmo tempo:

• Uma CLI (age e age-keygen) para cifrar e decifrar arquivos

• Um formato de arquivo com especificação aberta em age-encryption.org/v1

• Uma biblioteca Go (filippo.io/age) para integração em aplicações

A filosofia de design é simples: chaves pequenas e explícitas, zero opções de configuração, composabilidade no estilo UNIX. Não escolhe algoritmo, não configura nada, só cifra e decifra. Ponto.

Por que o age existe

O Filippo resumiu a motivação de forma direta: o age foi criado para substituir os casos de uso em que as pessoas usavam gpg -c (criptografia simétrica com passphrase) e gpg -e (criptografia com chave pública). A premissa é que, quando alguém chega no age, já sabe qual problema quer resolver — e quer uma ferramenta que poupe a dor de lidar com opções criptográficas legadas que ninguém deveria precisar entender.

O GPG/PGP carrega décadas de bagagem: algoritmos deprecados, negociação de parâmetros criptográficos (tamanho de chave, tipo de cifra, rounds), keyrings complexos, web of trust, e uma UX que parece ter sido projetada por um comitê em 1998, e na verdade, foi! O age joga tudo isso fora e começa do zero, com primitivas modernas e sem concessões retrocompatíveis.

Uma decisão deliberada e controversa: o age não suporta assinaturas digitais. A justificativa é que signing adiciona uma dimensão inteira de complexidade na UX, no gerenciamento de chaves e no design criptográfico de um formato streamable. O age cuida de integridade e confidencialidade, não de autenticação de remetente. Se você precisa de assinaturas, use minisign ou sigstore ferramentas especializadas para isso.

Como funciona por baixo

A criptografia do age é construída sobre primitivas bem estabelecidas:

Cifra de payload: ChaCha20-Poly1305 — a mesma AEAD usada no WireGuard, TLS 1.3 e SSH. Em hardware sem AES-NI (como muitos ARM), ChaCha20 tende a ser mais rápido que AES-GCM. O payload é dividido em chunks de 64 KiB, cada um cifrado individualmente usando um esquema STREAM (variante do que é usado no Tink e Miscreant), o que permite cifrar e decifrar de forma streaming sem carregar o arquivo inteiro em memória.

Troca de chaves (X25519): curva elíptica Curve25519 via Diffie-Hellman. As chaves públicas começam com age1... e são codificadas em Bech32 — curtas o suficiente para colar numa mensagem ou num arquivo de configuração. Uma chave pública age tem ~62 caracteres. Compare com uma chave pública RSA-4096 do GPG.

Derivação de chaves: HKDF-SHA-256 é usada para derivar as chaves de wrap e payload a partir do segredo compartilhado e da file key.

Passphrase (modo simétrico): scrypt para derivação, com work factor configurado automaticamente.

Pós-quântico (v1.3.0+): suporte nativo a recipients híbridos ML-KEM-768 + X25519 (baseado em HPKE). Chaves começam com age1pq1.... Isso protege contra ataques de computadores quânticos futuros no modelo "harvest now, decrypt later".

O formato é estritamente definido: não há negociação de algoritmos, não há opções de configuração criptográfica. Uma cifra, uma curva, um KDF. Ponto. Isso elimina a classe inteira de vulnerabilidades que surgem de downgrade attacks e de escolhas ruins de parâmetros.

Uso prático

Geração de chaves

# Chave X25519 padrão
age-keygen -o key.txt
# Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

# Chave pós-quântica
age-keygen -pq -o key-pq.txt

Cifrar e decifrar

# Cifrar com chave pública
age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p secrets.tar.gz > secrets.tar.gz.age

# Cifrar com passphrase
age -p secrets.txt > secrets.txt.age

# Decifrar
age -d -i key.txt secrets.tar.gz.age > secrets.tar.gz

Composabilidade UNIX

# Cifrar um backup e enviar via SSH
tar czf - ~/docs | age -r age1... | ssh server "cat > backup.tar.gz.age"

# Cifrar para múltiplos recipients
age -r age1alice... -r age1bob... arquivo.txt > arquivo.txt.age

# Cifrar para as chaves SSH públicas de alguém no GitHub
curl https://github.com/usuario.keys | age -R - arquivo.txt > arquivo.txt.age

Suporte a chaves SSH

O age aceita cifrar diretamente para chaves ssh-ed25519 e ssh-rsa:

age -R ~/.ssh/id_ed25519.pub arquivo.txt > arquivo.txt.age
age -d -i ~/.ssh/id_ed25519 arquivo.txt.age > arquivo.txt

Útil como atalho, mas as chaves SSH não são ideais para criptografia de longo prazo, por serem tipicamente revogáveis e pensadas para autenticação, não para cifrar dados que vão ficar armazenados por anos.

Inspecionar arquivos cifrados

Desde a v1.3.0, o age-inspect mostra metadados sem decifrar:

age-inspect secrets.age
# secrets.age is an age file, version "age-encryption.org/v1".
# This file is encrypted to the following recipient types:
#   - "mlkem768x25519"
# This file uses post-quantum encryption.

Instalação

O age está empacotado em praticamente toda distro relevante:

# Arch
pacman -S age

# Fedora
dnf install age

# Debian 12+ / Ubuntu 22.04+
apt install age

# macOS
brew install age

# Windows
winget install --id FiloSottile.age

# Via Go
go install filippo.io/age/cmd/...@latest

age vs. GPG vs. OpenSSL vs. o resto

Vamos ao que interessa: como o age se compara com as alternativas.

GPG/PGP

O elefante na sala. O GPG é o canivete suíço da criptografia — faz tudo, e faz tudo de forma dolorosamente complicada. Chaves enormes, keyrings frágeis, trust models que ninguém entende, algoritmos legados habilitados por padrão, UX hostil. O age resolve especificamente o caso de uso de criptografia de arquivos, descartando tudo que não é essencial.

O que o GPG ainda faz e o age não: assinaturas digitais, web of trust, integração nativa com clientes de e-mail, gerenciamento de identidades complexas. Se você precisa assinar commits (embora SSH também faça isso agora), assinar pacotes .deb ou manter uma identidade PGP para comunicação, o GPG ainda tem seu lugar.

O age foi projetado explicitamente para substituir gpg -c e gpg -e, não o GPG inteiro.

OpenSSL

O OpenSSL é uma biblioteca, não uma ferramenta de usuário final. Sim, você pode cifrar arquivos com openssl enc, mas está operando numa abstração muito baixa: precisa escolher o algoritmo, o modo de operação, lidar com IVs, derivação de chave, e o formato de saída não é padronizado. Um erro sutil e você compromete toda a segurança. O age abstrai tudo isso de forma segura por padrão.

minisign / signify

Ferramentas especializadas em assinaturas digitais. Não fazem criptografia. Complementam o age — use age para cifrar, minisign para assinar.

Vault / SOPS / Sealed Secrets

São ferramentas de gerenciamento de segredos, não de criptografia de arquivos de uso geral. Mas é aqui que o age brilha no ecossistema DevOps: o Mozilla SOPS suporta age como backend de criptografia, substituindo GPG com uma experiência infinitamente mais simples. O Flux CD recomenda explicitamente o uso de age em vez de PGP para gerenciar secrets no Kubernetes. O chezmoi (gerenciador de dotfiles) também tem suporte nativo.

rage (Rust)

O rage é uma implementação alternativa em Rust, totalmente interoperável com o age. Mesmo formato, mesmas chaves. Se você prefere binários Rust ou precisa integrar com o ecossistema Rust, é uma opção de primeira classe.

Typage (TypeScript)

O typage é a implementação TypeScript oficial, mantida pelo próprio Filippo. Funciona no browser, Node.js, Deno e Bun. Suporta até WebAuthn/passkeys para criptografia via hardware.

Ecossistema e adoção

O age não é um projeto experimental de fim de semana. É um projeto maduro com adoção real:

• 21.6k+ stars no GitHub, 629 forks, 18 releases (v1.3.1 é a mais recente, de dezembro de 2025)

• Especificação formal mantida no C2SP com vetores de teste padronizados (CCTV)

• Implementações em múltiplas linguagens: Go (referência), Rust (rage), TypeScript (typage), Java (Jagged), Kotlin (kage), Swift (AgeKit)

• Integração com ferramentas de infraestrutura: SOPS, Flux CD, chezmoi, gopass, Logseq, Apache NiFi

• Plugins para hardware: age-plugin-yubikey, age-plugin-tpm, age-plugin-se (Secure Enclave)

• Empacotado em todas as distros Linux relevantes, macOS (Homebrew/MacPorts), Windows (winget/Chocolatey/Scoop), FreeBSD, OpenBSD

• Licença BSD-3-Clause

A lista completa de projetos do ecossistema está em awesome-age.

O estado de maturidade: o age atingiu a v1.0 em 2021, tem uma especificação formal estável, múltiplas implementações interoperáveis, suporte pós-quântico nativo desde v1.3.0, e é mantido ativamente por um dos criptógrafos mais respeitados do ecossistema open-source. É seguro tratá-lo como produção.

O que o age não faz (e não pretende fazer)

• Assinaturas digitais — use minisign, sigstore, ou SSH signing

• Gerenciamento de identidades / web of trust — não existe um "keyring age"

• Criptografia de e-mail — não é o caso de uso; use PGP/GPG ou Signal

• Criptografia de disco — use LUKS/dm-crypt

• Comunicação em tempo real — use Noise framework, Signal, WireGuard

O age é cirúrgico no escopo: criptografia de arquivos. Faz uma coisa e faz bem. A filosofia UNIX, como deveria ser.

Exemplo prático: backup cifrado com age

Um script mínimo para backup cifrado:

#!/usr/bin/env bash
set -euo pipefail

RECIPIENT="age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p"
BACKUP_DIR="/backup"
SOURCE="$HOME/documentos"
DATE=$(date +%Y%m%d-%H%M%S)
DEST="\({BACKUP_DIR}/backup-\){DATE}.tar.zst.age"

tar cf - "$SOURCE" \
  | zstd -T0 --long -19 \
  | age -r "$RECIPIENT" \
  > "$DEST"

echo "Backup cifrado: \(DEST (\)(du -h "$DEST" | cut -f1))"

Para restaurar:

age -d -i ~/key.txt backup-20260405-120000.tar.zst.age | zstd -d | tar xf -

Composabilidade UNIX. Sem mágica, sem configuração, sem surpresas.

Considerações finais

O age é a resposta para quem quer cifrar arquivos sem precisar entender a história inteira da criptografia assimétrica desde 1991. Primitivas modernas, design minimalista, composabilidade UNIX, e um autor que sabe o que está fazendo.

Se você usa GPG apenas para cifrar arquivos (e sejamos honestos, esse é o caso de 90% das pessoas), o age é uma substituição direta e superior. Se você precisa do ecossistema completo do PGP (assinaturas, web of trust, integração com e-mail), o GPG continua sendo necessário — mas provavelmente menos do que você imagina.

Instale, gere uma chave, cifre algo. A experiência fala por si.

Links e referências

• Repositório principal: github.com/FiloSottile/age

• Especificação do formato: age-encryption.org/v1

• Especificação formal (C2SP): github.com/C2SP/C2SP/blob/main/age.md

• Man page: filippo.io/age/age.1

• rage (Rust): github.com/str4d/rage

• Typage (TypeScript): github.com/FiloSottile/typage

• Jagged (Java): github.com/exceptionfactory/jagged

• age-plugin-yubikey: github.com/str4d/age-plugin-yubikey

• awesome-age (ecossistema): github.com/FiloSottile/awesome-age

• Blog do Filippo sobre autenticação no age: words.filippo.io/age-authentication

• SOPS (Mozilla): github.com/getsops/sops

• Release v1.3.0 (pós-quântico): github.com/FiloSottile/age/releases/tag/v1.3.0

• Flux CD + SOPS + age: fluxcd.io/flux/guides/mozilla-sops

This is a comprehensive guide covering the encrypted DNS ecosystem: protocols, DNSCrypt, DNS Stamps, practical setup on Linux and Android, and the SNI leak that undermines everything if left unaddressed.

Traditional DNS: the problem

DNS (Domain Name System) resolves domain names into IP addresses. It works like a phone book: you ask for the number of esli.blog and get the server's IP. The problem is that this "call" happens without encryption. Anyone in the path — your ISP, the coffee shop admin, an attacker on the same network — can see exactly which domains you're resolving.

The DNS protocol was designed in the 80s, when the internet was an academic environment and the concept of network privacy didn't exist. We're still paying for that design decision.

Encrypted DNS protocols

Over time, several protocols emerged to fix this. Each with different trade-offs.

DoT (DNS-over-TLS)

Wraps DNS queries inside a TLS connection. Uses port 853, dedicated exclusively to this purpose. Standardized in RFC 7858.

Using a dedicated port is a double-edged sword: easy to configure, but also easy to block. A network admin (or government) can simply block port 853 and DoT is gone. Android uses DoT natively via "Private DNS" since version 9, which popularized the protocol on mobile devices.

DoH (DNS-over-HTTPS)

Wraps DNS queries inside HTTPS connections, using port 443. Standardized in RFC 8484.

The trick is that DoH traffic blends with regular HTTPS traffic. To block DoH, you'd need to block all HTTPS, which would break the web. This makes it more censorship-resistant, but also harder to monitor in corporate environments (where monitoring may be legitimate). Browsers like Firefox and Chrome support DoH natively.

DoQ (DNS-over-QUIC)

Uses the QUIC protocol (which runs over UDP) to transport DNS queries. Standardized in RFC 9250.

More recent, it promises lower latency than DoT/DoH by eliminating the separate TLS+TCP handshake. Still limited adoption, but providers like AdGuard DNS already support it.

DoH3 (DNS-over-HTTP/3)

Similar to DoQ, but using HTTP/3 as transport. Since HTTP/3 already uses QUIC, it inherits the same latency advantages. Providers like DNS0 (founded by NextDNS co-founders) already support it.

ODoH (Oblivious DNS-over-HTTPS)

An anonymization layer on top of DoH. Uses an intermediary proxy (relay) so the resolver never sees the client's IP. Standardized in RFC 9230.

The concept is similar to Anonymized DNSCrypt (covered below): separate who asks from who answers.

DNSCrypt: the protocol the industry ignored

DNSCrypt was created by Frank Denis (jedisct1), the same author of libsodium. It's not a "patch" on top of another protocol. It was designed specifically to protect DNS traffic.

What it does:

• Server authentication. The client validates it's talking to the legitimate resolver using the provider's public key. No dependency on CAs (Certificate Authorities). This eliminates the entire TLS chain of trust, which is a known point of failure.

• Query and response encryption. Uses Curve25519 for key exchange and XSalsa20-Poly1305 (or XChaCha20-Poly1305) for authenticated encryption. All based on elliptic curve cryptography, no dependency on RSA or X.509 certificate infrastructure.

• Anti-replay and anti-forgery. Each query has a unique nonce. Forged or replayed responses are detected and discarded.

• Padding. Queries and responses are padded with random data to hinder traffic analysis based on packet size.

The protocol runs over UDP (port 443 by default) and optionally TCP. It's lightweight, fast, and doesn't depend on PKI infrastructure.

The protocol is in the process of IETF standardization as an Internet-Draft (draft-denis-dprive-dnscrypt-06, updated April 2025).

Why did the industry ignore it?

Google, Cloudflare, Apple, Microsoft — they all adopted DoH and DoT. DNSCrypt was left out of the mainstream. Not because it's technically inferior, but because there's no megacorp behind it sponsoring adoption. DoH uses HTTPS, which the entire web infrastructure already supports. DNSCrypt requires its own implementation.

Result: the DNSCrypt protocol has limited adoption among major providers. AdGuard DNS, Quad9, and CleanBrowsing support it. NextDNS, Cloudflare, and Google do not support the DNSCrypt protocol — only DoH and DoT.

But here's the crucial distinction: the DNSCrypt protocol is one thing, the dnscrypt-proxy software is another.

dnscrypt-proxy: the Swiss army knife

dnscrypt-proxy is the reference client implementation. Written in Go, it runs on practically anything: Linux, macOS, Windows, Android, OpenWrt routers.

The key point is that dnscrypt-proxy is not limited to the DNSCrypt protocol. It supports:

• DNSCrypt v2

• DoH (DNS-over-HTTPS)

• ODoH (Oblivious DoH)

• Anonymized DNSCrypt

So even if a provider doesn't support the DNSCrypt protocol (like NextDNS), you can still use dnscrypt-proxy to connect via DoH. The software accepts stamps from any supported protocol.

Anonymized DNSCrypt: DNS without tracking

Encrypted DNS solves the interception problem along the path. But it doesn't solve the problem of the resolver itself knowing who made the query. Your IP arrives at the server alongside the query.

Anonymized DNSCrypt solves this by introducing relays:

1. The client encrypts the query for the final resolver (using the resolver's public key).

2. Sends the encrypted query to a relay.

3. The relay doesn't have the resolver's key, so it can't read the content. It just forwards the packet.

4. The resolver receives the query, decrypts it, resolves it, and responds via the relay.

The relay knows the client's IP but not the query content. The resolver knows the query content but only sees the relay's IP. Neither has the complete picture.

This is fundamentally different from using Tor for DNS (which is slow and wasn't designed for it) or blindly trusting that the resolver is "no-log."

The list of available relays is in the official repository.

DNS Stamps: the QR code of DNS

Manually configuring encrypted DNS is tedious. You need to specify protocol, IP, port, hostname, path (for DoH), public key (for DNSCrypt), and optionally certificate hashes. Multiple fields, each with a different format depending on the protocol.

DNS Stamps solve this by encoding everything into a single string.

Structure

A stamp starts with sdns:// followed by a base64url payload. The first byte of the payload identifies the protocol:

After the protocol byte, the payload contains properties (DNSSEC, no-log, no-filter), IP address, certificate hashes, hostname, path, and optionally bootstrap IPs.

Practical example

A DoH stamp for NextDNS with ID abc123:

sdns://AgMAAAAAAAAAAAAADmRucy5uZXh0ZG5zLmlvBy9hYmMxMjM

Decoded:

• Protocol: 0x02 (DoH)

• Hostname: dns.nextdns.io

• Path: /abc123

• No-log: yes

• DNSSEC: yes

Generating stamps

The official generator is at dnscrypt.info/stamps. Select the protocol, fill in the fields, and the stamp is generated automatically. It works in reverse too: paste a stamp and it decodes the fields.

The DNS Stamps specification is in the process of IETF standardization (draft-denis-dns-stamps-00, July 2025), supporting DNSCrypt, DoH, DoT, DoQ, and ODoH.

Who publishes stamps natively?

Not every provider makes life easy. Some publish ready-made stamps in their documentation, others require manual generation.

Important note about NextDNS: contrary to what many think, NextDNS does provide the stamp on the Setup page. Go to my.nextdns.io, access Setup Guide, select Routers, and look for the DNSCrypt section. The stamp is already generated with your config ID. It's a DoH stamp (not native DNSCrypt, since NextDNS doesn't support the DNSCrypt protocol).

To generate manually or add a device name to the path, use the generator at dnscrypt.info/stamps with these fields:

The path must start with /. If your ID is abc123, the path is /abc123. To identify the device in the dashboard, add a name: /abc123/fedora-desktop.

The complete list of resolvers with ready-made stamps is in the official repository.

Protocol comparison

* Default port 443, but configurable.

Setting up dnscrypt-proxy on Linux

Why dnscrypt-proxy instead of the NextDNS CLI?

NextDNS offers its own CLI (nextdns via sh -c "$(curl -sL https://nextdns.io/install)"). It works fine, it's simple. But dnscrypt-proxy offers advantages:

• Supports multiple protocols (DNSCrypt, DoH, ODoH)

• Allows switching providers without changing the stack

• Support for Anonymized DNSCrypt and relays

• Local cache with configurable TTL

• Cloaking, local blocklists, forwarding rules

• Detailed logs for debugging

• Works identically on any distro

If you just want NextDNS working quickly, the official CLI does the job. If you want granular control or plan to use features beyond what NextDNS offers natively, dnscrypt-proxy is the way.

Installation

Fedora:

sudo dnf install dnscrypt-proxy

The package installs the binary, the systemd service, and the configuration file at /etc/dnscrypt-proxy/dnscrypt-proxy.toml.

Arch / EndeavourOS / Omarchy:

sudo pacman -S dnscrypt-proxy

Same structure. Arch keeps the package updated frequently.

Debian / Ubuntu:

sudo apt install dnscrypt-proxy

Warning: versions in Debian/Ubuntu repositories may be outdated. Check with dnscrypt-proxy --version and compare with releases on GitHub. If significantly behind, install manually via the GitHub binary.

Getting the NextDNS stamp

Two methods:

Method 1 (recommended): go to my.nextdns.io, navigate to Setup Guide, select Linux or Routers, and copy the stamp from the DNSCrypt section. It already includes your config ID.

Method 2 (manual): go to dnscrypt.info/stamps and fill in:

Copy the resulting stamp (sdns://...).

To identify the machine in the NextDNS dashboard, add the device name to the path: /abc123/fedora-desktop.

Configuration

Edit the main file:

sudo vim /etc/dnscrypt-proxy/dnscrypt-proxy.toml

Essential settings:

# Listen address
listen_addresses = ['127.0.0.1:53', '[::1]:53']

# Force exclusive use of NextDNS
server_names = ['nextdns']

# Enable IPv6 if your network supports it
ipv6_servers = false

# Require DNSSEC, no-log, and no-filter
require_dnssec = true
require_nofilter = false
require_nolog = true

# Local cache
cache = true
cache_size = 4096
cache_min_ttl = 2400
cache_max_ttl = 86400

# Disable automatic download of public lists
# (we want ONLY NextDNS)
# Comment out or remove [sources] sections if they exist:
# [sources]
#   [sources.'public-resolvers']
#     ...
#   [sources.'relays']
#     ...

# Static server with your stamp
[static]
  [static.'nextdns']
  stamp = 'sdns://AgMAAAAAAAAAAAAADmRucy5uZXh0ZG5zLmlvBy9hYmMxMjM'

Replace the stamp with the one generated using your real ID.

About the cache: the values above are intentionally aggressive. cache_min_ttl = 2400 (40 minutes) and cache_max_ttl = 86400 (24 hours) significantly reduce the number of queries to NextDNS. If you're on the free plan (300k queries/month), this makes a difference. Even on the paid plan, fewer queries = less latency for frequently accessed domains.

The systemd-resolved conflict

If you're on Fedora, Ubuntu, or any distro using systemd-resolved, brace yourself: it listens on port 53 by default and will conflict with dnscrypt-proxy.

Check before anything:

ss -tlnp | grep ':53 '

If systemd-resolve shows up listening on 53, you have two options:

Option A: Disable systemd-resolved (recommended)

If you want full DNS control and don't need resolved for anything:

sudo systemctl disable --now systemd-resolved
sudo rm /etc/resolv.conf
echo 'nameserver 127.0.0.1' | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf

The chattr +i makes the file immutable. Without it, NetworkManager will overwrite resolv.conf on the first reconnection. To edit later: sudo chattr -i /etc/resolv.conf.

Option B: Coexistence (dnscrypt-proxy on alternate port)

If for some reason you need to keep resolved (corporate VPN integration, mDNS/Avahi, etc.):

In dnscrypt-proxy.toml:

listen_addresses = ['127.0.0.1:5353']

In /etc/systemd/resolved.conf:

[Resolve]
DNS=127.0.0.1#5353
DNSStubListener=yes

sudo systemctl restart systemd-resolved

It works, but adds an unnecessary layer. The resolved becomes a middleman that just forwards. Unless you have a concrete reason, go with Option A.

Note for Arch with Hyprland / Window Managers

If you don't use NetworkManager and configure networking via iwd, dhcpcd, or manually, systemd-resolved is probably not even active. Check with systemctl status systemd-resolved. If inactive, nothing to do. Just ensure /etc/resolv.conf points to 127.0.0.1.

Persisting resolv.conf on Fedora with NetworkManager

NetworkManager rewrites /etc/resolv.conf on every reconnection. Besides chattr +i, there's a cleaner approach: tell NetworkManager not to manage DNS.

Create /etc/NetworkManager/conf.d/no-dns.conf:

[main]
dns=none

sudo systemctl restart NetworkManager

From here on, NetworkManager doesn't touch DNS. Your resolv.conf with nameserver 127.0.0.1 stays intact.

Enabling and starting

sudo systemctl enable --now dnscrypt-proxy.service

Verify:

systemctl status dnscrypt-proxy
journalctl -u dnscrypt-proxy -f

In the logs, look for lines indicating the nextdns server was validated. Something like:

[nextdns] OK (DoH) - rtt: XXms

If you see stamp errors or server not found, review the stamp and check that no default servers are enabled competing with the static configuration.

Validation

# Resolution via dnscrypt-proxy
dig @127.0.0.1 esli.blog

# Confirm NextDNS is active
curl -sL https://test.nextdns.io

The test.nextdns.io response should show:

• Status: Connected (or Using NextDNS)

• Protocol: DoH

If it returns "not using NextDNS", check:

• The stamp (correct path with /YOUR_ID?)

• Does server_names point to the correct name?

• Is any default server still enabled in sources?

• Does resolv.conf point to 127.0.0.1?

Also test filtering. Access a domain that should be blocked by your NextDNS blocklists:

dig @127.0.0.1 some-blocked-site.example

If it returns 0.0.0.0 or NXDOMAIN, filtering is working.

Advanced optional configurations

Anonymized DNS with relays

If you want to go further and use relays so NextDNS doesn't see your IP (via Anonymized DoH), add to dnscrypt-proxy.toml:

[anonymized_dns]
routes = [
    { server_name='nextdns', via=['anon-relay-1', 'anon-relay-2'] }
]

Available relays are in the dnscrypt-proxy resolver list. This adds latency but significantly increases privacy. If NextDNS shouldn't know which IP the queries come from, this is the way.

Local blocklists

dnscrypt-proxy supports its own blocklists, independent of NextDNS. In dnscrypt-proxy.toml:

[blocked_names]
blocked_names_file = '/etc/dnscrypt-proxy/blocked-names.txt'

In blocked-names.txt, add domains (one per line, supports wildcards):

*.facebook.com
*.tiktok.com
ads.*

This works even if NextDNS is down. It's an additional local filtering layer.

Query logging for debug

[query_log]
file = '/var/log/dnscrypt-proxy/query.log'
format = 'tsv'

Create the directory first:

sudo mkdir -p /var/log/dnscrypt-proxy
sudo chown _dnscrypt-proxy:_dnscrypt-proxy /var/log/dnscrypt-proxy

TSV format makes analysis easy with awk, cut, and friends. Disable in production if privacy is a priority.

Encrypted DNS on Android

What Android already offers (and why it's not enough)

Since Android 9, there's a "Private DNS" option in Settings > Network. It works with DoT (DNS-over-TLS) pointing to a hostname like abc123.dns.nextdns.io (where abc123 is your NextDNS config ID).

Does it work? Yes. But it has limitations:

• Only supports DoT. No DoH, no DNSCrypt, no ODoH.

• No configurable local cache.

• No control over which app uses which DNS.

• No integrated firewall.

• No configurable fallback.

• If the DoT server doesn't respond, Android may fall back to the ISP's DNS silently (depending on the option: "automatic" falls back, "strict" blocks).

• No logs for debugging.

For most people, Private DNS with NextDNS in strict mode is already a massive improvement over ISP DNS. But if you want real control, you need something more.

InviZible Pro: the complete solution

InviZible Pro is an open-source Android app that integrates three privacy modules in a single package:

Available on F-Droid (unrestricted version) and Google Play. Source code at GitHub under GPLv3.

What it does

• Works with and without root. With root, redirects traffic via iptables (more efficient, no VPN overhead). Without root, creates a local VPN (traffic doesn't leave the device, it's just redirected internally to the modules).

• Integrated firewall. Granular per-app control: who can use internet, who goes through Tor, who uses direct DNS. Replaces separate firewall apps like NetGuard.

• Kill switch. If the module crashes, traffic is blocked. No accidental plaintext query leaks to the ISP's DNS.

• Tor bridges. Support for obfs4, snowflake, and webtunnel bridges to circumvent censorship on restrictive networks.

• Granular configuration. Direct access to dnscrypt-proxy.toml, torrc, and i2pd.conf files within the app with an integrated text editor.

• Real-time logs. Each module has its own log tab. Debug without needing Termux or logcat.

• Independent updates. The dnscrypt-proxy, Tor, and Purple I2P binaries are updated separately from the app.

• Stealth Mode. DPI (Deep Packet Inspection) evasion for censorship scenarios.

In short: replaces VPN + firewall + DNS adblock in a single app, no ads, no tracking, no subscription for core features.

Configuring NextDNS in InviZible Pro

Prerequisites

• InviZible Pro installed (F-Droid: pan.alexander.tordnscrypt.stable or Play Store)

• NextDNS account with a configured profile

• Your config ID (visible at my.nextdns.io in the Setup tab)

Step 1: Get the stamp

Same process as described in the DNS Stamps section. Use the stamp from the NextDNS Setup Guide or generate it manually at dnscrypt.info/stamps.

Step 2: Configure via InviZible Pro interface

1. Open InviZible Pro

2. On the DNSCrypt card, tap the gear icon

3. Go to DNSCrypt servers and uncheck all pre-configured servers

4. Go to Own servers / DNS Stamp

5. Paste the stamp

6. Name the server (e.g., nextdns)

7. Save

Step 2 (alternative): Edit dnscrypt-proxy.toml directly

If you prefer full control:

1. Menu > Common Settings > Open text editor

2. Select dnscrypt-proxy.toml

3. Edit:

server_names = ['nextdns']

cache = true
cache_size = 4096
cache_min_ttl = 2400
cache_max_ttl = 86400

[static]
  [static.'nextdns']
  stamp = 'sdns://AgMAAAAAAAAAAAAADmRucy5uZXh0ZG5zLmlvBy9hYmMxMjM'

1. Save and close

Step 3: Restart and validate

1. On the DNSCrypt card, stop and start the module

2. Check DNSCrypt logs — the nextdns server should appear as active with OK status

3. In the browser, go to test.nextdns.io

If it returns "not using NextDNS": review the stamp (leading / in path? correct config ID?), check no other server is selected, look for error messages in logs.

Step 4: Additional adjustments

DNS and Tor together (careful): if the Tor module is active, DNS queries are routed through Tor by default before reaching NextDNS. This hides your real IP from NextDNS (may be desirable) but increases latency considerably (undesirable for daily use) and may prevent NextDNS from applying location-based rules. To disable: Common Settings > uncheck "Route DNS through Tor."

Battery consumption: DNSCrypt alone consumes very little. Tor consumes more. If using only the DNSCrypt module (no Tor, no I2P), battery impact is minimal (~8% for Tor + DNSCrypt 24/7 according to InviZible docs). Exclude InviZible Pro from Android's battery optimization. Check dontkillmyapp.com for manufacturer-specific instructions (Samsung, Xiaomi/MIUI, and Huawei are the worst offenders).

Rate limit on NextDNS free plan: 300k queries/month with active filtering. After the limit, DNS continues resolving but without blocking or logs. Aggressive cache (cache_min_ttl = 2400) helps reduce query count. Monitor at my.nextdns.io > Analytics.

Alternatives to InviZible Pro

The SNI leak: the Achilles' heel of secure DNS

You configured DNSCrypt. Enabled DoH. Replaced your ISP's DNS with a privacy-respecting resolver. Did everything right. And yet, your ISP can still know exactly which sites you visit.

Welcome to the SNI problem.

Encrypting DNS queries is the first step toward reclaiming network privacy. But DNS is only half the equation. The other half happens during the TLS handshake, and that's where the leak lives that almost nobody discusses.

What SNI is and why it exists

SNI stands for Server Name Indication. It's a field sent by the client (your browser) at the beginning of a TLS connection, before any content encryption.

The reason is practical: when multiple sites share the same IP (extremely common in shared hosting, CDNs, and cloud platforms), the server needs to know which TLS certificate to present. The client provides this by sending the destination hostname in the ClientHello — the first message of the TLS handshake. In plaintext.

This means any entity positioned between you and the destination server (ISP, corporate network operator, government, airport Wi-Fi) can read the SNI field and know exactly which domain you're accessing.

In short: HTTPS protects the content. SNI gives away the destination.

What the attacker sees (and what they do with it)

With access to SNI, a network observer can:

Build a complete browsing profile. Even without seeing page content, knowing that someone accessed medicalconsult.com, jobboard.com, and laborlawyer.com on the same day already tells a story.

Selectively block sites. South Korea did exactly this in 2019: after users started circumventing DNS blocks, the government instructed ISPs to inspect the SNI field in TLS handshakes to drop connections to prohibited domains. Encrypted DNS became useless. SNI was the new control point.

Censor without breaking encryption. The ISP doesn't need to decrypt HTTPS traffic. It just reads the SNI, compares it against a list, and drops the SYN packet or sends a RST. Trivial to implement in DPI (Deep Packet Inspection) and invisible to anyone not monitoring.

Correlate traffic with identity. Combining SNI with source IP and timestamps, it's possible to link access patterns to a specific subscriber. This is done systematically in authoritarian regimes and, as demonstrated in practice, by ISPs in democracies that retain logs by legal obligation.

Encrypted DNS solves the question "which IP does this domain point to?" SNI leaks the answer: "which domain am I visiting?" Two different metadata channels. Protecting one and ignoring the other is like locking the front door and leaving the window wide open.

The evolution: from ESNI to ECH

The technical community didn't ignore the problem. The first attempt was ESNI (Encrypted Server Name Indication), proposed in 2018 as an experimental TLS 1.3 extension. The idea was simple: encrypt the SNI field using a public key available via DNS.

ESNI worked as a proof of concept but had practical limitations. Encryption was applied only to the SNI, leaving other ClientHello fields (like ALPN, cipher suite list, and extensions) still visible. This allowed observers to infer destination information even without the explicit SNI. ESNI also depended on specific DNS TXT records, making key distribution fragile and hard to scale.

The answer was ECH (Encrypted Client Hello), which superseded ESNI and is in the final stages of IETF standardization (draft 25 at the time of writing). The fundamental difference: instead of encrypting only the SNI, ECH encrypts the entire ClientHello.

How ECH works

ECH splits the ClientHello into two parts:

Outer ClientHello (public): Contains generic information like TLS version, cipher suites, and a generic SNI. In Cloudflare's case, all ECH connections show cloudflare-ech.com as the external SNI. The network observer sees only that you're accessing "something on Cloudflare," along with millions of other users.

Inner ClientHello (encrypted): Contains the real SNI, sensitive extensions, and all information that was previously sent in plaintext. This block is encrypted using a public key (ECHConfig) that the browser obtains via HTTPS/SVCB DNS records.

For the ISP or any intermediary, the TLS connection appears to be to cloudflare-ech.com. The real destination is only revealed inside the encrypted tunnel, accessible only to the destination server (or the CDN hosting it).

Think of it this way: without ECH, it's like sending a letter with the recipient's name written on the envelope. With ECH, the envelope shows "Cloudflare" and the real name is inside, sealed.

The encrypted DNS dependency

Here's the point that ties everything together: ECH depends on DNS records to function. The browser needs to fetch the domain's HTTPS/SVCB record to obtain the ECHConfig (the encryption public key). If that DNS query is made in plaintext, an attacker can simply remove or modify the record to prevent ECH.

Without DoH, DoT, or DNSCrypt, ECH can be sabotaged before it even starts.

This is why the DNSCrypt setup isn't "just about DNS." It's the foundation for ECH to work. One doesn't replace the other. They complement each other.

The complete chain for real privacy:

1. Encrypted DNS (DNSCrypt, DoH, DoT) → prevents the ISP from knowing which domains you resolve

2. ECH → prevents the ISP from knowing which domains you access via TLS

3. HTTPS → prevents the ISP from reading the communication content

Remove any of these layers and protection degrades. All three together eliminate browsing metadata visible to network observers.

Current support: who has implemented it

Browsers

Firefox was the first to enable ECH by default, and requires DoH to be active for ECH to work (which makes technical sense). Chrome and derivatives do progressive rollout.

Servers/CDNs

Cloudflare is the main driver of ECH adoption on the server side. It activated ECH across all plans, including the free tier (where it cannot be disabled). This is relevant because a significant portion of internet sites use Cloudflare as CDN/reverse proxy.

2026 data: approximately 4.2% of the top 100K sites and 9.2% of the top 1M support ECH. Seems low, but considering that Cloudflare alone covers a huge slice of web traffic, the practical impact is larger than the numbers suggest.

Other CDNs and hosting providers are still evaluating. Without server support, ECH simply isn't negotiated and the connection falls back to the old behavior (plaintext SNI).

How to verify and configure on Linux

Firefox

ECH is already enabled by default in Firefox 119+.

To confirm:

1. Go to about:config

2. Search network.dns.echconfig.enabled → should be true

3. Search network.dns.http3_echconfig.enabled → should be true

ECH in Firefox depends on DoH being active. Check in: Settings → Privacy & Security → DNS over HTTPS.

Enable with Maximum Protection and select a provider (Cloudflare, NextDNS, or custom).

Chromium/Brave/Edge

In Chrome and derivatives, ECH was controlled by a flag until version 117:

chrome://flags/#encrypted-client-hello

Currently, if DoH is active and the server supports ECH, Chrome negotiates automatically and there's no option to disable it.

Again, as with Firefox, ECH depends on Secure DNS being active. Check in: Settings → Privacy and Security → Security → Use secure DNS.

Checking sites with dig

dig HTTPS crypto.cloudflare.com +short

If it returns a field with ech=, the site supports ECH.

The presence of ECHConfig in the HTTPS-type DNS record is a necessary and sufficient condition to confirm server-side ECH support. The browser negotiates if it wants to — but the support is on the server.

Validation

To verify ECH is working on your connection:

• Visit crypto.cloudflare.com/cdn-cgi/trace and look for the field sni=encrypted

• Visit defo.ie/ech-check.php for a more detailed test

What ECH doesn't solve

ECH encrypts the ClientHello. That's significant, but it's not the end of the story.

Destination IP. ECH hides the domain, not the IP. If a server hosts a single site, the IP already reveals the destination. ECH is most effective when many sites share the same infrastructure (as in CDNs).

Traffic analysis. Data volume, access patterns, and timing are still observable. Traffic fingerprinting techniques can infer the visited site even without SNI.

Unencrypted DNS. If DNS leaks the domain before ECH kicks in, the protection is null. ECH needs DoH/DoT/DNSCrypt to work as designed.

Servers without support. If the site you're accessing doesn't support ECH, the SNI remains in plaintext. Protection depends on server-side adoption.

For more complete coverage, combine ECH with a VPN. A VPN hides the destination IP and encapsulates all traffic, while ECH protects TLS metadata. VPN + ECH + encrypted DNS is the most robust combination available today without using Tor.

ECH as an attack tool

Worth noting the other side: ECH is also useful for attackers. In 2024, researchers at NTT Security Holdings identified malware (dubbed ECHidna) that used ECH to hide communication with command and control (C2) servers. The malicious traffic masqueraded as legitimate connections to CDN infrastructure, making detection by traditional firewalls ineffective.

This isn't an argument against ECH — on the contrary: it shows the technology and cryptography work. What changes is the intent of use.

Hiding SNI from your ISP and attackers

zapret and SpoofDPI are tools that operate at the network layer to prevent Deep Packet Inspection (DPI) systems from reading the SNI field in the TLS ClientHello.

On Linux, zapret uses nfqueue (via iptables/nftables) to intercept outgoing packets before they leave the machine — upon capturing the ClientHello, it applies techniques like TCP fragmentation (split2), TTL manipulation, and fake packet insertion, causing the ISP's DPI to receive fragments out of order or with invalid data while the destination server reassembles correctly.

SpoofDPI acts as a local HTTP/HTTPS proxy: the browser connects to it, and it establishes the real connection with the destination by fragmenting the first TLS packet at the application level — simpler to configure (just point the browser proxy to 127.0.0.1:8080), but less flexible than zapret. Neither encrypts nor removes the SNI — they just make passive inspection unfeasible by breaking the heuristics of DPI equipment.

On Android, the main options are InviZible Pro, ByeDPI Android, and DPI Tunnel — all work without root by creating a local VPN on the device that intercepts outgoing traffic and applies fragmentation/desynchronization techniques on the TLS ClientHello before it reaches the ISP, preventing passive DPI from reading the SNI.

InviZible Pro is the most complete, integrating DNSCrypt, Tor, and anti-DPI modules in a single app (with root, it injects direct iptables rules, dispensing with the local VPN and avoiding conflicts). It includes an option to spoof the SNI.

ByeDPI Android is the simplest and most focused: install, choose the desync method (split/disorder), and activate — no extra configuration. As on Linux, none of them encrypt or remove the SNI; they just fragment the TCP packet so that passive inspection equipment can't reassemble and read the field in real time.

Wrapping up

The complete setup: dnscrypt-proxy on Linux (Fedora, Arch, Debian), InviZible Pro on Android, same NextDNS stamp, same config ID, same blocklists, unified analytics in the NextDNS dashboard. Three environments, one resolver, encrypted queries everywhere.

But remember: encrypted DNS alone is not enough. The SNI leak exposes your browsing destinations during TLS handshakes. ECH is the fix, but adoption is still in progress. Browser support is already universal. Cloudflare pushes server-side adoption. The pieces are falling into place.

What you control directly:

1. Enable DoH/DoT/DNSCrypt — the prerequisite for ECH to function

2. Validate ECH is active in your browser (about:config, flags, online tests)

3. Disable WebRTC — not SNI directly, but WebRTC leaks your real IP even with VPN/ECH, enabling correlation

Without ECH, SNI is the last open metadata channel for network observers. With ECH, that channel closes. The ISP stops knowing which site you visit — not just what you do inside it.

If your ISP could charge for every DNS query it snoops on, it would have funded a space program by now. Encrypt your queries. And while you're at it, push for ECH adoption.

References

• DNSCrypt project

• DNS Stamps specification

• dnscrypt-proxy on GitHub

• dnscrypt-resolvers

• InviZible Pro on GitHub

• IETF Draft: DNSCrypt

• IETF Draft: DNS Stamps

• IETF Draft: ECH

• RFC 8744 — Issues and Requirements for SNI Encryption in TLS

• Cloudflare: Announcing Encrypted Client Hello

• Cloudflare: DNS over TLS

• CDT — Encrypted Client Hello: Closing the SNI Metadata Gap

• ECH check tool

• Cloudflare trace

• NextDNS dashboard

• NextDNS test

• Don't Kill My App

This post is a unified summary of the original series, with direct references, and with technical updates that make sense in 2026 — especially around FIDO2/WebAuthn, passkeys, and PIN/management policies that have evolved significantly. I also connect it with my other posts on cryptography, because YubiKey is a practical consequence: you stop talking about "crypto" as an abstract concept and start operationalizing keys, signatures, identity, and risk.

Before anything: YubiKey is not "improved 2FA"

The temptation is to treat YubiKey as "the same 2FA, just on USB." That reduces the subject to the worst use case: typeable OTP, user-dependent, exposed to phishing and clunky UX. The real value appears when you understand it supports multiple protocols, and each one changes the type of attack you need to defeat.

When you move from codes to FIDO2/WebAuthn, for example, you're not "improving 2FA" — you're changing the category: authentication becomes bound to the origin (the site), which drastically reduces the class of attacks based on fake pages and reusable secret harvesting. When you bring the key to SSH, you reduce the impact of $HOME theft/exfiltration. When you bring it to OpenPGP, you decrease key material exposure and improve your discipline around subkeys and purposes.

2FA/MFA — The Basics

Two-factor authentication is an additional security layer that requires at least two of the following:

• What you know — passwords, PINs

• What you have — a physical device, a card

• Who you are — biometrics

An ATM withdrawal covers two: you know your PIN and have your debit card. A bank vault can use all three, with passwords, access cards, and fingerprint scans required to open it.

Traditional email and password logins cover only the first — what you know. You know your email address and password, and generally, they're easy enough for someone else to guess or crack. That's what makes them so insecure. Two-factor authentication adds a second layer to digital logins.

Almost every service now allows users to enable two-factor authentication. We're at a turning point where having 2FA enabled is mandatory in more and more services and apps.

Passwords are terrible. Most are too easy for hackers to guess, and the rest are too long or complicated for humans to remember. Even secure passwords are useless after a leak, and leaks are basically inevitable. For these reasons and more, it's a good idea not to rely exclusively on passwords.

2FA Methods

SMS or email codes — Apps send a code you need to enter before logging in. Easiest to set up because you don't need to install software or buy hardware. Also the least secure because email and SMS are not encrypted and are easily compromised.

Authenticator apps — The apps you want to log into request a code you can retrieve by opening an app on your phone, like Google Authenticator or Authy. Much more secure than relying on SMS or email, but not exactly convenient — you need to grab your phone, open an app, and type a code.

Hardware authentication — Apps ask you to plug in a device like a YubiKey and press a button. The YubiKey sends a unique code that the service uses to confirm your identity. More secure because the codes are much longer and more convenient (SMS/token codes are typically 4-6 numeric digits), and you don't need to type them yourself.

What is a YubiKey?

The YubiKey is a device that makes two-factor authentication as simple as possible. Instead of a code being sent to you (SMS) or generated by an app on your phone (Authy, Authenticator, bank tokens...), you just press a button on your YubiKey.

Each device has a unique built-in code used to generate codes that help confirm your identity. YubiKey is not the only hardware 2FA device on the market — just the most popular.

Why is it better?

• Convenience — SMS, email, and authenticator apps require you to copy-paste or manually enter a code. With YubiKey, just press a button on a device connected to your computer.

• Much longer codes — Other 2FA methods typically send only a six-digit code. YubiKeys don't ask you to type a code manually, so they can use much longer codes. More secure.

• Easy to migrate — New computer? Unplug your YubiKey from the old one, plug it into the new one, and log into all your apps as before. You can also use one key to log into your account on multiple computers.

• Extremely hard to hack — It's relatively easy for hackers to compromise your email or SMS. It's much harder — nearly impossible with current technology — to forge the codes generated by a unique hardware device.

How it works: yubico.com/why-yubico/how-the-yubikey-works

Catalog of supported services/sites/apps: yubico.com/works-with-yubikey/catalog

YubiKey 5 NFC — Overview

Released in 2018. Primary functions:

• FIDO2 — Secure single and multi-factor authentication, stores up to 25 credentials protected by a PIN. Enables passwordless login where the YubiKey, unlocked by PIN and authorized by touch, can log into accounts without entering a username or password. FIDO certified.

• OTP — Two programmable slots, each can hold: Yubico OTP, HMAC-SHA1 Challenge-Response, Static Password, or OATH-HOTP.

• U2F — Unlimited U2F credentials. FIDO certified.

• OATH — Up to 32 OATH credentials, supports OATH-TOTP (time-based) and OATH-HOTP (counter-based). Requires Yubico Authenticator.

• PIV (Smart Card) — PIV-compatible smart card. Supported algorithms: RSA 1024/2048, ECC P256/P384. Slots: 9a (Authentication), 9b (Management Key), 9c (Digital Signature), 9d (Key Management), 9e (Card Authentication), f9 (Attestation), 82-95 (Retired Key Management).

• OpenPGP — Implements OpenPGP Smart Card spec v2.0 (v3.4 on firmware 5.2.3+). Supported algorithms: RSA 1024-4096, secp256r1, secp256k1, secp384r1, secp521r1, brainpoolP256r1/384r1/512r1, curve25519, x25519 (decrypt only), ed25519 (sign/auth only). GnuPG 2.0+ required for keys above 2048 bits.

• Differentiator: NFC

For SRE/DevOps context, the most relevant protocols are: PIV, OpenPGP, HMAC-CR, and FIDO2. The private key never leaves the chip — the app sends data to the YubiKey for processing; it returns the result. That's what differentiates an HSM from a .pem file on disk.

Linux Installation

The YubiKey works out of the box — no drivers needed. Plug it into a USB port (gold contacts facing up on most computers), and the LED should light up solid green. It uses standard USB keyboard drivers.

On Linux, the key is recognized as a QWERTY keyboard input to enter the generated code when you touch the gold surface (the area with the "Y" logo).

You can use it with any software token generator (Google Authenticator, Authy, LastPass Authenticator, etc.), but for full functionality (OATH via Authenticator, PIV, OpenPGP), you'll need the smartcard stack.

Installing pcscd

The pcscd daemon is middleware for accessing smart cards — it allocates/deallocates reader drivers dynamically at runtime and manages connections.

# Debian/Ubuntu
sudo apt-get install pcscd

# Arch
sudo pacman -S yubikey-manager ykpers libfido2 pcsc-tools opensc

# Fedora
sudo dnf install yubikey-manager ykpers libfido2 pcsc-lite opensc

If installing via Snap or adding Yubico repositories on Ubuntu, pcscd is not required separately.

Verify the key is present:

ykman info

Yubico Apps

Yubico Authenticator — Complements the YubiKey for sites/apps that don't support hardware as an authenticator. You scan the QR code (or register manually) and it generates the numeric token requested after successful password login. Available for desktop and mobile (Android/iOS). It requires the YubiKey and PIN to open and display tokens.

sudo snap install yubioath-desktop

Downloads: Yubico Authenticator | Snap

YubiKey Manager — Optional. For configuring tokens and managing slots. Available as AppImage and CLI.

# Ubuntu
sudo add-apt-repository ppa:yubico/stable && sudo apt-get update

# CLI
sudo apt install yubikey-manager

# Personalization Tool
sudo apt install yubikey-personalization-gui

# PAM modules
sudo apt install libpam-yubico libpam-u2f

Downloads: YubiKey Manager | Releases

Configuring Your YubiKey

Each site/service/app has its own path to enable the key, usually in security settings near the password change option. Services that don't support the physical key support 2FA via app.

Yubico maintains a knowledge base with step-by-step instructions for configuring your key on various services:

1. Plug in your YubiKey

2. Go to yubico.com/setup and click your device

3. Browse the list of compatible apps

4. Follow the instructions

Yubico API

To get your API ID and Secret, enter an email and touch the key at: upgrade.yubico.com/getapikey

Despite the name "upgrade", the API is free.

Client ID:  58107
Secret key: 8xpmpAy2OtmZAAeXP/0NUed/aLB=

PAM Configuration — libpam-yubico

There are two ways to configure PAM authentication: libpam-yubico and libpam-u2f. You can configure both on the same host, but each file in pam.d should use only one method (no point in requiring two tokens for the same login).

Create the authentication file at /etc/yubikeys_mappings:

#username:first12charsofkey
esl1h:ccccedrrdvhv

If a user has more than one key, separate the first 12 characters of each with a semicolon. One line per user.

Optionally, keep an individual file in each user's home: ~/.yubico/authorized_yubikeys. If the key file is omitted in pam.d config, it will look in the user's home.

Add the ID and Secret:

sudo dpkg-reconfigure libpam-yubico

On the next screen (PAM enable profile), keep the defaults.

PAM Configuration — libpam-u2f

sudo apt install libpam-u2f pamu2fcfg

# Create config directory
mkdir -p ~/.config/Yubico

# Generate authentication config
pamu2fcfg > ~/.config/Yubico/u2f_keys

If you registered a PIN on the key, it will be requested. Then touch the key and it will populate the file.

Common PAM Setup

For both configurations above, in /etc/pam.d/common-auth, add try_first_pass as a parameter to pam_unix.so:

auth [success=1 default=ignore]  pam_unix.so nullok_secure try_first_pass

YubiKey for Console Login

Add at the beginning of /etc/pam.d/login:

# Using libpam-yubico (shows prompt for key):
auth sufficient pam_yubico.so id=58107
# Replace with YOUR ID!

# OR using libpam-u2f (no visual prompt, key LED blinks):
auth required pam_u2f.so

The difference: libpam-yubico presents a prompt asking for the key; with pam_u2f, nothing visual is shown — only the key's LED blinks, indicating you should touch it.

This does not modify the graphical interface login, only the console terminal login.

2FA for sudo

With libpam-u2f configured, edit /etc/pam.d/sudo. Right below the @include common-auth line, add:

auth required pam_u2f.so

When running sudo: enter password + [Enter], then touch the key to insert the token.

SSH with PAM

With pam_u2f configured, add to /etc/pam.d/sshd below @include common-account:

auth       required   pam_u2f.so

Important caveat: this only works on localhost. For remote hosts, additional configuration and sshd_config parameters are needed for a proper SSH + 2FA environment. Alternatives: use YubiKey with FIDO U2F to generate the SSH key, or use only the YubiKey token for SSH login (without password, key, or 2FA) through PGP or PIV.

OpenSSH with YubiKey + ed25519

Since OpenSSH 8.2 (released 2020), U2F/FIDO devices are supported using the ecdsa-sk and ed25519-sk public key types (FIDO2, YubiKeys with firmware above 5.2.3) and their certificates. The sk stands for "Security Key."

Check your YubiKey firmware version:

lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'

Above 5.2.3 = FIDO2 support.

The advantage: you get a normal public/private key pair, but the private key file doesn't contain the actual sensitive private key — instead, it contains a "key handle" used by the YubiKey to derive the real private key at signing time.

ssh user@host -i .ssh/id_ed25519_sk [+ passphrase] [+ yubikey-token]

Even if the key leaks, it's not enough to access the host (even knowing the username).

Why ed25519 over ECDSA: ECDSA has known vulnerabilities. RSA 4096-bit has comparable complexity to Ed25519, but Ed25519 is still preferred due to concerns that RSA may be vulnerable to the same strength concerns as DSA.

Generate keys:

# ECDSA-SK
ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk

# Ed25519-SK (preferred)
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk

# FIDO2 resident key (stored on YubiKey, portable)
ssh-keygen -t ed25519-sk -O resident -O verify-required \
    -C "esli@infra-prod" -f ~/.ssh/id_ed25519_yk

# Export handles from resident keys (use on another host without the file)
ssh-keygen -K

# Add to ssh-agent with mandatory touch confirmation
ssh-add -K ~/.ssh/id_ed25519_yk

After generating keys, add the public key (.pub) to authorized_keys on the server and/or add via ssh-agent (ssh-agent, ssh-add).

Force the SSH server to accept only YubiKey-generated keys:

In /etc/ssh/sshd_config:

PubkeyAcceptedKeyTypes sk-ecdsa-sha2-nistp256@openssh.com,sk-ssh-ed25519@openssh.com
# Or ed25519 only:
# PubkeyAcceptedKeyTypes sk-ssh-ed25519@openssh.com

GPG Keys

Creating RSA Keys

gpg --gen-key
# Or with full options:
gpg --expert --full-generate-key

Choose: (1) RSA and RSA, 4096 keysize, 3072 for subkeys, expiration as desired, then fill in identification data and set a password.

pub   rsa4096 2023-02-02 [SC]
      F40975F47855887B2084E7D18A74F970158F02B8
uid                      Esli Silva (https://esli.blog.br) <not.announced@simplelogin.fr>
sub   rsa3072 2023-02-02 [E]

Encrypting/Decrypting with GPG

# Encrypt (no password prompt — uses public key)
gpg -r F40975F47855887B2084E7D18A74F970158F02B8 -e -a -o Encrypted.pdf Original.pdf

# Decrypt (requires key + password; import key first on other hosts)
gpg -r F40975F47855887B2084E7D18A74F970158F02B8 -d -o Decrypted.pdf Encrypted.pdf

Adding Subkeys

gpg --expert --edit-key F40975F47855887B2084E7D18A74F970158F02B8

At the gpg> prompt:

gpg> addkey
# Select option (8) RSA (set your own capabilities)
# Toggle S/E/A to set desired capabilities
# S = Sign, E = Encrypt, A = Authenticate

The same key should NEVER be used for different purposes. The subkey format exists precisely to separate signing, encryption, and authentication — this improves security and your ability to operate with discipline (revoke, rotate, isolate).

RSA keypairs in PGP can still have all capability bits at once, but all other key types explicitly use different algorithms for signing and encryption — an ECDSA or EdDSA key can only sign/verify, and an ECDH key can only encrypt/decrypt. Since the master key in PGP is used to certify other people's keys and your own subkeys, it must be a signing-capable algorithm (certify).

After setting capabilities and confirming, save:

gpg> quit
Save changes? (y/N) y

Backup/Export GPG Keys

# Export secret key to stdout
gpg --export-secret-key --armor F40975F47855887B2084E7D18A74F970158F02B8

# Export public key to file
gpg --output public.pgp --armor --export F40975F47855887B2084E7D18A74F970158F02B8

# Export private key to file
gpg --output private.pgp --armor --export-secret-key F40975F47855887B2084E7D18A74F970158F02B8

Creating ECC Keys

Same steps, selecting ECC at the start:

gpg --expert --full-generate-key
# Select (11) ECC (set your own capabilities)
# Toggle capabilities as needed (S, A, Q to finish)
# Select (1) Curve 25519
# Set expiration, fill identification data

pub   ed25519 2023-02-02 [SCA]
      C512D2E3863F0D4902D63EC5BAB622429963AB29
uid                      Esli Silva (https://esli.blog.br) <my.develoment@aleeas.com>

When editing an ECC key and calling addkey, the option (8) with multiple capabilities is no longer available — ECC enforces algorithm separation by design.

Listing GPG Keys

gpg --list-keys

Importing Keys to YubiKey

gpg --edit-key F40975F47855887B2084E7D18A74F970158F02B8

gpg> keytocard
Really move the primary key? (y/N) y
Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 3

GPG with YubiKey for File/Secrets Encryption

# Check if YubiKey is recognized as GPG card
gpg --card-status

# Encrypt file to your own key (on YubiKey)
gpg --encrypt --recipient esli@esli.blog.br secrets.txt

# Decrypt — YubiKey performs the operation, requires PIN
gpg --decrypt secrets.txt.gpg > secrets.txt

# Practical: secrets in a Git repo
echo "DB_PASSWORD=hunter2" | gpg --encrypt -r esli@esli.blog.br --armor > .secrets.gpg
# At deploy time:
gpg --decrypt .secrets.gpg | source /dev/stdin

HMAC-SHA1 Challenge-Response for Key Derivation

Slot 2 of the YubiKey can be configured for HMAC-CR. You send a challenge (up to 64 bytes), it returns a 20-byte HMAC. This becomes the basis for an encryption key.

Encrypt:

#!/usr/bin/env bash
# yk-encrypt.sh — Encrypt file using YubiKey as key factor
set -euo pipefail

FILE="\({1:?Usage: \)0 <file>}"
SLOT=2

# Generate random challenge and save alongside encrypted file
CHALLENGE=$(openssl rand -hex 32)
echo "[*] Sending challenge to YubiKey (slot $SLOT)..."

# ykchalresp returns HMAC in hex
HMAC=\((ykchalresp -2 "\)CHALLENGE" 2>/dev/null) || {
    echo "[!] YubiKey did not respond. Inserted and configured?" >&2
    exit 1
}

# Derive AES-256 key via PBKDF2 (challenge + HMAC as material)
KEY=\((echo -n "\){CHALLENGE}${HMAC}" | openssl dgst -sha256 -binary | xxd -p -c 256)

# Encrypt with AES-256-CBC
openssl enc -aes-256-cbc -pbkdf2 -iter 600000 \
    -k "$KEY" \
    -in "$FILE" \
    -out "${FILE}.yk.enc"

# Save the challenge (without the HMAC — without the physical key, can't open)
echo "\(CHALLENGE" > "\){FILE}.yk.challenge"

echo "[+] Encrypted file: ${FILE}.yk.enc"
echo "[+] Challenge saved: ${FILE}.yk.challenge"
echo "[!] Without the YubiKey, the file cannot be decrypted."

Decrypt:

#!/usr/bin/env bash
# yk-decrypt.sh
set -euo pipefail

ENC_FILE="\({1:?Usage: \)0 <file.yk.enc>}"
CHALLENGE_FILE="${ENC_FILE%.enc}.challenge"
SLOT=2

CHALLENGE=\((cat "\)CHALLENGE_FILE")
echo "[*] Waiting for YubiKey..."
HMAC=\((ykchalresp -2 "\)CHALLENGE" 2>/dev/null) || { echo "[!] YubiKey failed" >&2; exit 1; }

KEY=\((echo -n "\){CHALLENGE}${HMAC}" | openssl dgst -sha256 -binary | xxd -p -c 256)

openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \
    -k "$KEY" \
    -in "$ENC_FILE" \
    -out "${ENC_FILE%.yk.enc}.decrypted"

echo "[+] Decrypted: ${ENC_FILE%.yk.enc}.decrypted"

Protocol Quick Reference

What Protocols Are Available?

Real-World YubiKey Applications for SRE/DevOps

In the real world, YubiKey stops being "just another authentication factor" and becomes a physical control point over critical actions. In infrastructure environments, this completely changes the threat model: compromising credentials isn't enough — the attacker also needs the physical device.

Privileged SSH access — Instead of relying on private keys stored on the filesystem (even with correct permissions), authentication requires physical presence and operator interaction. This eliminates an entire class of attacks based on key exfiltration (malware, compromised backups, home directory leaks). In environments with bastion hosts or access to sensitive Kubernetes clusters, this drastically reduces the risk of silent lateral movement.

Secrets protection in pipelines — Instead of storing credentials in plaintext or in misconfigured vaults, the YubiKey can serve as a root of trust for decrypting data only at execution time. Particularly useful in semi-manual pipelines (controlled deploys, runbooks, emergency operations) where human presence is already expected. In practice, the secret only "exists" in memory for a few seconds and depends on a physical factor to be accessed.

Non-repudiation for compliance — Each device has a unique identifier, making it possible to tie critical actions — key rotation, production config changes, sensitive data access — to a specific hardware device. This enables stronger auditing: not just "which user did it" but "which physical device was used."

Code signing and supply chain — GPG or hardware-based signing ensures commits, tags, and artifacts can only be signed with physical presence. This prevents an attacker who compromised a CI environment from forging signed releases — an increasingly relevant problem in supply chain attacks. Same logic applies to container images and internally distributed packages.

Unlock factor for internal tools — Admin panels, SRE portals, or sensitive CLIs can require FIDO2 authentication before executing destructive operations ("drain cluster", "delete namespace", "rotate CA"). This adds intentional friction exactly where it should exist: on irreversible actions.

Session compromise mitigation — Even if a machine is invaded or a terminal is open, the absence of the physical device prevents new authentications and critical operations. This limits attack impact and forces the adversary to act within a much more restricted window.

Personal identity anchor — The same YubiKey can be used for service login, code signing, SSH access, and data decryption. This consolidates identity, reduces attack surface, and simplifies the mental model: instead of dozens of distributed secrets, you have a single strong control point — that conveniently cannot be copied.

Programming Language Integration

Python

pip install yubikey-manager cryptography fido2
# yubikey-manager exposes the ykman API as a library

Go

go get github.com/go-piv/piv-go/piv
go get golang.org/x/crypto

Rust

# Cargo.toml
[dependencies]
yubikey = { version = "0.8", features = ["untested"] }
age = "0.10"
aes-gcm = "0.10"
rand = "0.8"
sha2 = "0.10"
rsa = { version = "0.9", features = ["sha2"] }

age + YubiKey (the modern approach): The age project is the modern successor to GPG for file encryption. The plugin age-plugin-yubikey integrates natively with PIV:

cargo install age-plugin-yubikey

Firmware Updates and Recent Changes

Yubico published relevant evolutions in the YubiKey 5 line with firmware 5.7: increased credential storage capacity, PIN management improvements, and enterprise-oriented features including enterprise attestation and CTAP 2.1 changes.

One point many people insist on ignoring: firmware is not user-upgradeable. If you want new firmware, you buy a new key.

References:

• YubiKey 5 Series with 5.7 firmware

• YubiKey 5 Technical Manual

• 5.7 Firmware Specifics

What I Consider "Good Use" of YubiKey in 2026

Good use is what reduces classes of attacks and improves your operations. Not what gives you more feeling of security.

• For web accounts: Prioritize FIDO2/WebAuthn when available. The security leap is structural — you stop depending on a typeable secret and depend on authentication bound to the correct service.

• For local Linux: If you do things that matter, requiring a token for sudo is one of the best cost/benefit ratios. Not because "nobody will become root," but because you cut the most common path of opportunistic attack.

• For SSH: Hardware-backed auth changes the impact of credential exfiltration. Doesn't cure a compromised endpoint, but reduces the damage from passive leaks and makes identity harder to clone.

• For personal/professional encryption: OpenPGP with subkeys by purpose and smartcard operation is the kind of discipline that prevents workarounds from becoming habits. Here the YubiKey is less "extra security" and more "minimum governance to not self-sabotage."

Non-negotiable rule: if you use one key, have two. The first is the one you carry. The second is the one that prevents "I lost an object" from becoming "I lost my digital identity."

Backup codes offline continue to exist for a reason.

Final Considerations

The YubiKey is not a silver bullet — it's a physical security layer that complements good practices. Points the pragmatic SRE needs to keep in mind:

• Backup: Always have a second YubiKey configured. Losing your only key is a formative experience you don't want to have.

• PIN vs Touch: Configure touch-policy=always for critical operations. Physical touch is what differentiates the YubiKey from a key file on disk.

• Remote forwarding: For remote servers, usbip allows USB forwarding over the network. Alternative: use SSH agent forwarding with ssh-agent + FIDO2.

• Auditing: The YubiKey serial is unique and can be used as an operator identifier in audit logs.

• Revocation: Have a documented process for revoking and replacing keys when a YubiKey is lost or compromised.

The premise is simple: what's on the hardware cannot be exfiltrated by malware. An attacker who compromised your machine can steal your active session, but cannot open a new SSH connection, decrypt new files, or sign new commits without the physical token. This drastically reduces the exposure window.

Conclusion

The series started as 2FA and ended as identity and risk control. If you use YubiKey only to spit out OTP, you're using the most fragile mode of the ecosystem — useful, but far from the best. The value appears when you move authentication to FIDO2/WebAuthn where possible, use the hardware to reduce exfiltration in SSH, and treat cryptography (GPG) as something that deserves separation of functions and operation with less exposure.

This post is a commented index of the series, but also a reminder: security that depends on perfect user discipline is expensive and fails. Security that improves system design is cheaper in the long run and fails less embarrassingly.

References

YubiKey Series (Portuguese originals):

• YubiKey #1 — Introdução ao 2FA

• YubiKey #2 — Linux Instalação

• YubiKey #3 — Console, sudo e SSH

• YubiKey #4 — OpenSSH + ed25519

• YubiKey #5 — Chaves GPG

Cryptography (my blog):

• Criptografia para iniciantes

• Ferramentas para Criptografia

• Como escolher Ferramentas de Criptografia

• O que é o WireGuard?

Official Yubico:

• YubiKey 5.7 Firmware Announcement

• YubiKey 5 Technical Manual

• 5.7 Firmware Specifics

• How the YubiKey Works

• Works with YubiKey Catalog

• Importing Keys to YubiKey

• Yubico Developers

Libraries and Tools:

• piv-go (Google)

• rust-yubikey (Fortanix)

• age-plugin-yubikey

• yubikey-manager (Python)

• libfido2

GPG Cheatsheets:

• devhints.io/gnupg

• GPG Cheatsheet (programster)

• GPG Cheatsheet (gock.net)

Este post é um resumo unificado dos artigos anteriores, com links diretos para referência, e com atualizações técnicas que fazem sentido em 2026 — especialmente no eixo FIDO2/WebAuthn, passkeys e políticas de PIN/gestão que evoluíram bastante. Também conecto com outros textos meus sobre criptografia, porque YubiKey é uma consequência prática: você para de falar “cripto” como conceito abstrato e passa a operacionalizar chaves, assinatura, identidade e risco.

Antes de tudo: YubiKey não é “um 2FA melhorado”

A tentação é tratar YubiKey como “o mesmo 2FA, só que em USB”. Isso é reduzir o assunto ao pior caso de uso: OTP digitável, dependente do usuário, exposto a phishing e a UXs tortas. O valor real aparece quando você entende que ela suporta múltiplos protocolos e que cada um deles muda o tipo de ataque que você precisa derrotar.

Quando você sai de códigos e entra em FIDO2/WebAuthn, por exemplo, você não está “melhorando 2FA”, você está mudando a categoria: a autenticação fica vinculada ao origin (o site), e isso reduz drasticamente a classe de ataque baseada em páginas falsas e coleta de segredo reutilizável. Quando você leva a chave para SSH, você reduz o impacto do roubo/exfiltração do seu $HOME. Quando leva para OpenPGP, você diminui a exposição do material de chave e melhora sua disciplina de subkeys e finalidades.

Parte 1 — A série original

YubiKey #1 — Introdução ao 2FA

No primeiro artigo estabeleço o motivo da série existir: senhas vazam, usuários reutilizam, e qualquer mecanismo “extra” que ainda dependa do usuário digitar um segredo é melhor do que nada, mas continua com falhas previsíveis.

A chave física entra como fator de posse para elevar a barra e reduzir o efeito dominó de credenciais comprometidas. O ponto importante ali é o enquadramento: YubiKey não é só um gerador de código. É um autenticador multi-protocolo. Isso muda a conversa de “qual app de token eu uso” para “qual protocolo eu escolho para o meu risco”. Link: https://esli.blog.br/yubikey-introducao

YubiKey #2 — Linux instalação: plug-and-play, pcscd e ferramentas

No segundo artigo trago o contexto do Linux: muitas funções básicas funcionam sem instalar nada porque parte do comportamento pode aparecer como dispositivo HID (teclado) para OTP. Só que a vida real (OATH no Authenticator, PIV, OpenPGP) passa pelo stack de smartcard e ferramentas como o Yubico Authenticator e o YubiKey Manager.

O artigo também faz um inventário do que uma YubiKey 5 NFC suporta e por que isso importa: FIDO U2F/FIDO2, OTP, OATH, PIV, OpenPGP. A consequência prática é clara: antes de “configurar”, você precisa decidir o que vai usar e o que vai desabilitar, porque deixar tudo ligado por padrão costuma ser o jeito mais eficiente de colecionar surpresas. Link: https://esli.blog.br/yubikey-linux-instalacao

YubiKey #3 — Console, sudo e SSH

O terceiro artigo é onde a YubiKey deixa de ser “2FA de site” e vira controle local de privilégio.

Eu mostro dois caminhos no PAM: um baseado em Yubico OTP (libpam-yubico com API ID/secret e mapeamento de usuários/keys) e outro baseado em U2F (libpam-u2f com pam_u2f e pamu2fcfg).

O resultado prático é endurecer login em console e, principalmente, exigir presença do token para sudo. Isso ataca um cenário comum: a senha do usuário foi obtida (ou a sessão foi “emprestada”), e agora virar root é só uma questão de hábito. Com a chave no fluxo, o atacante precisa também do hardware e do momento. Eu também deixo registrado o detalhe que muita gente ignora: “colocar PAM no SSH” não cria automaticamente um 2FA remoto robusto. Sem desenho de fluxo e parâmetros corretos, você quebra acesso ou cria uma falsa sensação de segurança. Link: https://esli.blog.br/yubikey-console-sudo-ssh

YubiKey #4 — OpenSSH + YubiKey (ed25519 e afins)

No quarto artigo entro no uso para SSH, e isso é uma das melhores aplicações para infraestrutura: reduzir o impacto de exfiltração de chaves privadas e aumentar o custo de ataque local.

A ideia é simples, mas tem implicação profunda: em vez de o host guardar um segredo que te representa, ele guarda um identificador e delega a operação de assinatura para o hardware no momento do login. Na prática, você reduz a “portabilidade acidental” de credenciais. Backups ficam menos perigosos, dotfiles vazados ficam menos catastróficos, e o atacante que conseguir ler seu disco não ganha automaticamente sua identidade SSH. Isso não resolve endpoint comprometido, mas muda o tipo de incidente e o esforço necessário para persistência. Link: https://esli.blog.br/yubikey-ssh-ed25519-ecdsa

YubiKey #5 — Chaves GPG: subkeys, finalidades e o prazer de parar de improvisar criptografia

O quinto artigo amarra criptografia aplicada com a chave: geração de chaves RSA e ECC no GnuPG, criação de subkeys, e o uso correto por finalidade. Eu bato em um ponto que vale repetir: uma chave não deveria ser “faz tudo”. Subkeys existem para separar assinatura, criptografia e autenticação; isso melhora segurança e também melhora sua capacidade de operar com disciplina (revogar, rotacionar, isolar).

Além do básico de gpg --gen-key e do fluxo de export/backup, o artigo entra em keytocard para mover material para a YubiKey e operar no modelo de smartcard. O ganho não é “criptografar mais”: é expor menos o material que realmente importa. Link: https://esli.blog.br/yubikey-chaves-gpg

Parte 2 — Onde a criptografia entra (e os meus outros artigos que se conectam com isso)

YubiKey não substitui criptografia. Ela é uma forma de forçar criptografia a sair do plano do “conceito correto” e entrar no plano do “uso correto”.

Em outras palavras: ela te obriga a pensar em identidade, chaves, finalidades, recuperação e falhas.

Isso conversa diretamente com outros textos meus: Em “Criptografia para iniciantes”, eu explico a base: simétrica vs assimétrica, hash, salt e por que confundir integridade com confidencialidade dá ruim. Esse é o pano de fundo que ajuda a entender por que “um código de 6 dígitos” (TOTP) não é do mesmo universo de uma autenticação vinculada ao origin (FIDO2). Link: https://esli.blog.br/criptografia-para-iniciantes

Em “Ferramentas para Criptografia” e “Como escolher Ferramentas de Criptografia”, eu puxo o assunto para o lado pragmático: escolher ferramenta por caso de uso, reduzir fricção, evitar complexidade desnecessária e, principalmente, não usar OpenPGP como martelo universal quando a sua dor é outra. YubiKey entra aqui como “hardening do material de chave”, não como “mais uma ferramenta de cripto”. Links: https://esli.blog.br/ferramentas-para-criptografia e https://esli.blog.br/como-escolher-ferramentas-de-criptografia

E em “O que é o WireGuard?”, eu mostro um exemplo de criptografia moderna bem aplicada: algoritmos sólidos, design direto, pouca área para erro humano e operação simples. É a mesma filosofia que justifica trocar 2FA frágil por autenticação resistente a phishing quando o ecossistema permite. Link: https://esli.blog.br/o-que-e-o-wireguard

Parte 3 — Atualizações que importam (FIDO2, passkeys e firmware recente)

O ecossistema avançou. A palavra da moda virou “passkeys”, mas a parte importante é: FIDO2/WebAuthn é a rota mais curta hoje para reduzir phishing como classe de ataque, e não só “adicionar um segundo passo”.

A Yubico publicou evoluções relevantes na linha YubiKey 5 com firmware 5.7, com aumento de capacidade de armazenamento para credenciais, melhorias de gerenciamento de PIN e recursos voltados a ambientes enterprise, incluindo opções como enterprise attestation e mudanças ligadas a CTAP 2.1. Referência oficial: https://www.yubico.com/blog/now-available-for-purchase-yubikey-5-series-and-security-key-series-with-new-5-7-firmware/

Para quem quer detalhe técnico (em vez de marketing), o manual técnico da Yubico documenta matriz de capacidades por versão de firmware e explica recursos e limitações com mais precisão, inclusive deixando explícito um ponto que muita gente insiste em ignorar: firmware não é atualizável pelo usuário; se você quer firmware novo, você compra chave nova. Referência: https://docs.yubico.com/hardware/yubikey/yk-tech-manual/yk5-firmware-overview.html e detalhes 5.7/5.6 aqui: https://docs.yubico.com/hardware/yubikey/yk-tech-manual/5.7-firmware-specifics.html

Parte 4 — O que eu considero “uso bom” de YubiKey em 2026

O uso bom é aquele que reduz classes de ataque e melhora sua operação. Não é o que te dá mais sensação de segurança.

Para contas web: priorize FIDO2/WebAuthn quando existir. O salto de segurança é estrutural, porque você deixa de depender de segredo digitável e depende de autenticação vinculada ao serviço certo.

Para Linux local: se você faz coisas que importam, exigir token no sudo é uma das melhores relações custo/benefício. Não porque “ninguém vai virar root”, mas porque você corta o caminho mais comum do ataque oportunista.

Para SSH: hardware-backed auth muda o impacto de exfiltração de credenciais. Não cura endpoint comprometido, mas reduz o estrago de vazamento passivo e deixa a identidade mais difícil de clonar.

Para criptografia pessoal/profissional: OpenPGP com subkeys por finalidade e operação via smartcard é o tipo de disciplina que evita gambiarra virar hábito. Aqui a YubiKey é menos “segurança extra” e mais “governança mínima para não se auto-sabotar”.

E a regra que eu trataria como não-negociável: se você usa uma chave, tenha duas. A primeira é a que você carrega. A segunda é a que te impede de transformar “perdi um objeto” em “perdi minha identidade digital”.

Backup codes offline continuam existindo por um motivo.

Conclusão

A série começou como 2FA e acabou como identidade e controle de risco. Se você usa YubiKey só para cuspir OTP, você está usando o modo mais frágil do ecossistema — útil, mas longe do melhor. O valor aparece quando você move autenticação para FIDO2/WebAuthn onde der, usa o hardware para reduzir exfiltração em SSH e trata criptografia (GPG) como algo que merece separação de funções e operação com menos exposição.

Este post é um índice comentado da série, mas também um lembrete: segurança que depende de disciplina perfeita do usuário é cara e falha. Segurança que melhora o desenho do sistema é mais barata no longo prazo e falha de forma menos humilhante.

Referências (série YubiKey)

https://esli.blog.br/yubikey-introducao

https://esli.blog.br/yubikey-linux-instalacao

https://esli.blog.br/yubikey-console-sudo-ssh

https://esli.blog.br/yubikey-ssh-ed25519-ecdsa

https://esli.blog.br/yubikey-chaves-gpg

Referências (criptografia no meu blog)

https://esli.blog.br/criptografia-para-iniciantes

https://esli.blog.br/ferramentas-para-criptografia

https://esli.blog.br/como-escolher-ferramentas-de-criptografia

https://esli.blog.br/o-que-e-o-wireguard

Referências oficiais (Yubico)

https://www.yubico.com/blog/now-available-for-purchase-yubikey-5-series-and-security-key-series-with-new-5-7-firmware/

https://docs.yubico.com/hardware/yubikey/yk-tech-manual/yk5-firmware-overview.html

https://docs.yubico.com/hardware/yubikey/yk-tech-manual/5.7-firmware-specifics.html

Pagar pela velocidade, pagar pelo tráfego/download, pagar a mais nos serviços assinados e... pagar mais ainda porque estou utilizando (escolhi assinar) o serviço XPTO e não o ZYX que a operadora me oferece “de graça" e fora da franquia de dados.

A Anatel abriu a Tomada de Subsídios nº 1/2026 para juntar informações e montar um possível regulamento sobre “deveres dos usuários” — com foco explícito em “grandes usuários de rede”, leia-se: plataformas grandes (streaming, redes sociais, etc.) e o tráfego que elas geram. Junto disso, entrou um segundo pacote: como serviços digitais/assinaturas (SVAs) são empurrados, cobrados e cancelados nos planos das operadoras.

Fontes:

• Notícia: TELETIME (30/03/2026)

• Texto oficial: Participa Anatel – Tomada nº 1/2026

• Nota da Anatel: Anatel (gov.br)

O que a Anatel está mirando (sem rodeios)

1. A parte “fair share” (pedágio)
   A pauta é: “plataformas grandes geram muito tráfego; logo, deveriam ajudar a pagar a conta da rede”. A tomada pede dados para sustentar esse tipo de tese: impacto de tráfego, custos, congestionamento, onde o tráfego está (no Brasil ou fora), etc.

2. A parte das assinaturas empurradas (SVA)
   Aqui o foco é mais pró-consumidor: consentimento claro, fim de “assinatura fantasma”, cancelamento menos infernal, e responsabilidades quando operadora e parceiro jogam a culpa um no outro.

O que é “assinatura fantasma”
É quando você passa a pagar por uma assinatura/SVA sem perceber direito, normalmente porque ela foi:

• incluída como “benefício” no plano e depois começou a cobrar,

• ativada com 1 clique em fluxo confuso,

• liberada como teste grátis (trial) e virou cobrança automática,

• ou “autorizada” por um consentimento genérico (caixa pré-marcada, aceite amplo, tela que mistura várias coisas).

O resultado prático é sempre o mesmo: o usuário descobre na fatura (ou no cartão) e, quando tenta cancelar, entra no modo “labirinto”.

“Isso já foi tentado antes?”

Sim, é a continuação de uma trilha antiga, com cara de “vamos insistir até colar”:

• Tomada de Subsídios nº 13/2023

• Tomada de Subsídios nº 26/2024

• Agora: Tomada de Subsídios nº 1/2026

E tem cobertura extra no mesmo sentido:

• Tele.Síntese

• Convergência Digital

• Demarest

• Contexto: TELETIME (12/03/2026)

Causas e danos (o que pode acontecer na prática)

Para o usuário final (você, eu, a conta no fim do mês)

Possível ganho real: menos “serviço extra” que aparece na fatura, menos pegadinha de trial, mais clareza de consentimento e cancelamento.

Possível dano real: se a parte do “pedágio” avançar, o custo não desaparece por mágica. Ele tende a:

• voltar como preço maior (na mensalidade, no streaming, ou nos dois),

• ou virar justificativa para piorar a Internet por categoria de uso (“este tráfego pesa, então tratemos diferente”).

Segurança e privacidade

Para sustentar o discurso de “quem congestiona o quê”, a régua pode escorregar para pedidos de monitoramento mais detalhado do uso da rede (mesmo que não falem isso assim). Em termos práticos: mais coleta/relato de dados operacionais e mais tentação de “medir por aplicação”.

Mesmo quando isso não expõe “conteúdo”, metadados e correlações já são suficientes para ampliar risco de:

• vazamento,

• uso secundário,

• e normalização de vigilância operacional em escala.

Pequenas empresas e liberdade (onde costuma doer)

Aqui entra o motivo de lobby e o efeito colateral clássico:

• Operadoras grandes ganham argumento para criar uma nova fonte de receita (“plataformas paguem”) e para reforçar poder de negociação.

• Plataformas grandes têm dinheiro e jurídico para negociar e cumprir exigências; se virar regra, elas sobrevivem.

• Pequenos provedores (ISPs) e pequenos serviços digitais podem acabar com mais burocracia, mais requisitos, mais custo fixo — ou seja, barreira de entrada e consolidação de mercado.

Isso não é “liberdade de expressão” no sentido manchete. É a liberdade mais chata e importante: a de competir e operar sem precisar de um departamento jurídico para existir.

Por que tem lobby empurrando isso?

Porque é uma pauta que promete três coisas que sempre atraem lobby:

1. Dinheiro novo (pedágio sobre tráfego, “contribuição” de plataforma, etc.).

2. Poder de barganha (quem controla a rede tenta controlar termos).

3. Narrativa vendável (“é justo”, “é para melhorar a qualidade”, “é para proteger o consumidor”).

O pedaço do consumidor (SVA) tem mérito — e justamente por isso pode servir de “cavalo de Troia” para o resto passar com menos resistência.

Conclusão

Pensa assim:

Você tem a “assinatura da airfryer”: a operadora te vende um combo bonitinho, “leve a airfryer junto”, às vezes com trial, às vezes com um clique, e pronto — de repente você está pagando a airfryer todo mês (a tal assinatura fantasma), mesmo sem ter pedido de forma clara.

Só que, além disso, você também paga a conta de luz normalmente. Ou seja: você já paga pelo serviço essencial (energia) e ainda paga pelo “aparelho/benefício” que veio acoplado.

Aí entra o plot twist regulatório: o governo olha pro sistema e diz:

“Tem gente usando airfryer demais. Então vamos cobrar um imposto da fabricante de airfryer porque os clientes dela estão consumindo muita energia.”

Na teoria, parece “justo”: quem gera mais uso, paga mais.

Na prática, o que acontece quase sempre é:

1. A fabricante repassa o custo no preço da airfryer (ou na “assinatura” dela).

2. O varejo/operadora repassa de novo no combo.

3. E o usuário continua pagando a conta de luz do mesmo jeito.

Resultado: você paga a airfryer, paga a energia, e agora paga também o imposto “sobre usar energia demais” — só que embutido no preço final. O custo não some; ele dá a volta e volta para o consumidor.

É essa a lógica do lobby do “fair share/pedágio”: vender como “vamos cobrar de quem ‘usa muito’ a rede”, mas no fim vira mais um custo no caminho e com pouca concorrência e muito poder de barganha, quem fecha a conta é o usuário.

Outra analogia: A operadora oferece velocidade e limita a 100 Gb de tráfego ao mês. Oferece Deezer de graça e fora da franquia de download. Mas você opta por ter o spotify... Tudo bem, mas pagará mais caro na assinatura, porque o governo taxará o Spotify e a operadora cobrará pedágio dela (do spotify) porque, segundo eles, o Spotify usa muito a infraestrutura deles e há muitos usuários... O Spotify por sua vez, aumenta a assinatura para bancar estes custos.

Se a Anatel quer transformar “grande usuário” em justificativa para pedágio, monitoramento e diferenciação de tráfego: o risco é custo maior, mais coleta de dados e um mercado ainda mais fechado onde os grandes negociam, os pequenos só obedecem e o usuário paga uma conta maior.

Antes de sair escrevendo código, é fundamental entender os protocolos disponíveis no hardware. A YubiKey não é um pendrive de senhas é um HSM (Hardware Security Module) de bolso que expõe múltiplas interfaces:

Para o contexto de SRE/DevOps, os mais relevantes são: PIV, OpenPGP, HMAC-CR e FIDO2.
A chave privada nunca sai do chip, o app envia dados para a YubiKey processar; ela devolve o resultado. Isso é o que diferencia um HSM de um arquivo .pem no disco.

Shell Script / Bash

O shell não fala diretamente com a YubiKey, mas os utilitários de linha de comando da Yubico fazem isso muito bem. Para um SRE, isso é suficiente para 80% dos casos de uso.

Dependências:

# Arch
sudo pacman -S yubikey-manager ykpers libfido2 pcsc-tools opensc

# Fedora
sudo dnf install yubikey-manager ykpers libfido2 pcsc-lite opensc

# Verificar se a key está presente
ykman info

HMAC-SHA1 Challenge-Response para derivar chave de criptografia

O slot 2 da YubiKey pode ser configurado para HMAC-CR. Você envia um challenge (até 64 bytes), ela retorna um HMAC de 20 bytes. Isso vira a base de uma chave de criptografia.

encrypt:

#!/usr/bin/env bash
# yk-encrypt.sh — Criptografa arquivo usando YubiKey como fator de chave
set -euo pipefail

FILE="\({1:?Uso: \)0 <arquivo>}"
SLOT=2

# Gera challenge aleatório e salva junto ao arquivo cifrado
CHALLENGE=$(openssl rand -hex 32)
echo "[*] Enviando challenge para YubiKey (slot $SLOT)..."

# ykchalresp retorna o HMAC em hex
HMAC=\((ykchalresp -2 "\)CHALLENGE" 2>/dev/null) || {
    echo "[!] YubiKey não respondeu. Inserida e configurada?" >&2
    exit 1
}

# Deriva chave AES-256 via PBKDF2 (challenge + HMAC como material)
KEY=\((echo -n "\){CHALLENGE}${HMAC}" | openssl dgst -sha256 -binary | xxd -p -c 256)

# Cifra com AES-256-GCM
openssl enc -aes-256-cbc -pbkdf2 -iter 600000 \
    -k "$KEY" \
    -in "$FILE" \
    -out "${FILE}.yk.enc"

# Salva o challenge (sem o HMAC — sem a key física, não abre)
echo "\(CHALLENGE" > "\){FILE}.yk.challenge"

echo "[+] Arquivo cifrado: ${FILE}.yk.enc"
echo "[+] Challenge salvo: ${FILE}.yk.challenge"
echo "[!] Sem a YubiKey, o arquivo não pode ser decifrado."

E depois, decrypt:

#!/usr/bin/env bash
# yk-decrypt.sh
set -euo pipefail

ENC_FILE="\({1:?Uso: \)0 <arquivo.yk.enc>}"
CHALLENGE_FILE="${ENC_FILE%.enc}.challenge"
SLOT=2

CHALLENGE=\((cat "\)CHALLENGE_FILE")
echo "[*] Aguardando YubiKey..."
HMAC=\((ykchalresp -2 "\)CHALLENGE" 2>/dev/null) || { echo "[!] Falha na YubiKey" >&2; exit 1; }

KEY=\((echo -n "\){CHALLENGE}${HMAC}" | openssl dgst -sha256 -binary | xxd -p -c 256)

openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \
    -k "$KEY" \
    -in "$ENC_FILE" \
    -out "${ENC_FILE%.yk.enc}.decrypted"

echo "[+] Decifrado: ${ENC_FILE%.yk.enc}.decrypted"

SSH com YubiKey (PIV ou FIDO2)

# Gera chave FIDO2 residente na YubiKey para SSH
ssh-keygen -t ed25519-sk -O resident -O verify-required \
    -C "esli@infra-prod" -f ~/.ssh/id_ed25519_yk

# A chave privada fica no hardware. O arquivo local é só um "handle".
# Para usar em outro host sem o arquivo:
ssh-keygen -K  # exporta handles das chaves residentes

# Adiciona ao ssh-agent com confirmação de toque obrigatória
ssh-add -K ~/.ssh/id_ed25519_yk

GPG com YubiKey para criptografia de arquivos/secrets

# Verifica se a YubiKey está como cartão GPG
gpg --card-status

# Cifra arquivo para sua própria chave (que está na YubiKey)
gpg --encrypt --recipient esli@esli.blog.br segredo.txt

# Decifra — YubiKey faz a operação, exige PIN
gpg --decrypt segredo.txt.gpg > segredo.txt

# Uso prático: secrets em repositório Git
echo "DB_PASSWORD=hunter2" | gpg --encrypt -r esli@esli.blog.br --armor > .secrets.gpg
# No deploy:
gpg --decrypt .secrets.gpg | source /dev/stdin

Python

Python tem bindings maduros para praticamente tudo relacionado à YubiKey.

pip install yubikey-manager cryptography fido2
# yubikey-manager expõe a API do ykman como biblioteca

Go

Go é a linguagem de eleição para ferramentas de infraestrutura. O pacote piv-go da Google é o estado da arte para PIV.

go get github.com/go-piv/piv-go/piv
go get golang.org/x/crypto

Rust

Rust tem o ecossistema mais completo e seguro para trabalhar com YubiKey. O crate yubikey é mantido ativamente e cobre PIV completamente.

Dependências (cargo.toml):

[dependencies]
yubikey = { version = "0.8", features = ["untested"] }
age = "0.10"
aes-gcm = "0.10"
rand = "0.8"
sha2 = "0.10"
rsa = { version = "0.9", features = ["sha2"] }

age + YubiKey (a forma moderna)

O projeto age é o sucessor moderno do GPG para criptografia de arquivos. O plugin age-plugin-yubikey integra nativamente com PIV

cargo install age-plugin-yubikey

Aplicações reais da YubiKey no dia a dia de SRE/DevOps

No mundo real, YubiKey deixa de ser “mais um fator de autenticação” e vira um ponto de controle físico sobre ações críticas. Em ambientes de infraestrutura, isso muda completamente o modelo de ameaça: não basta comprometer credenciais — o atacante precisa também do dispositivo físico.

Um uso direto e frequente é na proteção de acessos privilegiados via SSH. Em vez de depender de chaves privadas armazenadas no filesystem (mesmo com permissões corretas), a autenticação passa a exigir presença física e interação do operador. Isso elimina uma classe inteira de ataques baseada em exfiltração de chave (ex: malware, backup comprometido, vazamento de home directory). Em ambientes com bastion hosts ou acesso a clusters Kubernetes sensíveis, isso reduz drasticamente o risco de movimento lateral silencioso.

Outro cenário recorrente é a proteção de secrets em pipelines e automações. Em vez de armazenar credenciais em texto claro ou mesmo em vaults mal configurados, a YubiKey pode ser utilizada como raiz de confiança para descriptografar dados apenas no momento da execução. Isso é particularmente útil em pipelines semi-manuais (deploys controlados, runbooks, operações de emergência), onde a presença humana já é esperada. Na prática, você cria um modelo onde o segredo só “existe” em memória durante alguns segundos e depende de um fator físico para ser acessado.

Em times que lidam com compliance (financeiro, saúde, governo), a YubiKey também entra como mecanismo de não repúdio operacional. Como cada dispositivo possui um identificador único, é possível atrelar ações críticas — como rotação de chaves, alteração de configuração em produção ou acesso a dados sensíveis — a um hardware específico. Isso permite auditoria mais forte: não apenas “qual usuário fez”, mas “qual dispositivo físico foi utilizado”. Em incidentes, isso reduz ambiguidades.

Para proteção de código e supply chain, o uso com GPG ou assinatura baseada em hardware garante que commit, tags e artefatos só possam ser assinados com presença física. Isso impede que um atacante que comprometeu um ambiente CI consiga forjar releases assinadas, um problema cada vez mais relevante em ataques à cadeia de suprimentos. O mesmo raciocínio se aplica a imagens de contêiner e pacotes distribuídos internamente.

Outro caso prático é o uso como fator de desbloqueio para ferramentas internas. Painéis administrativos, portais de SRE, ou até CLIs sensíveis podem exigir autenticação via FIDO2 antes de executar operações destrutivas (ex: “drain cluster”, “delete namespace”, “rotate CA”). Isso adiciona um “atrito intencional” exatamente onde ele deve existir: nas ações irreversíveis. Não é sobre dificultar o trabalho — é sobre impedir erros ou abusos silenciosos.

Em ambientes distribuídos ou com acesso remoto, a YubiKey também atua como mitigação contra comprometimento de sessão. Mesmo que uma máquina seja invadida ou um terminal esteja aberto, a ausência do dispositivo físico impede novas autenticações e operações críticas. Isso limita o impacto de ataques e força o adversário a agir dentro de uma janela muito mais restrita.

Por fim, há o uso como âncora de identidade pessoal no ecossistema técnico. A mesma YubiKey pode ser utilizada para login em serviços, assinatura de código, acesso SSH e descriptografia de dados. Isso consolida identidade, reduz superfície de ataque e simplifica o modelo mental: em vez de dezenas de segredos distribuídos, você tem um único ponto de controle forte — que, convenientemente, não pode ser copiado.

Referência Rápida: Qual Protocolo Usar?

Considerações Finais

A YubiKey não é bala de prata, é uma camada de segurança física que complementa boas práticas. Alguns pontos que o SRE pragmático precisa ter em mente:

Backup: Sempre tenha uma segunda YubiKey configurada. Perder a única key é uma experiência formativa que você não quer ter.

PIN vs Touch: Configure touch-policy=always para operações críticas. O toque físico é o que diferencia a YubiKey de um arquivo de chave no disco.

Forwarding remoto: Para servidores remotos, usbip permite forwarding de USB via rede. Alternativa: use o SSH agent forwarding com ssh-agent + FIDO2.

Auditoria: O serial da YubiKey é único e pode ser utilizado como identificador de operador em logs de auditoria.

Revogação: Tenha um processo documentado para revogar e substituir chaves quando uma YubiKey for perdida ou comprometida.

A premissa é simples: o que está no hardware não pode ser exfiltrado por malware. Um atacante que comprometeu sua máquina pode roubar sua sessão ativa, mas não pode abrir uma nova conexão SSH, decifrar novos arquivos ou assinar novos commits sem o token físico. Isso reduz drasticamente a janela de exposição.

Referências:

• Yubico Developers

• piv-go (Google)

• rust-yubikey (Fortanix)

• age-plugin-yubikey

• yubikey-manager (Python)

• libfido2

Recentemente, o Waterfox anunciou uma mudança estrutural que merece nossa atenção técnica: a integração do motor de bloqueio de anúncios do Brave, o projeto open source adblock-rust.

Esta decisão, detalhada no anúncio de 15 anos do blog oficial do Waterfox é uma escolha de engenharia que envolve performance, segurança de memória com Rust e a complexa economia de manter um browser independente hoje.

O Anúncio: Tradução e Contexto

No post oficial, Alex Kontos (criador do Waterfox) confirmou que o navegador entregará ainda este ano um bloqueador de conteúdo nativo. A escolha pelo motor do Brave foi pautada em três pilares:

1. Maturidade Técnica: O motor já processa bilhões de requisições diariamente nos milhões de instalações do Brave.

2. Manutenção Profissional: Uma equipe dedicada mantém as regras de parsing e segurança atualizadas.

3. Licenciamento: O adblock-rust usa a licença MPL-2.0, compatível com a base de código do Waterfox. Isso evita os conflitos de licença (como a GPLv3 do uBlock Origin) que dificultariam uma integração profunda diretamente no "core" do executável.

Nota importante sobre monetização: O Waterfox manterá a exibição de anúncios de texto apenas em seu parceiro de busca (Startpage) por questões de sustentabilidade financeira. É crucial notar que esta é uma configuração do Waterfox e não uma limitação do motor do Brave.

Mergulho Técnico: O que é o adblock-rust?

Desenvolvido pelo Brave, o adblock-rust é uma biblioteca de alto desempenho projetada para ser embutida. Ao contrário de extensões que rodam em camadas superiores, este motor permite:

• Bloqueio ao nível de rede: Interceptação de requisições antes mesmo do processamento pesado.

• Filtros Cosméticos e Injeção de Scripts: Limpeza do DOM para remover espaços vazios de anúncios.

• Suporte a Sintaxe de Redes Sociais: Compatibilidade com listas famosas (EasyList, uBlock, etc.).

• Segurança de Memória: Sendo escrito em Rust, ele elimina classes inteiras de bugs de memória que costumam afligir motores escritos em C++.

Por que Rust?

A escolha da linguagem Rust para este componente não é moda. No contexto de um navegador, o motor de adblock precisa processar milhares de strings e regras de regex em milissegundos. Rust oferece a performance do "metal" (C/C++) com a garantia de que não ter buffer overflows ou vazamentos de memória críticos durante o parsing de listas de filtros malformadas.

Conheça os Projetos

Waterfox: A Resistência do Gecko

O Waterfox é um dos forks mais antigos e respeitados do ecossistema Firefox. Focado em usuários avançados, ele remove telemetria agressiva, experimentos desnecessários da Mozilla e foca na "vibe" original do browser como ferramenta de produtividade, não como hub de anúncios.

Brave: Inovação em Adblocking

O Brave revolucionou ao trazer o bloqueio de anúncios para o centro do binário do navegador. Seu motor em Rust agora se torna uma tecnologia "standard" que beneficia outros players menores, fortalecendo o ecossistema de browsers baseados em privacidade.

Minha Visão Técnica: O Futuro dos Browsers

Vejo esse movimento como um sinal de amadurecimento do software livre. Navegadores independentes como o Waterfox enfrentam pressões gigantescas (técnicas e financeiras). Em vez de tentar "reinventar a roda" criando um adblocker do zero, Alex Kontos optou por integrar o que há de melhor no mercado via código aberto.

Olhando projetos como o Laybird Browser e o Orion Browser... ambos não são forks de Chrome ou Firefox, Ladybird ainda não teve um stable release e o último (Orion) aceita extensões tanto da Chrome Store quanto do Firefox. Mullvad Browser entrega o nível máximo de segurança sem a rede Tor, que por sua vez está embutida tanto no Brave quanto no Tor Browser.

Cada um acima oferece características únicas, mas o restante não deveria ocupar o tempo dos desenvolvedores reinventando a roda ou criando forks/ports de projetos já maduros.

Integrar o bloqueador dentro do processo principal reduz a latência e o overhead de memória que costumamos ver em extensões WebExtension. Para o usuário final, isso significa uma navegação mais fluida e um navegador que "pesa menos" no sistema, e o adblock-rs do Brave implementa da melhor forma.

A web está mudando, e o Waterfox, ao se aliar tecnicamente ao motor do Brave e à robustez do Rust, garante que continuará sendo uma opção viável para quem não quer ser apenas mais um dado estatístico no Chrome ou no Safari.

Quando um navegador como o Waterfox decide incorporar o adblock-rust do Brave, o que vemos não é apenas uma melhoria de recurso. Vemos um retrato bastante honesto do estado atual da web:

• navegadores independentes estão pressionados financeiramente;

• extensões já não são resposta suficiente para tudo;

• Rust se consolida como linguagem para componentes críticos;

• o open source continua sendo a infraestrutura invisível que permite inovação real.

O anúncio do Waterfox é, ao mesmo tempo, uma boa notícia técnica e um lembrete político. A web aberta ainda depende de projetos independentes, mas manter esses projetos vivos continua sendo um problema tão difícil quanto escrever e manter um bom código.

Fontes

• Waterfox Blog — 15 Years of Forking

• Brave — adblock-rust no GitHub

• Waterfox — site oficial

• CyberInsider — repercussão da notícia

O protocolo NTP (Network Time Protocol) foi projetado nos anos 1980. Funciona sobre UDP, na porta 123, sem criptografia e sem autenticação. Seu sistema operacional confia cegamente na resposta de um servidor NTP para sincronizar o relógio. E essa confiança cega é explorável.

Se você leu os artigos sobre DNSCrypt, sobre não confiar no seu provedor de internet e sobre o vazamento via SNI, já percebeu o padrão: protocolos antigos que nunca foram projetados com segurança em mente continuam sendo a fundação da internet moderna. O NTP é mais um deles.

A hora correta é dependência direta de:

Certificados TLS/SSL. Cada certificado tem campos Not Before e Not After. Se o relógio do cliente estiver fora dessa janela, o certificado é rejeitado (ou aceito indevidamente se o relógio for manipulado para um período em que um certificado revogado ainda era válido).

Kerberos. O protocolo Kerberos, usado em autenticação corporativa e Active Directory, tem tolerância padrão de 5 minutos. Shift de tempo superior a isso invalida tickets e impede autenticação.

DNSSEC. Assinaturas DNSSEC têm validade temporal. Um atacante que empurra o relógio de um resolver DNS para frente faz todas as assinaturas DNSSEC expirarem, causando falha na validação e perda de resolução DNS para domínios protegidos.

TOTP/2FA. Tokens temporais (Google Authenticator, Authy, etc.) dependem de sincronização de tempo. Relógio deslocado significa código errado, que significa login negado.

Logs forenses. Correlação de eventos entre sistemas depende de timestamps confiáveis. Sem isso, investigação de incidentes e compliance viram exercício de ficção.

RPKI e BGP. Route Origin Authorizations têm manifests com timestamp. Manipulação de tempo pode fazer um relying party aceitar manifests expirados ou rejeitar válidos, afetando roteamento BGP inteiro.

Cron jobs e schedulers. Tarefas agendadas executam baseadas no relógio do sistema. Um shift de tempo pode disparar jobs prematuramente, atrasá-los, ou causar loops de execução.

Os ataques

Pesquisadores da Boston University publicaram em 2015/2016 o paper "Attacking the Network Time Protocol", documentando ataques práticos contra o NTP. Não são teóricos e foram demonstrados em laboratório e alguns explorados "in the wild".

On-path: time-shifting

Um atacante posicionado entre o cliente e o servidor NTP (ISP, rede corporativa, Wi-Fi público) pode modificar as respostas NTP.

O NTP padrão (ntpd) aceita ajustes de até 1000 segundos (panic threshold) sem questionar. E na inicialização, com a flag -g (padrão em muitas distros Linux), aceita qualquer shift, incluindo anos para frente ou para trás.

O ataque "small-step-big-step" funciona assim: o atacante envia shifts pequenos (abaixo do threshold de detecção) durante operação normal. Quando o cliente reinicia, um shift grande é aceito porque o -g permite qualquer correção na inicialização. Resultado: o relógio é deslocado horas ou anos sem gerar alerta.

Off-path: Kiss-o'-Death (KoD)

O NTP tem um mecanismo de rate-limiting chamado Kiss-o'-Death (KoD). Quando um cliente envia queries demais, o servidor responde com um pacote KoD mandando o cliente parar.

O problema: em versões anteriores ao ntpd 4.2.8p4, um atacante off-path (sem estar na rota do tráfego) podia spoofar pacotes KoD de cada servidor configurado no cliente.

Resultado: o cliente para de sincronizar e o relógio começa a derivar. Com uma máquina e um scanner de rede, era possível desabilitar NTP em massa pela internet.

Amplificação DDoS

O comando monlist do NTP responde com até 600 entradas de clientes recentes. Uma requisição de ~40 bytes gera respostas de ~22KB, fator de amplificação de 556x. Esse ataque foi usado em DDoS massivos em 2014.

O monlist foi desativado em versões recentes, mas servidores NTP antigos e mal configurados continuam disponíveis.

Cenário prático: forçar aceitação de certificado revogado

O atacante manipula o NTP para empurrar o relógio do cliente para trás, para um período em que um certificado (já revogado) ainda era válido. O navegador ou aplicação aceita o certificado como legítimo. O atacante faz MITM com o certificado comprometido. A vítima não vê aviso nenhum.

Variante: empurrar o relógio para frente, forçando expiração de certificados DNSSEC. O resolver DNS passa a falhar na validação e o atacante pode então servir respostas DNS falsas sem o DNSSEC bloquear.

NTS: a solução

NTS (Network Time Security) é a resposta, padronizado pela RFC 8915 (setembro de 2020). Ele adiciona autenticação criptográfica ao NTP sem alterar o protocolo de medição de tempo em si.

Como funciona

O NTS opera em duas fases:

Fase 1: NTS-KE (Key Establishment). O cliente abre uma conexão TLS (porta TCP 4460) com o servidor NTS. Através desse canal criptografado, cliente e servidor negociam parâmetros de criptografia e o servidor emite cookies (opacos para o cliente). Essa etapa usa TLS 1.3 padrão com verificação de certificado.

Fase 2: NTP autenticado. As queries NTP subsequentes (UDP 123, como sempre) incluem extensões criptográficas. Cada pacote carrega um cookie e um campo de autenticação (AEAD, geralmente AES-SIV-CMAC-256). O servidor valida o cookie e a autenticação antes de responder. Um pacote NTP adulterado em trânsito falha na verificação e é descartado.

O ponto importante: o NTS não adiciona latência à medição de tempo. O handshake TLS (NTS-KE) ocorre na inicialização e depois aproximadamente uma vez por hora para renovação de cookies. As queries NTP regulares continuam sendo UDP com overhead mínimo (os campos de autenticação).

O servidor não mantém estado por cliente. Os cookies são auto-contidos (criptografados com a chave do servidor). Isso permite escalar para milhões de clientes sem overhead de memória.

Cenário atual: quem suporta NTS

Em 2026, existem entre 60 e 70 servidores NTS públicos no mundo. A Europa concentra a maioria, com a Netnod (Suécia) operando 12+ servidores e o PTB (Alemanha) com 4 servidores. A Cloudflare oferece NTS via anycast global. Não existe pool NTS (tipo pool.ntp.org) por causa da dependência de certificados TLS individuais por servidor. Um projeto financiado pelo ICANN (2025-2027), executado pela Trifecta Tech Foundation, trabalha numa solução de pooling para NTS.

Clientes que suportam NTS

O chrony é a escolha óbvia para Linux. Já é padrão na maioria das distros que importam (Fedora, RHEL, Arch, SUSE) e o Ubuntu 25.10 adotou chrony com NTS habilitado por padrão em novas instalações.

Servidores NTS públicos confiáveis

A lista completa e atualizada é mantida em https://github.com/jauderho/nts-servers

Sobre a escolha de servidores: é recomendável usar pelo menos 5 servidores NTS diferentes. Isso protege contra (n-1)/2 falsetickers (servidores que reportam hora incorreta). O chrony aplica algoritmos de consenso entre as fontes para descartar outliers.

Para o Brasil, time.cloudflare.com é a melhor opção de latência por utilizar anycast.

Os servidores europeus (Netnod, PTB) adicionam ~150-200ms de RTT, mas para sincronização NTP isso é perfeitamente aceitável. Não existe servidor NTS público operando na América do Sul no momento. Se você tem infraestrutura e quer contribuir, o repo do jauderho aceita PRs.

Configuração no Linux

Arch / EndeavourOS / Omarchy

Chrony já vem com suporte NTS compilado. No Arch é o pacote padrão para sincronização de tempo.

sudo pacman -S chrony

Edite /etc/chrony.conf:

# Servidores NTS
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
server ptbtime1.ptb.de iburst nts
server ptbtime2.ptb.de iburst nts
server ntppool1.time.nl iburst nts

# Persistir cookies NTS entre reinícios
ntsdumpdir /var/lib/chrony

# Drift file
driftfile /var/lib/chrony/chrony.drift

# Correção rápida na inicialização (max 1s de offset, 3 primeiros updates)
makestep 1.0 3

# Sincronizar RTC
rtcsync

# Log
logdir /var/log/chrony

Ative e inicie:

sudo systemctl enable --now chronyd

Desabilite o systemd-timesyncd (se estiver ativo), senão haverá conflito:

sudo systemctl disable --now systemd-timesyncd

Fedora

Chrony já é o padrão. O NTS não é habilitado por padrão, mas a habilitação é trivial:

sudo dnf install chrony  # provavelmente já instalado

Edite /etc/chrony.conf. Comente os pools padrão e adicione servidores NTS:

# Comentar pools padrão (NTP sem autenticação)
# pool 2.fedora.pool.ntp.org iburst

# Servidores NTS
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
server ptbtime1.ptb.de iburst nts
server ptbtime3.ptb.de iburst nts
server ntppool2.time.nl iburst nts

# Persistir cookies NTS
ntsdumpdir /var/lib/chrony

driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony

# Desabilitar NTP servers recebidos via DHCP
# (o ISP não deve ditar seu servidor de tempo)

Se o DHCP do seu provedor injeta servidores NTP (sim, isso acontece), remova ou comente a linha:

# sourcedir /run/chrony-dhcp

Restart:

sudo systemctl restart chronyd

Debian / Ubuntu (pré-25.10)

Ubuntu anteriores ao 25.10 usam systemd-timesyncd, que não suporta NTS. A migração:

sudo apt install chrony
sudo systemctl disable --now systemd-timesyncd
sudo systemctl enable --now chronyd

Edite /etc/chrony/chrony.conf com a mesma configuração de servidores NTS acima. Em Debian, o path da config pode ser /etc/chrony/chrony.conf ou /etc/chrony.conf dependendo da versão.

Ubuntu 25.10+ já vem com chrony + NTS habilitado por padrão em instalações novas. Em upgrades, a migração é manual.

Validação

Após configurar, verifique que NTS está funcionando:

Verificar fontes de tempo

chronyc -N sources

Saída esperada (o * indica a fonte selecionada como referência):

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================
^+ time.cloudflare.com           3   6    17     4  -1643us[-6247us] +/-   70ms
^- nts.netnod.se                 1   6    17     3    +17ms[  +17ms] +/-  148ms
^* ptbtime1.ptb.de               1   6    17     3  -2576us[-7179us] +/-  112ms
^+ ptbtime2.ptb.de               1   6    17     4  +1837us[-2767us] +/-  118ms
^+ ntppool1.time.nl              1   6    17     4  +5908us[+1304us] +/-  101ms

Reach deve ser 377 (octal, significa 8 consultas consecutivas bem-sucedidas). Se for 0, o servidor não está respondendo.

Verificar autenticação NTS

sudo chronyc -N authdata

Saída esperada:

Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
===============================================================
time.cloudflare.com          NTS     1   30  128  141    0    0    8   64
nts.netnod.se                NTS     1   15  256  140    0    0    8  100
ptbtime1.ptb.de              NTS     1   15  256  140    0    0    8  100
ptbtime2.ptb.de              NTS     1   15  256  140    0    0    8  100
ntppool1.time.nl             NTS     1   30  128  141    0    0    8   64

O que verificar:

• Mode deve ser NTS (não NTP)

• KeyID, Type, KLen devem ser valores diferentes de zero

• NAK deve ser 0 (zero falhas de autenticação)

• Cook indica cookies disponíveis (8 é o padrão completo)

• Type 15 = AEAD-AES-SIV-CMAC-256, o algoritmo padrão

Se algum servidor mostrar Mode: NTP em vez de NTS, o handshake NTS-KE falhou. Causas comuns: firewall bloqueando porta TCP 4460 (NTS-KE), DNS não resolvendo o hostname, ou certificado TLS expirado no servidor.

Verificar status geral

chronyc tracking

Mostra stratum, offset atual, frequência de correção e status do leap second. Um sistema bem sincronizado terá offset na faixa de microsegundos.

Reference ID    : CFC5577C (time.cloudflare.com)
Stratum         : 4
Ref time (UTC)  : Wed Apr 01 19:15:42 2026
System time     : 0.000761374 seconds slow of NTP time
Last offset     : -0.001684829 seconds
RMS offset      : 0.004399488 seconds
Frequency       : 29.567 ppm slow
Residual freq   : -0.000 ppm
Skew            : 176.681 ppm
Root delay      : 0.138503209 seconds
Root dispersion : 0.006709417 seconds
Update interval : 63.1 seconds
Leap status     : Normal

Considerações de firewall

O NTS precisa de duas portas abertas para saída:

• UDP 123 (NTP): queries de tempo padrão

• TCP 4460 (NTS-KE): handshake TLS para troca de chaves

Se você opera em rede corporativa ou com firewall egress restritivo, a porta 4460 pode estar bloqueada.

Alguns ISPs também bloqueiam ou fazem rate-limit em pacotes NTP maiores (que incluem as extensões NTS), confundindo-os com tentativas de amplificação.

Se o NTS-KE falhar, o chrony por padrão não sincroniza com aquela fonte (comportamento seguro: melhor não sincronizar do que sincronizar sem autenticação).

Boards ARM sem RTC

Se você roda chrony em Raspberry Pi ou outros ARM boards sem RTC (Real-Time Clock), há um problema: na inicialização, o relógio do sistema pode estar tão deslocado que o certificado TLS do servidor NTS é rejeitado (porque o sistema acha que estamos em 1970 ou alguma data absurda).

Solução: adicione à configuração:

nocerttimecheck 1

Isso permite que a primeira verificação de certificado ignore a validade temporal. Depois que o relógio sincroniza, as verificações subsequentes funcionam normalmente. Existe impacto de segurança (um certificado expirado seria aceito no primeiro boot), mas é um trade-off aceitável para hardware sem RTC.

ntpd-rs: a alternativa em Rust

Para quem prefere software com foco em segurança de memória, o ntpd-rs é um cliente e servidor NTP escrito em Rust, financiado pela ISRG (a mesma organização por trás do Let's Encrypt) através do projeto Prossimo. Suporta NTS nativamente.

Configuração básica em /etc/ntpd-rs/ntp.toml:

[observability]
log-level = "warn"

[[source]]
mode = "nts"
address = "time.cloudflare.com"

[[source]]
mode = "nts"
address = "nts.netnod.se"

[[source]]
mode = "nts"
address = "ptbtime1.ptb.de"

[synchronization]
single-step-panic-threshold = 1800
startup-step-panic-threshold = { forward = "inf", backward = "inf" }

O ntpd-rs está disponível em algumas distros mas é menos maduro que o chrony. Para produção, chrony continua sendo a referência. Mas vale acompanhar o ntpd-rs, especialmente se segurança de memória é prioridade na sua stack.

Conclusão

NTP sem autenticação é mais uma herança dos anos 80 que nunca deveria ter chegado a 2026 sem correção. Mas aqui estamos. A boa notícia é que a correção existe (NTS), é padronizada (RFC 8915), está implementada nos clientes principais (chrony) e disponível em servidores públicos confiáveis.

A configuração leva 5 minutos. Menos que o tempo que você gastou lendo este artigo.

Se você seguiu a série até aqui, sua pilha de proteção agora cobre DNS (DNSCrypt/DoH/DoT), handshake TLS (ECH) e sincronização de tempo (NTS). Três protocolos que o seu ISP usava como janela de observação, agora fechados.

O próximo passo natural é olhar para o que sai da sua máquina sem você saber. Auditoria de tráfego egress com opensnitch, ss e tcpdump. Mas isso fica para o próximo artigo.

Referências e leitura complementar:

• RFC 8915 - Network Time Security for the Network Time Protocol: https://datatracker.ietf.org/doc/html/rfc8915

• Attacking the Network Time Protocol (BU, 2015): https://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf

• Lista de servidores NTS: https://github.com/jauderho/nts-servers

• chrony NTS (ArchWiki): https://wiki.archlinux.org/title/Chrony

• Red Hat - NTS in chrony: https://docs.redhat.com/en/documentation/red\_hat\_enterprise\_linux/10/html/configuring\_time\_synchronization/overview-of-network-time-security-nts-in-chrony

• Fedora NTS: https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity

• Cloudflare Time Services: https://developers.cloudflare.com/time-services/nts/

• ntpd-rs (Prossimo/ISRG): https://github.com/pendulum-project/ntpd-rs

• NTP Tester (verificação NTS): https://www.ntp-tester.eu/nts.html

• Série DNSCrypt: https://esli.blog.br/dnscrypt-proxy

• Não confie no seu provedor: https://esli.blog.br/nao-confie-no-seu-provedor-de-internet

• SNI Leak e ECH: https://esli.blog.br/sni-leak-ech

Bem-vindo ao problema do SNI.

Se você acompanhou a série sobre DNSCrypt e o artigo sobre por que não confiar no seu provedor de internet, já sabe que criptografar as consultas DNS é o primeiro passo para recuperar privacidade na rede. Mas DNS é só metade da equação: outra metade acontece no TLS handshake, e é ali que mora o vazamento que quase ninguém discute.

O que é o SNI e por que ele existe

SNI significa Server Name Indication. É um campo enviado pelo cliente (seu navegador) no início de uma conexão TLS, antes de qualquer criptografia do conteúdo.

O motivo é prático: quando múltiplos sites compartilham o mesmo IP (o que é extremamente comum em hospedagens compartilhadas, CDNs e plataformas cloud), o servidor precisa saber qual certificado TLS apresentar. O cliente informa isso enviando o hostname de destino no ClientHello, a primeira mensagem do handshake TLS. Em texto claro.

Isso significa que qualquer entidade posicionada entre você e o servidor de destino (ISP, operador de rede corporativa, governo, Wi-Fi do aeroporto) consegue ler o campo SNI e saber exatamente qual domínio você está acessando.

Resumindo: HTTPS protege o conteúdo. O SNI entrega o destino.

O que o atacante vê (e o que ele faz com isso)

Com acesso ao SNI, um observador de rede consegue:

Construir um perfil completo de navegação. Mesmo sem ver o conteúdo das páginas, saber que alguém acessou consultamedica.com.br, vagas.com e advogadotrabalhista.com.br no mesmo dia já conta uma história.

Bloquear sites seletivamente. A Coreia do Sul fez exatamente isso em 2019: depois que os usuários começaram a contornar bloqueios DNS, o governo instruiu os ISPs a inspecionar o campo SNI nos handshakes TLS para derrubar conexões a domínios proibidos. O DNS criptografado virou inútil. O SNI era o novo ponto de controle.

Censurar sem quebrar criptografia. O ISP não precisa decifrar o tráfego HTTPS. Basta ler o SNI, comparar com uma lista e dropar o pacote SYN ou enviar um RST. É trivial de implementar em DPI (Deep Packet Inspection) e invisível para quem não está monitorando.

Correlacionar tráfego com identidade. Combinando SNI com IP de origem e timestamps, é possível vincular padrões de acesso a um assinante específico. Isso é feito sistematicamente em regimes autoritários e, como demonstramos no artigo anterior, por ISPs em democracias que retêm logs por obrigação legal.

O DNS cifrado resolve a pergunta "para qual IP este domínio aponta?". O SNI vaza a resposta: "qual domínio estou visitando?". São dois canais de metadados diferentes. Proteger um e ignorar o outro é como trancar a porta da frente e deixar a janela aberta.

A evolução: do ESNI ao ECH

A comunidade técnica não ignorou o problema. A primeira tentativa de solução foi o ESNI (Encrypted Server Name Indication), proposto em 2018 como extensão experimental do TLS 1.3. A ideia era simples: criptografar o campo SNI usando uma chave pública disponível via DNS.

O ESNI funcionou como prova de conceito, mas tinha limitações práticas. A criptografia era aplicada somente ao SNI, deixando outros campos do ClientHello (como ALPN, lista de cipher suites, e extensões) ainda visíveis. Isso permitia que observadores inferissem informações do destino mesmo sem o SNI explícito. O ESNI também dependia de registros DNS TXT específicos, o que tornava a distribuição de chaves frágil e difícil de escalar.

A resposta foi o ECH (Encrypted Client Hello), que substituiu o ESNI e está em processo de padronização final no IETF (draft 25 no momento desta publicação). A diferença fundamental: em vez de criptografar apenas o SNI, o ECH criptografa o ClientHello inteiro.

Como o ECH funciona

O mecanismo do ECH divide o ClientHello em duas partes:

Outer ClientHello (público): Contém informações genéricas como versão do TLS, cipher suites e um SNI genérico. No caso do Cloudflare, todas as conexões ECH mostram cloudflare-ech.com como SNI externo. O observador de rede vê apenas que você está acessando "algo no Cloudflare", junto com milhões de outros usuários.

Inner ClientHello (cifrado): Contém o SNI real, as extensões sensíveis e todas as informações que antes eram enviadas em texto claro. Esse bloco é criptografado usando uma chave pública (ECHConfig) que o navegador obtém via registro HTTPS/SVCB no DNS.

Para o ISP ou qualquer intermediário, a conexão TLS parece ser para cloudflare-ech.com. O destino real só é revelado dentro do túnel criptografado, acessível apenas pelo servidor de destino (ou pela CDN que o hospeda).

Pense assim: sem ECH, é como enviar uma carta com o nome do destinatário escrito no envelope. Com ECH, o envelope mostra "Cloudflare" e o nome real está dentro, lacrado.

Dependência do DNS criptografado

Aqui está o ponto que liga tudo: o ECH depende de registros DNS para funcionar. O navegador precisa buscar o registro HTTPS/SVCB do domínio para obter a ECHConfig (a chave pública de criptografia). Se essa consulta DNS for feita em texto claro, um atacante pode simplesmente remover ou modificar o registro para impedir o ECH.

Sem DoH, DoT ou DNSCrypt, o ECH pode ser sabotado antes de começar.

É por isso que a série sobre DNSCrypt não é "só sobre DNS". Ela é a fundação para que o ECH funcione. Um não substitui o outro. Eles se complementam.

A cadeia completa para privacidade real é:

1. DNS criptografado (DNSCrypt, DoH, DoT) impede que o ISP saiba quais domínios você resolve

2. ECH impede que o ISP saiba quais domínios você acessa via TLS

3. HTTPS impede que o ISP leia o conteúdo da comunicação

Remova qualquer uma dessas camadas e a proteção degrada. As três juntas eliminam os metadados de navegação visíveis para observadores de rede.

Suporte atual: quem já implementou

Navegadores

O Firefox foi o primeiro a ativar ECH por padrão, e exige que o DoH esteja habilitado para que o ECH funcione (o que faz sentido técnico). O Chrome e derivados fazem rollout progressivo.

Servidores/CDNs

O Cloudflare é o principal motor de adoção do ECH no lado servidor. Ativou ECH em todos os planos, incluindo o gratuito (onde não pode ser desabilitado). Isso é relevante porque uma parte significativa dos sites da internet usa Cloudflare como CDN/proxy reverso.

Dados de 2026: aproximadamente 4,2% dos top 100K sites e 9,2% do top 1M suportam ECH. Parece pouco, mas considerando que o Cloudflare sozinho cobre uma fatia enorme do tráfego web, o impacto prático é maior do que os números sugerem.

Outros CDNs e provedores de hospedagem ainda estão avaliando. Sem suporte do servidor, o ECH simplesmente não é negociado e a conexão cai no comportamento antigo (SNI em texto claro).

Como verificar e configurar no Linux

Firefox

O ECH já está habilitado por padrão no Firefox 119+.

Para confirmar:

1. Acesse about:config

2. Busque network.dns.echconfig.enabled → deve estar true

3. Busque network.dns.http3_echconfig.enabled → deve estar true

O ECH no Firefox depende do DoH estar ativo. Verifique em: Configurações → Privacidade e Segurança → DNS sobre HTTPS

Ative com Proteção Máxima e selecione um provedor (Cloudflare, NextDNS ou customizado).

Chromium/Brave/Edge

No Chrome e derivados, o ECH era controlado pela flag até a versão 117

chrome://flags/#encrypted-client-hello

Atualmente, se o DoH está ativo e o servidor suporta ECH, o Chrome negocia automaticamente e não existe a opção de ser desativado.

Novamente, assim como no Firefox, o ECH depende de Secure DNS estar ativo. Verifique em: Configurações → Privacidade e segurança → Segurança → Usar DNS seguro

Checando sites com comando dig

dig HTTPS crypto.cloudflare.com +short

Se retornar campo com ech=, o site suporta ECH.

A presença de ECHConfig no registro DNS tipo HTTPS é condição necessária e suficiente para afirmar que o site suporta ECH. O browser negocia se quiser - mas o suporte é do servidor.

Validação

Para verificar se o ECH está funcionando na sua conexão:

1. Acesse https://crypto.cloudflare.com/cdn-cgi/trace e procure o campo sni=encrypted

2. Acesse https://defo.ie/ech-check.php para um teste mais detalhado

O que o ECH não resolve

O ECH criptografa o ClientHello, isso é significativo mas não é o fim da história.

IP de destino. O ECH esconde o domínio, não o IP. Se um servidor hospeda um único site, o IP já revela o destino. O ECH é mais eficaz quando muitos sites compartilham a mesma infraestrutura (como em CDNs).

Análise de tráfego. O volume de dados, padrões de acesso e timing ainda são observáveis. Técnicas de traffic fingerprinting podem inferir o site visitado mesmo sem SNI.

DNS não criptografado. Se o DNS vazar o domínio antes do ECH atuar, a proteção é nula. O ECH precisa de DoH/DoT/DNSCrypt para funcionar como planejado.

Servidores sem suporte. Se o site que você acessa não suporta ECH, o SNI continua em texto claro. A proteção depende da adoção do lado servidor.

Para uma cobertura mais completa, combine ECH com VPN. Conforme discutido no artigo sobre qual a melhor VPN, uma VPN oculta o IP de destino e encapsula todo o tráfego, enquanto o ECH protege os metadados TLS. VPN + ECH + DNS criptografado é a combinação mais robusta disponível hoje sem utilizar o Tor.

ECH como ferramenta de ataque

Vale registrar o outro lado: o ECH também é útil para atacantes. Em 2024, pesquisadores da NTT Security Holdings identificaram um malware (batizado de ECHidna) que usava ECH para esconder comunicação com servidores de comando e controle (C2). O tráfego malicioso se passava por conexões legítimas a infraestrutura CDN, tornando a detecção por firewalls tradicionais ineficaz.

Isso não é argumento contra o ECH, ao contrário: mostra que a tecnologia e a criptografia funcionam, o que muda é a intenção de uso.

Escondendo SNI do seu provedor e de atacantes

zapret e SpoofDPI são ferramentas que operam na camada de rede para impedir que sistemas de Deep Packet Inspection (DPI) consigam ler o campo SNI no ClientHello do TLS.

No Linux, o zapret usa nfqueue (via iptables/nftables) para interceptar pacotes de saída antes de deixarem a máquina — ao capturar o ClientHello, ele aplica técnicas como fragmentação TCP (split2), manipulação de TTL e inserção de pacotes falsos (fake), fazendo com que o DPI do ISP receba os fragmentos fora de ordem ou com dados inválidos enquanto o servidor de destino remonta corretamente.

Já o SpoofDPI atua como proxy HTTP/HTTPS local: o navegador conecta nele, e ele estabelece a conexão real com o destino fragmentando o primeiro pacote TLS no nível da aplicação — mais simples de configurar (basta apontar o proxy do browser para 127.0.0.1:8080), porém menos flexível que o zapret. Ambos não criptografam nem removem o SNI — apenas tornam a inspeção passiva inviável ao quebrar as heurísticas dos equipamentos de DPI.

No Android, as principais opções são o InviZible Pro, ByeDPI Android e DPI Tunnel — todos funcionam sem root criando uma VPN local no dispositivo que intercepta o tráfego de saída e aplica técnicas de fragmentação/dessincronização no ClientHello TLS antes que ele chegue ao ISP, impedindo que o DPI passivo consiga ler o SNI.

O InviZible Pro é o mais completo, integrando DNSCrypt, Tor e módulos anti-DPI em um único app (com root, ele injeta regras iptables diretas, dispensando a VPN local e evitando conflitos). Possui opção para falsificar o SNI.

O ByeDPI Android é o mais simples e focado: instala, escolhe o método de desync (split/disorder) e ativa — sem configuração extra. Assim como no Linux, nenhum deles criptografa ou remove o SNI, apenas fragmentam o pacote TCP para que equipamentos de inspeção passiva não consigam remontar e ler o campo em tempo real.

Conclusão: o elo que faltava

Na prática, do lado do usuário final, o ECH é quase inteiramente dependente do navegador e do servidor (qualquer fork do Chrome/Chromium atualizado, e qualquer Firefox desde que validado o true nas configs).
O que o usuário controla é diretamente limitado, mas já está no artigo:

• Habilitar DoH/DoT/DNSCrypt (pré-requisito para ECH funcionar);

• Validar que ECH está ativo no browser (about:config, flags, testes online);

• Desabilitar WebRTC. Não é SNI diretamente, mas WebRTC vaza IP real mesmo com VPN/ECH, o que permite correlação e é um complemento lógico;

O ECH é a peça que conecta a série de proteções que temos construído aqui no blog. DNSCrypt protege a resolução de nomes, HTTPS protege o conteúdo e o ECH protege o handshake.

Sem ECH, o SNI é o último canal de metadados aberto para observadores de rede. Com ECH, esse canal fecha. O ISP deixa de saber qual site você visita, não apenas o que você faz dentro dele.

A adoção ainda está em progresso. Mas o suporte nos navegadores já é universal, o Cloudflare empurra a adoção no lado servidor, e distribuições Linux como Ubuntu e Fedora facilitam a configuração de DoH/DoT como requisito base.

Se você já configurou DNSCrypt seguindo a série anterior, validar que o ECH está habilitado no navegador é questão de segundos.

Referências e leitura complementar:

• RFC 8744 - Issues and Requirements for SNI Encryption in TLS

• IETF Draft ECH: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

• Cloudflare ECH: https://blog.cloudflare.com/announcing-encrypted-client-hello/

• CDT - Encrypted Client Hello: Closing the SNI Metadata Gap

• Cisco ECH Defense Strategies (análise do lado corporativo/firewall)

• https://defo.ie/ech-check.php (verificador ECH)

• https://crypto.cloudflare.com/cdn-cgi/trace (verificador Cloudflare)

• Série DNSCrypt: https://esli.blog.br/dnscrypt-proxy

• Não confie no seu provedor: https://esli.blog.br/nao-confie-no-seu-provedor-de-internet

• Qual melhor VPN: https://esli.blog.br/qual-melhor-vpn

• Qual melhor navegador: https://esli.blog.br/qual-melhor-navegador

Agora é a vez do Android. O objetivo é o mesmo: queries DNS criptografadas via DoH usando o NextDNS como resolver, mas com o dnscrypt-proxy rodando via InviZible Pro, alternativas e o que o Android oferece nativamente.

O que o Android já oferece (e por que não é suficiente)

Desde o Android 9, existe a opção "DNS Privado" em Configurações > Rede. Funciona com DoT (DNS-over-TLS) apontando para um hostname do tipo abc123.dns.nextdns.io (onde abc123 é seu config ID do NextDNS).

Funciona? Sim. Mas tem limitações:

• Só suporta DoT. Sem DoH, sem DNSCrypt, sem ODoH.

• Sem cache local configurável.

• Sem controle sobre qual app usa qual DNS.

• Sem firewall integrado.

• Sem fallback configurável.

• Se o servidor DoT não responder, o Android pode fazer fallback para o DNS do provedor sem avisar (dependendo da opção: "automático" faz fallback, "estrito" bloqueia).

• Não há logs para debug.

Para a maioria das pessoas, DNS Privado com NextDNS no modo estrito já é um avanço enorme sobre o DNS do provedor. Mas se você quer controle real, precisa de algo mais.

InviZible Pro: a solução completa

O InviZible Pro é um aplicativo Android open-source que integra três módulos de privacidade em um único pacote:

Disponível no F-Droid (versão sem restrições) e na Google Play. O código-fonte está em https://github.com/Gedsh/InviZible sob licença GPLv3.

O que ele faz

Funciona com e sem root. Com root, redireciona tráfego via iptables (mais eficiente, sem overhead de VPN). Sem root, cria uma VPN local (o tráfego não sai do dispositivo, apenas é redirecionado internamente para os módulos).

Firewall integrado. Controle granular por aplicativo: quem pode usar internet, quem passa pelo Tor, quem usa DNS direto. Isso substitui apps de firewall separados como o NetGuard.

Kill switch. Se o módulo cair, o tráfego é bloqueado. Sem vazamentos acidentais de queries em texto puro para o DNS do provedor.

Bridges Tor. Suporte a bridges obfs4, snowflake e webtunnel para contornar censura em redes restritivas.

Configuração granular. Acesso direto aos arquivos dnscrypt-proxy.toml, torrc e i2pd.conf dentro do app com editor de texto integrado.

Logs em tempo real. Cada módulo tem sua aba de log. Debug sem precisar de Termux ou logcat.

Atualizações independentes. Os binários do dnscrypt-proxy, Tor e Purple I2P são atualizados separadamente do app. Na versão mais recente (7.4.0, março de 2026): dnscrypt-proxy 2.1.15, Tor 4.8.22, Purple I2P 2.59.0.

Stealth Mode. Evasão de DPI (Deep Packet Inspection) para cenários de censura.

Em resumo: substitui VPN + firewall + adblock DNS em um único app, sem ads, sem rastreio, sem assinatura para as funcionalidades core. A versão paga destrava apenas o tema Material Design escuro.

Configurando NextDNS no InviZible Pro

Pré-requisitos

• InviZible Pro instalado (F-Droid: pan.alexander.tordnscrypt.stable ou Play Store)

• Conta no NextDNS com um perfil configurado

• Seu config ID (visível em https://my.nextdns.io na aba Setup)

Passo 1: Obter o stamp

Forma rápida: acesse https://my.nextdns.io, vá em Setup Guide > Routers ou Linux, seção DNSCrypt. O stamp já está pronto com seu config ID.

Forma manual: acesse https://dnscrypt.info/stamps/ e preencha:

O path DEVE começar com /. Se quiser identificar o dispositivo no painel do NextDNS, use /abc123/android-pixel ou similar.

Copie o stamp gerado. Algo como:

sdns://AgMAAAAAAAAAAAAADmRucy5uZXh0ZG5zLmlvBy9hYmMxMjM

Passo 2: Configurar via interface do InviZible Pro

1. Abra o InviZible Pro

2. No card DNSCrypt, toque no ícone de engrenagem

3. Acesse DNSCrypt servers e desmarque todos os servidores pré-configurados

4. Acesse Own servers / DNS Stamp (o nome pode variar conforme a versão)

5. Cole o stamp do passo anterior

6. Dê um nome ao servidor (ex: nextdns)

7. Salve

Passo 2 (alternativo): Editar o dnscrypt-proxy.toml

Se você prefere controle total (e já sabe o que está fazendo):

1. Menu > Common Settings > Open text editor

2. Selecione dnscrypt-proxy.toml

3. Edite:

# Forçar uso exclusivo do NextDNS
server_names = ['nextdns']

# Cache local (recomendado, especialmente no plano free)
cache = true
cache_size = 4096
cache_min_ttl = 2400
cache_max_ttl = 86400

# Servidor estático com seu stamp
[static]
  [static.'nextdns']
  stamp = 'sdns://AgMAAAAAAAAAAAAADmRucy5uZXh0ZG5zLmlvBy9hYmMxMjM'

1. Salve e feche o editor

Passo 3: Reiniciar e validar

1. No card DNSCrypt, pare o módulo (Stop) e inicie novamente (Start)

2. Verifique os logs do DNSCrypt. Deve aparecer o servidor nextdns como ativo com status OK

3. No navegador, acesse https://test.nextdns.io

Se tudo estiver correto, a página retorna seu config ID e status "connected" ou "using NextDNS".

Se retornar "not using NextDNS":

• Revise o stamp (o path tem a / inicial? O config ID está correto?)

• Verifique se não há outro servidor marcado nas configurações do DNSCrypt

• Nos logs, procure mensagens de erro relacionadas ao stamp

Passo 4: Ajustes adicionais

DNS e Tor juntos (cuidado):

Se o módulo Tor estiver ativo, por padrão as queries DNS são roteadas pelo Tor antes de chegar ao NextDNS. Isso:

• Esconde seu IP real do NextDNS (pode ser desejável)

• Aumenta a latência consideravelmente (indesejável para uso diário)

• Pode fazer o NextDNS não aplicar regras baseadas em localização

Para desabilitar: Common Settings > desmarque "Route DNS through Tor".

Consumo de bateria:

O DNSCrypt sozinho consome pouco. O Tor consome mais. Se usar apenas o módulo DNSCrypt (sem Tor e sem I2P), o impacto na bateria é mínimo. Segundo a documentação do InviZible, Tor + DNSCrypt 24/7 consome em torno de 8%.

Exclua o InviZible Pro da otimização de bateria do Android para evitar que o sistema mate o processo em background. Vá em Configurações > Bateria > Otimização de bateria > InviZible Pro > Não otimizar. Consulte https://dontkillmyapp.com para instruções específicas do seu fabricante (Samsung, Xiaomi/MIUI e Huawei são os piores nesse aspecto).

Rate limit no plano free do NextDNS:

O plano gratuito permite 300k queries/mês com filtragem ativa. Após o limite, o DNS continua resolvendo mas sem bloqueio e sem logs. O cache agressivo no dnscrypt-proxy.toml (cache_min_ttl = 2400) ajuda a reduzir o número de queries.

Monitore em https://my.nextdns.io > Analytics.

Alternativas ao InviZible Pro para DNSCrypt no Android

O InviZible Pro não é a única opção e dependendo do que você precisa (ou até onde está disposto a ir), outras ferramentas podem atender.

personalDNSfilter

Open-source, disponível no F-Droid. Funciona como proxy DNS local com suporte a blocklists. Não usa dnscrypt-proxy internamente, mas suporta DoH e DoT como upstream. Mais leve que o InviZible, sem os módulos Tor/I2P. Se você quer apenas DNS filtrado sem o pacote completo de privacidade, é uma opção.

https://www.zenz-solutions.de/personaldnsfilter-wp/

AdGuard (versão completa)

A versão completa do AdGuard (não confundir com o AdGuard DNS) funciona como VPN local no Android e intercepta DNS. Suporta DoH, DoT e DNSCrypt como upstream. Tem bloqueio de ads ao nível de rede (não só DNS), filtro HTTPS para bloquear ads em conexões criptografadas e proteção contra tracking. A versão completa é paga e não está na Play Store (baixar via site oficial).

https://adguard.com/en/adguard-android/overview.html

Rethink DNS + Firewall

Open-source, no F-Droid. Combina firewall por app, DNS criptografado (DoH, DoT), blocklists e logs detalhados. Interface moderna. Não usa dnscrypt-proxy, mas suporta configuração de servidores DNS customizados via DoH. Não suporta o protocolo DNSCrypt nem stamps diretamente, mas aceita endpoints DoH como https://dns.nextdns.io/abc123.

https://rethinkdns.com/

DNS Privado nativo do Android

Como mencionado, funciona apenas com DoT. Hostname do NextDNS: abc123.dns.nextdns.io. Sem firewall, sem cache configurável, sem logs. Mas é zero configuração e funciona em qualquer Android 9+.

Comparativo rápido

Resultado

Com o InviZible Pro configurado, seu Android passa a ter o mesmo nível de proteção DNS que o desktop com dnscrypt-proxy. Mesmo stamp, mesmo config ID do NextDNS, mesmas blocklists, analytics unificado no painel.

O setup completo da série: primeiro artigo para entender o ecossistema, segundo para configurar no Linux (Fedora e Arch), terceiro para Android. Três ambientes, um resolver, queries criptografadas em todos.

Se o seu provedor de internet pudesse cobrar por cada consulta DNS que bisbilhota, já teria financiado um programa espacial. Criptografe suas queries.

Outros artigos relacionados:

• DNSCrypt, DNS Stamps e DNS Criptografado: o guia que faltava

• dnscrypt-proxy no Linux: configurando DNS criptografado com NextDNS

• Privacidade e Segurança (2025)

• VPN não é o suficiente

• Como fugir das propagandas na Internet

• Qual melhor navegador

Referências:

• https://github.com/Gedsh/InviZible

• https://invizible.net/en/

• https://f-droid.org/packages/pan.alexander.tordnscrypt.stable/

• https://github.com/DNSCrypt/dnscrypt-proxy

• https://dnscrypt.info/stamps/

• https://my.nextdns.io

• https://test.nextdns.io

• https://dontkillmyapp.com

• https://rethinkdns.com/

• https://adguard.com/en/adguard-android/overview.html

O objetivo agora é prático: instalar o dnscrypt-proxy no Linux e configurar o NextDNS como resolver exclusivo via DoH, utilizando o stamp gerado conforme descrito no artigo anterior.

Uso NextDNS em todos os meus dispositivos, conforme descrevi no Privacidade e Segurança (2025). Aqui vou mostrar como configurar usando o dnscrypt-proxy ao invés do cliente oficial do NextDNS ou do DNS Privado nativo.

Por que dnscrypt-proxy ao invés do cliente NextDNS?

O NextDNS oferece um CLI próprio (nextdns via sh -c "$(curl -sL https://nextdns.io/install)"). Funciona bem, é simples. Mas o dnscrypt-proxy oferece vantagens:

• Suporta múltiplos protocolos (DNSCrypt, DoH, ODoH)

• Permite trocar de provider sem mudar a stack

• Suporte a Anonymized DNSCrypt e relays

• Cache local com TTL configurável

• Cloaking, blocklists locais, forwarding rules

• Logs detalhados para debug

• Funciona idêntico em qualquer distro

Se você quer apenas o NextDNS funcionando rápido, o CLI oficial resolve. Se quer controle granular ou planeja usar recursos além do que o NextDNS oferece nativamente, o dnscrypt-proxy é o caminho.

Instalação

Fedora

sudo dnf install dnscrypt-proxy

O pacote instala o binário, o serviço systemd e o arquivo de configuração em /etc/dnscrypt-proxy/dnscrypt-proxy.toml.

Arch / EndeavourOS / Omarchy

sudo pacman -S dnscrypt-proxy

Mesma estrutura. Arch mantém o pacote atualizado com frequência.

Debian / Ubuntu

sudo apt install dnscrypt-proxy

Atenção: as versões nos repositórios do Debian/Ubuntu podem estar desatualizadas. Verifique a versão com dnscrypt-proxy --version e compare com os releases em https://github.com/DNSCrypt/dnscrypt-proxy/releases. Se estiver muito defasado, instale manualmente via binário do GitHub.

Obter o stamp do NextDNS

Duas formas:

Forma 1 (recomendada): acesse https://my.nextdns.io, vá em Setup Guide, selecione Linux ou Routers, e copie o stamp da seção DNSCrypt. Ele já vem com seu config ID embutido.

Forma 2 (manual): acesse https://dnscrypt.info/stamps/ e preencha:

Copie o stamp resultante (sdns://...).

Para identificar a máquina no painel do NextDNS, adicione o nome do dispositivo ao path: /abc123/fedora-desktop.

Configuração

Edite o arquivo principal:

sudo vim /etc/dnscrypt-proxy/dnscrypt-proxy.toml

As configurações essenciais:

# Porta de escuta
listen_addresses = ['127.0.0.1:53', '[::1]:53']

# Forçar uso exclusivo do NextDNS
server_names = ['nextdns']

# Habilitar IPv6 se sua rede suportar
ipv6_servers = false

# Requerer DNSSEC, no-log e no-filter
require_dnssec = true
require_nofilter = false
require_nolog = true

# Cache local
cache = true
cache_size = 4096
cache_min_ttl = 2400
cache_max_ttl = 86400

# Desabilitar download automático de listas públicas
# (queremos APENAS o NextDNS)
# Comente ou remova as seções [sources] se existirem:
# [sources]
#   [sources.'public-resolvers']
#     ...
#   [sources.'relays']
#     ...

# Servidor estático com seu stamp
[static]
  [static.'nextdns']
  stamp = 'sdns://AgMAAAAAAAAAAAAADmRucy5uZXh0ZG5zLmlvBy9hYmMxMjM'

Substitua o stamp pelo gerado com seu ID real.

Sobre o cache: os valores acima são agressivos de propósito. cache_min_ttl = 2400 (40 minutos) e cache_max_ttl = 86400 (24 horas) reduzem significativamente o número de queries ao NextDNS. Se você está no plano free (300k queries/mês), isso faz diferença. Mesmo no plano pago, menos queries = menos latência para domínios frequentes.

O inferno do systemd-resolved

Se você está no Fedora, Ubuntu ou qualquer distro que use systemd-resolved, prepare-se: ele escuta na porta 53 por padrão e vai conflitar com o dnscrypt-proxy.

Verifique antes de qualquer coisa:

ss -tlnp | grep ':53 '

Se aparecer systemd-resolve ouvindo na 53, você tem duas opções:

Opção A: Desabilitar o systemd-resolved (recomendado)

Se você quer controle total do DNS e não precisa do resolved para nada:

sudo systemctl disable --now systemd-resolved
sudo rm /etc/resolv.conf
echo 'nameserver 127.0.0.1' | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf

O chattr +i torna o arquivo imutável. Sem isso, o NetworkManager vai sobrescrever o resolv.conf na primeira reconexão. Para editar futuramente: sudo chattr -i /etc/resolv.conf.

Opção B: Convivência (dnscrypt-proxy em porta alternativa)

Se por algum motivo precisa manter o resolved (integração com VPN corporativa, mDNS/Avahi, etc.):

No dnscrypt-proxy.toml:

listen_addresses = ['127.0.0.1:5353']

No /etc/systemd/resolved.conf:

[Resolve]
DNS=127.0.0.1#5353
DNSStubListener=yes

sudo systemctl restart systemd-resolved

Funciona, mas adiciona uma camada desnecessária. O resolved vira um middleman que só repassa. A não ser que tenha um motivo concreto, vá com a Opção A.

Nota para Arch com Hyprland / Window Managers

Se você não usa NetworkManager e configura rede via iwd, dhcpcd ou manualmente, o systemd-resolved provavelmente nem está ativo. Verifique com systemctl status systemd-resolved. Se estiver inativo, não precisa fazer nada. Apenas garanta que o /etc/resolv.conf aponte para 127.0.0.1.

Persistência do resolv.conf no Fedora com NetworkManager

O NetworkManager reescreve o /etc/resolv.conf a cada reconexão. Além do chattr +i, existe uma abordagem mais limpa: instruir o NetworkManager a não gerenciar DNS.

Crie o arquivo /etc/NetworkManager/conf.d/no-dns.conf:

[main]
dns=none

sudo systemctl restart NetworkManager

A partir daqui, o NetworkManager não toca no DNS. Seu resolv.conf com nameserver 127.0.0.1 permanece intacto.

Habilitando e iniciando

sudo systemctl enable --now dnscrypt-proxy.service

Verifique:

systemctl status dnscrypt-proxy
journalctl -u dnscrypt-proxy -f

Nos logs, procure linhas indicando que o servidor nextdns foi validado. Algo como:

[nextdns] OK (DoH) - rtt: XXms

Se aparecer erros de stamp ou servidor não encontrado, revise o stamp e verifique se não há servidores padrão habilitados competindo com a configuração estática.

Validação

# Resolução via dnscrypt-proxy
dig @127.0.0.1 esli.blog

# Confirmar NextDNS ativo
curl -sL https://test.nextdns.io

O retorno do test.nextdns.io deve mostrar:

• Status: Connected (ou Using NextDNS)

• Protocol: DoH

Se retornar "not using NextDNS", revise:

1. O stamp (path correto com /SEU_ID?)

2. O server_names aponta para o nome correto?

3. Algum servidor padrão ainda está habilitado nas sources?

4. O resolv.conf aponta para 127.0.0.1?

Teste também a filtragem. Acesse um domínio que deveria ser bloqueado pelas suas blocklists no NextDNS:

dig @127.0.0.1 [algum-site.bloqueado]

Se retornar 0.0.0.0 ou NXDOMAIN, a filtragem está funcionando.

Configurações avançadas opcionais

Anonymized DNS com relays

Se quiser ir além e usar relays para que o NextDNS não veja seu IP (via Anonymized DoH), adicione ao dnscrypt-proxy.toml:

[anonymized_dns]
routes = [
    { server_name='nextdns', via=['anon-relay-1', 'anon-relay-2'] }
]

Os relays disponíveis estão na lista de resolvers do dnscrypt-proxy. Isso adiciona latência, mas aumenta significativamente a privacidade. Se o NextDNS não deve saber de qual IP as queries vêm, essa é a forma.

Blocklists locais

O dnscrypt-proxy suporta blocklists próprias, independentes do NextDNS. No dnscrypt-proxy.toml:

[blocked_names]
blocked_names_file = '/etc/dnscrypt-proxy/blocked-names.txt'

No arquivo blocked-names.txt, adicione domínios (um por linha, suporta wildcards):

*.facebook.com
*.tiktok.com
ads.*

Isso funciona mesmo se o NextDNS estiver fora do ar. É uma camada adicional de filtragem local.

Query logging para debug

[query_log]
file = '/var/log/dnscrypt-proxy/query.log'
format = 'tsv'

Crie o diretório antes:

sudo mkdir -p /var/log/dnscrypt-proxy
sudo chown _dnscrypt-proxy:_dnscrypt-proxy /var/log/dnscrypt-proxy

O formato TSV facilita análise com awk, cut e companhia. Desligue em produção se privacidade for prioridade.

Meu dnscrypt-config.toml: https://github.com/Esl1h/dotfiles/blob/main/etc/dnscrypt-proxy/dnscrypt-proxy.toml

Resultado

Mesmo stamp, mesma configuração do NextDNS, mesma proteção que você tem no Android (que será o tema do próximo artigo). Suas queries DNS saem criptografadas, filtradas pelas mesmas blocklists, com analytics unificado no painel do NextDNS.

Seu provedor de internet que se contente em ver pacotes criptografados passando sem saber o que você está resolvendo.

Outros artigos relacionados:

• DNSCrypt, DNS Stamps e DNS Criptografado: o guia que faltava

• Privacidade e Segurança (2025)

• VPN não é o suficiente

• Como fugir das propagandas na Internet

• Usando o Brave, scriptlets, filter e wikiwand para melhor navegação

Referências:

• https://github.com/DNSCrypt/dnscrypt-proxy

• https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Configuration

• https://dnscrypt.info/stamps/

• https://my.nextdns.io

• https://test.nextdns.io

Já falei sobre DNS e privacidade em outros artigos aqui no blog, como no Privacidade e Segurança (2025), onde uso NextDNS em todos os dispositivos, e no Como fugir das propagandas na Internet, onde mostro como o NextDNS funciona como camada de bloqueio e também o porque você não deve confiar no seu provedor de internet.
Neste artigo, vou aprofundar no protocolo DNSCrypt, nos DNS Stamps e no ecossistema de DNS criptografado.

DNS tradicional: o problema

O DNS (Domain Name System) resolve nomes de domínio em endereços IP. Funciona como uma lista telefônica: você pede o número de esli.blog e recebe o IP do servidor. O problema é que essa "ligação" acontece sem criptografia. Qualquer pessoa no caminho (seu ISP, o administrador da rede do café, um atacante na mesma rede) consegue ver exatamente quais domínios você está resolvendo.

Isto é, superficialmente, como funciona o protocolo. O DNS foi projetado nos anos 80, quando a internet era um ambiente acadêmico e a ideia de privacidade na rede não existia.

Os protocolos de DNS criptografado

Com o tempo, surgiram vários protocolos para resolver esse problema. Cada um com abordagens diferentes.

DoT (DNS-over-TLS)

Encapsula as consultas DNS dentro de uma conexão TLS. Usa a porta 853, dedicada exclusivamente para esse fim. Padronizado na RFC 7858.

O fato de usar uma porta própria é uma faca de dois gumes: facilita a configuração, mas também facilita o bloqueio. Um administrador de rede (ou governo) pode simplesmente bloquear a porta 853 e acabou o DoT. O Android usa DoT nativamente na função "DNS Privado" desde a versão 9, o que popularizou o protocolo em dispositivos móveis.

DoH (DNS-over-HTTPS)

Encapsula as consultas DNS dentro de conexões HTTPS, usando a porta 443. Padronizado na RFC 8484.

A sacada é que o tráfego DoH se mistura com o tráfego HTTPS normal. Para bloquear DoH, seria necessário bloquear todo o HTTPS, o que inviabilizaria a navegação. Isso o torna mais resistente à censura, mas também mais difícil de monitorar em ambientes corporativos (onde monitoramento pode ser legítimo). Navegadores como Firefox e Chrome suportam DoH nativamente.

DoQ (DNS-over-QUIC)

Usa o protocolo QUIC (que por sua vez roda sobre UDP) para transportar consultas DNS. Padronizado na RFC 9250.

Mais recente, promete menor latência que DoT/DoH por eliminar o handshake TLS+TCP separado. Ainda com adoção limitada, mas providers como AdGuard DNS já suportam.

DoH3 (DNS-over-HTTP/3)

Similar ao DoQ, mas usando HTTP/3 como transporte. Como o HTTP/3 já usa QUIC, herda as mesmas vantagens de latência. Providers como DNS0 (fundado pelos co-fundadores do NextDNS) já suportam.

ODoH (Oblivious DNS-over-HTTPS)

Uma camada de anonimização sobre o DoH. Usa um proxy intermediário (relay) para que o resolver nunca veja o IP do cliente que fez a consulta. Padronizado na RFC 9230.

O conceito é semelhante ao Anonymized DNSCrypt (que veremos adiante): separar quem pergunta de quem responde.

DNSCrypt

E aqui é onde a conversa fica interessante.

DNSCrypt: o protocolo que a indústria ignorou

O DNSCrypt foi criado por Frank Denis (jedisct1), o mesmo autor do libsodium. Não é um "remendo" sobre outro protocolo. Foi projetado especificamente para proteger tráfego DNS.

O que ele faz:

Autenticação do servidor. O cliente valida que está falando com o resolver legítimo usando a chave pública do provider. Sem depender de CAs (Certificate Authorities). Isso elimina toda a cadeia de confiança de TLS, que é um ponto de falha conhecido.

Criptografia da query e resposta. Usa Curve25519 para troca de chaves e XSalsa20-Poly1305 (ou XChaCha20-Poly1305) para criptografia autenticada. Tudo baseado em criptografia de curva elíptica, sem depender de RSA ou da infraestrutura de certificados X.509.

Anti-replay e anti-forgery. Cada query tem um nonce único. Respostas forjadas ou repetidas são detectadas e descartadas.

Padding. As queries e respostas são preenchidas com dados aleatórios para dificultar análise de tráfego baseada no tamanho dos pacotes.

O protocolo roda sobre UDP (porta 443 por padrão) e opcionalmente TCP. É leve, rápido e não depende de infraestrutura de PKI.

O protocolo está em processo de padronização no IETF como Internet-Draft (draft-denis-dprive-dnscrypt-06, atualizado em abril de 2025).

Por que a indústria ignorou?

Google, Cloudflare, Apple, Microsoft, todos adotaram DoH e DoT. O DNSCrypt ficou de fora do mainstream. Não porque seja inferior tecnicamente, mas porque não tem uma megacorp por trás patrocinando a adoção. DoH usa HTTPS, que toda a infraestrutura web já suporta e o DNSCrypt exige implementação própria.

Resultado: o protocolo DNSCrypt em si tem adoção limitada entre os grandes providers. AdGuard DNS, Quad9 e CleanBrowsing suportam. NextDNS, Cloudflare e Google não suportam o protocolo DNSCrypt, apenas DoH e DoT.

Mas aqui entra a distinção crucial: o protocolo DNSCrypt é uma coisa, o software dnscrypt-proxy é outra.

dnscrypt-proxy: o canivete suíço

O dnscrypt-proxy é a implementação de referência do cliente. Escrito em Go, roda em praticamente qualquer coisa: Linux, macOS, Windows, Android, roteadores com OpenWrt.

O ponto é que o dnscrypt-proxy não se limita ao protocolo DNSCrypt. Ele suporta:

• DNSCrypt v2

• DoH (DNS-over-HTTPS)

• ODoH (Oblivious DoH)

• Anonymized DNSCrypt

Então mesmo que um provider não suporte o protocolo DNSCrypt (como o NextDNS), você ainda pode usar o dnscrypt-proxy para se conectar via DoH. O software aceita stamps de qualquer protocolo suportado.

Anonymized DNSCrypt: DNS sem rastreio

O DNS criptografado resolve o problema de interceptação no caminho. Mas não resolve o problema do próprio resolver saber quem fez a consulta. Seu IP chega ao servidor junto com a query.

O Anonymized DNSCrypt resolve isso introduzindo relays. Funciona assim:

1. O cliente criptografa a query para o resolver final (usando a chave pública do resolver).

2. Envia a query criptografada para um relay.

3. O relay não tem a chave do resolver, então não consegue ler o conteúdo. Ele apenas encaminha o pacote.

4. O resolver recebe a query, descriptografa, resolve e responde via relay.

O relay sabe o IP do cliente, mas não sabe o conteúdo da query. O resolver sabe o conteúdo da query, mas só vê o IP do relay. Nenhum dos dois tem o quadro completo.

Isso é fundamentalmente diferente de usar Tor para DNS (que é lento e não foi projetado para isso) ou de confiar cegamente que o resolver é “no-log”.

A lista de relays disponíveis está no repositório oficial: https://github.com/DNSCrypt/dnscrypt-resolvers

DNS Stamps: o QR Code do DNS

Configurar DNS criptografado manualmente é chato. Você precisa informar protocolo, IP, porta, hostname, path (no caso de DoH), chave pública (no caso de DNSCrypt), e opcionalmente hashes de certificado. São vários campos, cada um com formato diferente dependendo do protocolo.

O DNS Stamp resolve isso codificando tudo em uma única string.

Estrutura

Um stamp começa com sdns:// seguido de um payload em base64url. O primeiro byte do payload identifica o protocolo:

Depois do protocolo, o payload contém propriedades (DNSSEC, no-log, no-filter), endereço IP, hashes de certificado, hostname, path e opcionalmente IPs de bootstrap.

Exemplo prático

Um stamp DoH para o NextDNS com ID abc123:

sdns://AgMAAAAAAAAAAAAADmRucy5uZXh0ZG5zLmlvBy9hYmMxMjM

Decodificando:

• Protocolo: 0x02 (DoH)

• Hostname: dns.nextdns.io

• Path: /abc123

• No-log: sim

• DNSSEC: sim

Gerando stamps

O gerador oficial está em https://dnscrypt.info/stamps/ (anteriormente em https://stamps.dnscrypt.info). Você seleciona o protocolo, preenche os campos e o stamp é gerado automaticamente. Funciona no sentido inverso também: cole um stamp e ele decodifica os campos.

A especificação dos DNS Stamps está em processo de padronização no IETF (draft-denis-dns-stamps-00, julho de 2025), suportando DNSCrypt, DoH, DoT, DoQ e ODoH.

Quem publica stamps nativamente?

Nem todo provider facilita a vida. Alguns publicam stamps prontos na documentação, outros exigem que você gere manualmente.

Correção importante sobre o NextDNS: diferente do que muitos pensam, o NextDNS fornece o stamp na página de Setup. Vá em https://my.nextdns.io, acesse Setup Guide, selecione Routers, e procure a seção DNSCrypt. O stamp já está gerado com seu config ID. Ele é um stamp DoH (não DNSCrypt nativo, pois o NextDNS não suporta o protocolo DNSCrypt).

Se preferir gerar manualmente ou adicionar um nome de dispositivo ao path, use o gerador em https://dnscrypt.info/stamps/ com os seguintes campos:

O path deve começar com /. Se o ID é abc123, o path é /abc123. Para identificar o dispositivo no painel, adicione um nome: /abc123/fedora-desktop.

A lista completa de resolvers com stamps prontos está no repositório oficial: https://github.com/DNSCrypt/dnscrypt-resolvers

O dnscrypt-proxy baixa essas listas automaticamente e permite selecionar servidores por nome, protocolo, localização, ou filtrar por propriedades como no-log e DNSSEC.

Resumo dos protocolos

* Porta padrão 443, mas configurável.

Próximos artigos

Este artigo é o primeiro de uma série de três. No próximo artigo, mostro como instalar e configurar o dnscrypt-proxy no Linux (Fedora e Arch) utilizando o NextDNS como resolver. No terceiro, a configuração no Android com o InviZible Pro e alternativas.

Se você ainda está utilizando o DNS do seu provedor, considere que ele provavelmente sabe mais sobre seus hábitos de navegação do que você gostaria. E se pudesse cobrar por cada consulta que bisbilhota, já teria financiado uma ida à lua.

Outros artigos relacionados no blog:

• Privacidade e Segurança (2025)

• VPN não é o suficiente

• Como fugir das propagandas na Internet

• Qual melhor navegador

• Guia de Comandos Linux para Redes (modelo OSI)

Referências:

• https://dnscrypt.info/

• https://dnscrypt.info/stamps-specifications/

• https://github.com/DNSCrypt/dnscrypt-proxy

• https://github.com/DNSCrypt/dnscrypt-resolvers

• https://www.ietf.org/archive/id/draft-denis-dns-stamps-00.html

• https://www.cloudflare.com/learning/dns/dns-over-tls/

O que entregam:

Gratuitos (sem assinatura)

1. DNS — resolvedores DoH/DoT com 6 perfis de filtragem

2. Mullvad Browser — navegador anti-fingerprinting com Tor Project

3. Connection Check — ferramenta web (mullvad.net/check) e API (am.i.mullvad.net/json) para verificar IP, localização, DNS leaks e status da conexão. Funciona para qualquer VPN, não só Mullvad.

4. Código-fonte aberto — todo o código do app (desktop/mobile) e browser está no GitHub sob GPLv3

5. Acesso via .onion — site completo acessível pela rede Tor

Descontinuados:

1. Mullvad Leta — motor de busca proxy (Google/Brave Search). Foi descontinuado. Mullvad Inicialmente requeria conta paga, tornou-se gratuito e aberto a todos em março de 2025 Vivaldi, e foi posteriormente desligado.

Pago (€5/mês):

• VPN (WireGuard, multihop, DAITA, anti-censura, kill switch, split tunneling, túneis pós-quânticos).

O que é a Mullvad

Mullvad significa "toupeira" em sueco. O nome já entrega a proposta: cavar um túnel e sumir. A empresa foi fundada em 2009 por Daniel Berntsson e Fredrik Strömberg em Gotemburgo, Suécia, sob a empresa Amagicom AB. Desde o início, a ideia era oferecer um serviço de VPN que não exigisse e-mail, nome, telefone ou qualquer dado pessoal para funcionar.

Enquanto a concorrência inteira entrava numa corrida de quem gritava mais alto sobre privacidade (e ao mesmo tempo pedia seu CPF no cadastro), a Mullvad gerava um número de conta aleatório de 16 dígitos e pronto. Esse é seu login. Não existe "recuperar senha", não existe "esqueci meu e-mail". Perdeu o número, perdeu o acesso. Simples, brutal e coerente.

Em abril de 2023, a polícia sueca apareceu no escritório da Mullvad com um mandado de busca e apreensão querendo dados de clientes. Saíram de mãos vazias. Não porque a Mullvad se recusou a cooperar, mas porque não havia dados para entregar. A política de no-log não era só marketing, realmente faz parte arquitetura.

Filosofia

A Mullvad opera com alguns princípios raros no mercado de VPN:

1. Sem contas identificáveis. Número aleatório. Sem e-mail, sem nome.

2. Preço único e fixo. Sem planos anuais com desconto manipulativo, sem "oferta por tempo limitado". O mesmo valor desde 2009.

3. Código aberto. Clientes para todas as plataformas com código no GitHub.

4. Auditorias independentes. Realizadas por Cure53, Assured AB, X41 D-Sec, entre outros. Publicadas e acessíveis.

5. Aceita pagamento anônimo. Dinheiro pelo correio (sim, você coloca euros num envelope e manda pra Suécia), Bitcoin, Bitcoin Cash, Monero, e cartão.

6. Sem programa de afiliados. Nenhum YouTuber vai te oferecer "código PRIVACIDADE10" pra Mullvad. Eles simplesmente não fazem isso.

7. Sem renovação automática. Você não "assina" a Mullvad. Você adiciona tempo à conta. Acabou, acabou. Sem surpresas no cartão.

Essa última é a que mais me diverte. A ausência total de marketing agressivo num mercado que é basicamente sustentado por marketing agressivo. Enquanto a NordVPN e a Surfshark brigam pra ver quem patrocina mais podcasters e youtubers, a Mullvad está lá no canto, fazendo o trabalho.

VPN

O que você recebe

O serviço de VPN é o produto principal. Desde janeiro de 2026, a Mullvad opera exclusivamente com o protocolo WireGuard. O suporte a OpenVPN foi completamente removido após um período de transição que começou em novembro de 2024. A decisão faz sentido: WireGuard é mais rápido, mais leve, tem uma base de código drasticamente menor (o que significa menos superfície de ataque) e já era o protocolo padrão do app havia anos.

Com o foco exclusivo no WireGuard, a Mullvad pôde investir em funcionalidades avançadas:

Multihop — entrada por um servidor, saída por outro. Separa o ponto que conhece sua origem do ponto que conhece seu destino.

DAITA (Defense Against AI-guided Traffic Analysis) — mecanismo para dificultar análise de tráfego por machine learning. Adiciona padding e padrões de tráfego fictício para que um observador não consiga inferir o que você está fazendo dentro do túnel.

Túneis pós-quânticos — proteção contra a possibilidade de que computadores quânticos futuros quebrem a criptografia usada na troca de chaves atual. A Mullvad implementa key exchange quantum-resistant sobre WireGuard.

Anti-censura — para contornar bloqueios em redes restritivas, o app oferece Shadowsocks e UDP-over-TCP diretamente nas configurações. Substituem a necessidade do antigo bridge mode com OpenVPN.

Servidores

A Mullvad mantém cerca de 580 servidores em 50 países, distribuídos em 90 cidades. Não é a maior rede do mercado, longe disso. Mas a filosofia é diferente: boa parte da infraestrutura é composta por servidores próprios (bare-metal), não alugados em cloud. Todos os servidores rodam em RAM (diskless), o que significa que um reboot apaga tudo. Isso reduz a superfície de ataque e a dependência de terceiros.

A lista completa de servidores e o status em tempo real ficam em: https://mullvad.net/en/servers

Limite de dispositivos

Cada conta permite até 5 conexões simultâneas. Simples, sem tiers, sem upsell para "plano família".

Instalação no Linux

No Arch (e derivados):

yay -S mullvad-vpn

No Fedora:

sudo dnf config-manager addrepo --from-repofile=https://repository.mullvad.net/rpm/stable/mullvad.repo
sudo dnf install mullvad-vpn

No Debian/Ubuntu via repositório:

sudo apt install curl
sudo curl -fsSLo /usr/share/keyrings/mullvad-keyring.asc https://repository.mullvad.net/deb/mullvad-keyring.asc
echo "deb [signed-by=/usr/share/keyrings/mullvad-keyring.asc arch=$( dpkg --print-architecture )] https://repository.mullvad.net/deb/stable stable main" | sudo tee /etc/apt/sources.list.d/mullvad.list
sudo apt update
sudo apt install mullvad-vpn

A versão mais recente no momento da escrita é a 2026.1, que já usa Wayland por padrão no Linux (com fallback para X11).

Existe a versão com GUI (mullvad-vpn) e sem GUI (mullvad-vpn-cli). Para quem roda Hyprland ou qualquer WM sem tray nativa, a CLI resolve bem:

mullvad account login 1234567890123456
mullvad relay set location br sao
mullvad connect
mullvad status

Nota para quem usa Fedora com GNOME ou KDE: a partir da versão 2026.1, o ícone na tray pode exigir a extensão AppIndicator e o pacote libappindicator-gtk3.

Para WireGuard puro, sem o client da Mullvad, é possível gerar configurações diretamente pelo site: https://mullvad.net/en/account/wireguard-config

Isso gera um arquivo .conf que você importa direto no wg-quick ou no NetworkManager:

sudo wg-quick up /etc/wireguard/mullvad-br-sao.conf

Multihop com WireGuard

O multihop encadeia dois servidores: o tráfego entra por um e sai por outro. Útil pra quem quer uma camada extra de separação entre entrada e saída.

Via CLI:

mullvad relay set tunnel wireguard --entry-location se got
mullvad relay set location us nyc
mullvad connect

Nesse exemplo, o tráfego entra pela Suécia (Gotemburgo) e sai pelos EUA (Nova York).

Kill Switch

O kill switch vem habilitado por padrão. Se a conexão VPN cair, todo o tráfego de rede é bloqueado até reconectar. Sem vazamentos. Sem "ah, mas eu queria acessar a rede local". Se quiser ajustar:

mullvad lockdown-mode set on
mullvad lan set allow

Split Tunneling

Permite que processos específicos ignorem o túnel VPN:

mullvad split-tunnel add 1234  # PID do processo

No Linux, funciona via cgroups. Não é o método mais elegante do mundo, mas funciona.

Anti-censura

Desde a remoção do OpenVPN, a Mullvad oferece métodos de ofuscação diretamente no WireGuard:

mullvad anti-censorship set udp-over-tcp --port 443   # simula OpenVPN sobre TCP
mullvad anti-censorship set shadowsocks              # simula o antigo bridge mode
mullvad anti-censorship set automatic                # tenta automaticamente se WireGuard puro falhar

A opção automatic é a mais prática: tenta conexão direta primeiro e escala para ofuscação se necessário.

Preço

5 euros por mês. Sempre. Desde 2009. Sem desconto anual, sem Black Friday, sem "plano de 3 anos que parece barato até você fazer a conta". Um mês custa 5 euros. Doze meses custam 60 euros. A matemática é simples e honesta.

O único desconto que existe é de 10% para pagamento em criptomoedas (Bitcoin, Bitcoin Cash e Monero), devido a taxas menores de processamento.

Formas de pagamento: cartão de crédito, PayPal, Bitcoin, Bitcoin Cash, Monero, transferência bancária, Swish (Suécia), EPS transfer, Bancontact, iDEAL/Wero, Przelewy24, e dinheiro físico pelo correio.

Garantia de devolução: 14 dias (exceto para pagamentos em dinheiro e criptomoedas).

Página da conta: https://mullvad.net/en/account

Mullvad e a Mozilla VPN

Um ponto que muita gente não sabe: a Mozilla VPN (aquela integrada ao ecossistema Firefox) usa a infraestrutura de servidores da Mullvad por baixo. Se você já assina a Mullvad, a Mozilla VPN é redundante. Se está avaliando a Mozilla VPN, saiba que os servidores WireGuard que ela usa são os mesmos da Mullvad, mas com outra camada de billing e interface.

Mullvad Browser

Em abril de 2023, a Mullvad se juntou ao Tor Project para lançar o Mullvad Browser. A ideia é simples e genial: pegar a engenharia anti-fingerprinting do Tor Browser, remover a rede Tor e entregar um navegador que funciona com VPN (ou sem VPN) mas que torna todos os usuários indistinguíveis entre si.

O Tor Browser já é o padrão ouro em anti-fingerprinting. O problema é que muita gente quer essa proteção mas não quer (ou não precisa) rotear tudo pela rede Tor, que é mais lenta e levanta flags em vários serviços. O Mullvad Browser resolve isso.

O que muda na prática

Todos os usuários do Mullvad Browser têm a mesma fingerprint. Mesmas fontes, mesma resolução reportada, mesmas configurações. O objetivo é criar uma "multidão" onde cada indivíduo é indistinguível. É o conceito de crowd anonymity aplicado ao navegador.

Ele já vem com:

• uBlock Origin pré-instalado

• Modo privado por padrão (sem histórico persistente)

• Letterboxing (a área útil do browser é padronizada para evitar fingerprinting por resolução)

• Proteção contra fingerprinting de canvas, WebGL, AudioContext

• Sem telemetria

Ciclo de atualização

O Mullvad Browser é baseado no Firefox ESR (Extended Support Release), o que garante estabilidade. A partir de 2026, o canal Alpha passou a seguir o Firefox Rapid Release em vez do ESR, com atualizações a cada quatro semanas. O canal Stable continua no ESR. O Alpha também passou a estar disponível para Linux ARM.

Relação com o Tor Project

O Mullvad Browser é mantido pelo Tor Project com financiamento da Mullvad. Usa a mesma base do Tor Browser (Firefox ESR com patches), mas sem o proxy SOCKS da rede Tor. É literalmente o Tor Browser para quem não quer usar Tor.

Isso não é concorrência ao Tor Browser. São ferramentas complementares:

Download: https://mullvad.net/en/browser

Disponível para Linux, Windows e macOS. No Linux, vem como tarball. Extrai, roda, sem instalação no sistema.

DNS

Aqui a Mullvad entrega bastante coisa gratuitamente. Você não precisa ser assinante da VPN para usar os servidores DNS deles.

O que é DNS e por que você deveria se importar

O DNS (Domain Name System) é o sistema que traduz nomes de domínio como esli.blog.br em endereços IP. Toda vez que você acessa qualquer site, uma consulta DNS acontece antes de tudo. Se essa consulta não é criptografada, seu provedor de internet (e qualquer um no caminho) sabe exatamente quais sites você está acessando, mesmo que o conteúdo em si esteja criptografado via HTTPS.

A Mullvad oferece resolvedores DNS gratuitos com criptografia e diferentes níveis de filtragem. Não registram logs.

Tipos de DNS oferecidos

Todos suportam DNS over HTTPS (DoH) e DNS over TLS (DoT), sem logging.

Documentação completa: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls

Qual perfil escolher

Se você nunca configurou um DNS alternativo antes e quer algo prático: comece com o base (194.242.2.4). Ele bloqueia anúncios e rastreadores sem quebrar sites. Se quiser proteção adicional contra domínios maliciosos, suba para o extended. O all pode quebrar funcionalidades de redes sociais embeddadas em sites, então use com consciência.

Configurando no systemd-resolved

sudo mkdir -p /etc/systemd/resolved.conf.d
cat << 'EOF' | sudo tee /etc/systemd/resolved.conf.d/mullvad-dns.conf
[Resolve]
DNS=194.242.2.4#base.dns.mullvad.net
DNSOverTLS=yes
Domains=~.
EOF
sudo systemctl restart systemd-resolved
resolvectl status

Configurando via NetworkManager

nmcli connection modify "SuaConexao" ipv4.dns "194.242.2.4"
nmcli connection modify "SuaConexao" ipv4.ignore-auto-dns yes
nmcli connection down "SuaConexao" && nmcli connection up "SuaConexao"

DNS no Mullvad Browser

O Mullvad Browser usa o DoH da Mullvad por padrão. Não precisa configurar nada. Se quiser trocar o perfil de filtragem, altere nas configurações de rede do browser (about:preferences#general na seção Network Settings).

DNS e a Mullvad VPN

Quando você está conectado à VPN da Mullvad, o DNS é automaticamente roteado pelos servidores deles dentro do túnel. Isso evita DNS leaks. Se quiser trocar o perfil de filtragem dentro da VPN:

mullvad dns set default --block-ads --block-trackers --block-malware

Para verificar:

mullvad dns get

Integração com o Brave

O Brave não usa a Mullvad como backend de VPN. O Brave Firewall + VPN é powered by Guardian, uma empresa americana, e é um produto completamente separado, com outra infraestrutura, outro preço (US\(9.99/mês ou US\)99.99/ano), e até outra jurisdição (EUA, dentro do Five Eyes, o que não é exatamente ideal para um serviço de privacidade).

A relação entre Brave e Mullvad é mais limitada e indireta: ambos compartilham valores de privacidade e o Brave permite configuração de DNS customizado, o que torna trivial usar os resolvedores da Mullvad sem pagar nada.

Para configurar o DoH da Mullvad no Brave:

brave://settings/security → seção "Usar DNS seguro" → "Personalizado" → inserir:

https://base.dns.mullvad.net/dns-query

Troque base por adblock, extended, all ou family conforme o nível de filtragem desejado.

Mullvad e Tor: a relação completa

A relação entre Mullvad e Tor vai além do browser. Existem alguns pontos de conexão:

Mullvad Browser

Parceria direta. Tor Project desenvolve, Mullvad financia. Já coberto acima.

VPN + Tor

Usar VPN antes do Tor (VPN como entrada) tem prós e contras:

Prós:

• Seu ISP não sabe que você está usando Tor

• O nó de entrada do Tor vê o IP da VPN, não o seu

Contras:

• A Mullvad sabe que você está usando Tor (já que seu tráfego passa pelo túnel)

• Adiciona um ponto de confiança na cadeia

A Mullvad não bloqueia Tor e não interfere no tráfego. Funciona de forma transparente.

Pagamento via Tor

O site da Mullvad é acessível via .onion:

http://o54hon2e2vj6c7m3aqqu6uyece65by3vgoez7kfzrhqsitv2bvqd.onion

Você pode gerar uma conta, adicionar tempo e configurar tudo sem nunca sair da rede Tor.

Auditorias de segurança

A Mullvad é uma das VPNs mais auditadas do mercado. As auditorias são feitas por firmas independentes e os relatórios são publicados integralmente. Algumas das mais recentes incluem avaliações da Cure53, Assured AB, e X41 D-Sec, cobrindo infraestrutura, aplicativo, política de logs e implementação WireGuard. A auditoria mais recente da implementação WireGuard não encontrou vulnerabilidades críticas.

Todos os relatórios ficam disponíveis no blog oficial: https://mullvad.net/en/blog

Apps e links

O app está disponível também no F-Droid (Android) e na App Store (iOS).

Verificando se está tudo funcionando

Depois de conectar a VPN, o teste rápido:

curl -s https://am.i.mullvad.net/json | python3 -m json.tool

Isso retorna seu IP, localização, se está conectado à Mullvad e se há DNS leaks.

Pelo navegador: https://mullvad.net/en/check

O que a Mullvad não faz

Vale ser honesto sobre as limitações:

• Streaming: não desbloqueia Netflix, Disney+, Hulu, BBC iPlayer, e nem tenta. Se esse é seu caso de uso principal, procure outro serviço.

• Rede de servidores: ~580 servidores em 50 países é modesto comparado a NordVPN (6000+ em 100+ países) ou Proton VPN (milhares em 120+ países). Na prática, funciona bem para uso normal, mas não espere cobertura ampla na Ásia ou África.

• Interface: funcional, não bonita. Não tem mapa mundi interativo nem tutorial de onboarding. Assume que você sabe o que está fazendo.

• Suporte: apenas por e-mail. Sem chat ao vivo, sem telefone.

• Jurisdição: Suécia, que faz parte da aliança 14 Eyes. Na prática, a política de no-log e a arquitetura diskless mitigam o risco, mas é um fator a considerar no seu threat model.

Considerações

A Mullvad não vai te mandar e-mail de "sentimos sua falta" porque nem sabe quem você é. Não vai aparecer no seu feed patrocinando um podcast. Não tem selo de "VPN mais rápida de 2024" dado por um site que recebe comissão de afiliado.

Mas faz o que promete. E no mercado de VPN, onde a maioria das empresas é basicamente uma operação de marketing com um proxy WireGuard por trás, isso vale mais do que qualquer selo.

Se privacidade é uma preocupação real e não só um checkbox no seu threat model, a Mullvad é provavelmente a escolha mais coerente que existe hoje.

Vou mostrar por que o ISP (Internet Service Provider) é o elo mais perigoso da sua cadeia de conectividade, casos reais em que provedores no Brasil e no mundo falharam (ou agiram contra seus próprios clientes) e, principalmente, o que fazer para reduzir drasticamente o poder que ele tem sobre a sua vida digital.

O problema: seu ISP vê tudo

Quando você digita um endereço no navegador, a primeira coisa que acontece é uma consulta DNS. Por padrão, essa consulta vai para o servidor DNS do seu provedor. Em texto plano. Sem criptografia. Ele sabe exatamente quais domínios você resolve, quando e com qual frequência.

Mesmo com HTTPS (que criptografa o conteúdo), o provedor ainda enxerga:

• O domínio que você está acessando (via SNI no TLS handshake)

• Os IPs de destino e origem

• O volume de dados trafegados

• Os horários de acesso

• O tipo de protocolo utilizado

Com essas informações, dá para construir um perfil comportamental completo. E muitos provedores fazem exatamente isso.

Casos reais: quando a confiança quebrou

Brasil: envenenamento de DNS na Oi e GVT

Em 2011, servidores DNS da Oi Velox e GVT foram envenenados. Ao acessar sites como o Google, os usuários eram induzidos a baixar um executável malicioso chamado Google_Setup.exe. Os arquivos continham rotinas de captura de dados. Na época, a Oi tinha cerca de 6 milhões de assinantes e a GVT, 1,4 milhão. A Oi negou o ataque. Padrão.

Brasil: dados de 28 milhões de clientes da NET/Claro à venda

Em 2020, um hacker colocou à venda em fórum da dark web dados de quase 28 milhões de clientes da antiga NET (Claro), incluindo nome completo, CPF, data de nascimento, email, telefone e endereço. A Claro informou que “não foram encontradas evidências” de que os dados fossem da empresa. Padrão, de novo.

Brasil: Claro, TIM, Vivo e Oi compartilhando dados de forma ilícita

O Ministério Público da Bahia acionou as quatro maiores operadoras por "vazamento de dados" e compartilhamento ilícito de informações pessoais, obrigando-as a obter consentimento antes de continuar tratando dados dos clientes. O relatório "Quem defende seus dados?" do InternetLab revelou que nenhuma operadora brasileira sequer avisa o usuário quando entrega dados para autoridades.

Brasil: Anatel investiga Vivo, Claro e TIM por espionagem

Em 2024, a Anatel abriu processos administrativos para apurar se Vivo, Claro e TIM sabiam de monitoramento indevido de dados de clientes e se deveriam ter notificado a agência. As operadoras disseram que só souberam pela imprensa. Se você confia nisso, eu tenho uns NFTs para te vender.

EUA: Verizon e os supercookies

A Verizon injetou silenciosamente um identificador único (X-UIDH) em todo o tráfego HTTP dos seus clientes mobile por dois anos. Esse "supercookie" não podia ser removido, desabilitado ou evitado pelo usuário. Modo incógnito? Inútil. Limpar cookies? Inútil. O rastreador era injetado no nível de rede, depois que o tráfego saía do dispositivo. A FCC multou a Verizon em US$ 1,35 milhão em 2016, o que equivale a troco de bala para uma empresa daquele porte.

A Comcast também foi flagrada injetando anúncios JavaScript nos navegadores de dispositivos conectados aos seus 3,5 milhões de hotspots WiFi.

Reino Unido: Investigatory Powers Act

Desde 2016, o "Snooper's Charter" obriga ISPs britânicos a armazenar o histórico de conexão de todos os clientes por 12 meses, acessível sem mandado judicial. O governo pode ver quais sites você acessou, quando, de qual dispositivo. Membros do parlamento são explicitamente protegidos dessa vigilância. Uma regra para eles, outra para o resto.

Turquia: ISPs como braço do Estado

Na Turquia, ISPs são obrigados a reter logs de 1 a 2 anos e, não oficialmente, a implementar Deep Packet Inspection (DPI). Quando o Twitter foi banido em 2014, os ISPs primeiro envenenaram o DNS, depois bloquearam todos os IPs do Twitter. Os turcos responderam pichando os endereços do DNS do Google (8.8.8.8 e 8.8.4.4) em muros pela cidade. O uso do Twitter no país cresceu 138%.

O Estado como ameaça: vigilância, mandados secretos e perseguição política

Se os casos acima mostram provedores falhando por incompetência, negligência ou ganância, este ponto é sobre algo pior: governos usando provedores como instrumento de vigilância em massa, com mandados secretos, sem contraditório e sem que o alvo sequer saiba que está sendo monitorado.

EUA: a FISA Court e os 3,4 milhões de buscas sem mandado

Nos Estados Unidos, a Section 702 do Foreign Intelligence Surveillance Act (FISA) permite que a NSA, o FBI e a CIA coletem comunicações de estrangeiros fora do país sem mandado judicial individualizado. Até aqui, parece razoável. O problema é o que acontece com os americanos (e qualquer pessoa que se comunique com esses alvos estrangeiros): suas mensagens, emails, ligações e textos são coletados "incidentalmente" e armazenados em bancos de dados que o FBI pode consultar livremente.

Só em 2021, o FBI realizou 3,4 milhões de buscas nessas bases sem qualquer mandado. Entre os alvos: manifestantes do Black Lives Matter (141 pessoas monitoradas por protestar contra o assassinato de George Floyd), mais de 19.000 doadores de uma campanha eleitoral, jornalistas, membros do Congresso, assessores parlamentares e, num caso particularmente absurdo, um juiz estadual que havia procurado o FBI para denunciar violações de direitos civis por um chefe de polícia local. O FBI pesquisou as comunicações dele. Do denunciante.

Essas buscas acontecem num tribunal secreto (a FISA Court) que funciona sem a presença do investigado, sem advogado de defesa e com taxa de aprovação que beira 99%. Em 2022, dos 354 pedidos de vigilância, apenas 7 foram rejeitados. O investigado nunca sabe que foi alvo. Nunca tem chance de se defender. E as empresas que recebem essas ordens são obrigadas por lei a cumpri-las e proibidas (sob gag order) de revelar que as receberam.

As National Security Letters (NSLs) são ainda piores: o FBI pode solicitar dados de provedores sem passar por juiz algum. Basta um agente atestar que a informação é "relevante para segurança nacional". A empresa é proibida de informar o usuário. É um sistema onde o Estado pode vasculhar a vida digital de qualquer cidadão sem acusação formal, sem julgamento e sem chance de defesa.

Brasil: interceptação massiva e o uso político da vigilância

No Brasil, a Lei 9.296/96 regulamenta a interceptação telemática, exigindo ordem judicial. Na teoria. Na prática, o volume de interceptações no Brasil é assustador. Em 2013, foram registrados mais de 50.000 avisos de interceptação enviados às operadoras de telecomunicações. Comparando: os EUA, com 120 milhões de habitantes a mais, autorizaram 3.576 no mesmo ano.

Em 2012, a Polícia Federal implementou o SIS (Sistema de Interceptação de Sinais), que permite interceptar qualquer comunicação na rede de uma operadora sem interação caso a caso com a telco. O sistema eliminou a necessidade de pedir cooperação técnica da operadora para cada alvo. Ou seja: a infraestrutura para vigilância em massa já está montada. Depende apenas de quem está no comando.

Em 2013, documentos revelaram que o Gabinete de Segurança Institucional da Presidência ordenou à ABIN monitorar sindicatos e movimentos sociais opositores. Líderes da ONG Xingu Vivo, que lutavam contra a construção da Usina de Belo Monte em terra indígena, foram espionados por agentes infiltrados. No estado de São Paulo, foi revelado o monitoramento de movimentos de moradia.

A LGPD (Lei Geral de Proteção de Dados) exclui explicitamente de seu escopo o tratamento de dados para fins de segurança do Estado, persecução penal e defesa nacional. Essa exceção existe para ser regulamentada por legislação específica que, até hoje, não foi criada. Resultado: há um buraco negro legal onde o Estado pode operar com pouquíssima supervisão quando o assunto é vigilância.

O problema estrutural: seu ISP é o ponto de coleta

Independente do país, o padrão se repete: o governo não precisa hackear seu dispositivo. Ele vai ao provedor, que por força de lei é obrigado a reter dados e, em muitos casos, entregar informações sem que o alvo seja notificado, sem direito a defesa e, frequentemente, sem que o próprio provedor questione a ordem.

No Reino Unido, o Investigatory Powers Act obriga a retenção por 12 meses. Na Turquia, de 1 a 2 anos. No Brasil, o Marco Civil da Internet exige guarda de registros de conexão por 1 ano e de registros de acesso a aplicações por 6 meses.

Você não precisa ser criminoso, suspeito ou investigado. Basta ser inconveniente. Jornalista investigando corrupção. Ativista ambiental. Advogado de direitos humanos. Doador de campanha. Ou simplesmente alguém que denunciou um policial corrupto, como o juiz americano espionado pelo FBI por fazer a coisa certa.

Quando seu tráfego passa em texto plano pelo provedor, quando seu DNS não é criptografado, quando você não usa VPN, cada pacote é evidência potencial num processo que pode nunca chegar ao seu conhecimento. A infraestrutura de vigilância já existe. A questão não é se ela será usada contra inocentes. A história mostra que já foi, é, e continuará sendo.

Proteger seu tráfego não é paranoia. É o mínimo de higiene digital para quem entende como funciona a cadeia de custódia entre o seu dispositivo e a internet.

O que fazer: retome o controle

1. Use seu próprio DNS

Pare de usar o DNS do provedor. Configure um provedor de DNS que respeite privacidade e ofereça filtragem:

NextDNS e ControlD se destacam pela granularidade: você escolhe quais categorias bloquear, visualiza logs em tempo real e configura perfis por dispositivo. É basicamente um Pi-hole na nuvem, sem precisar manter hardware.

2. DNS over TLS (DoT) e DNS over HTTPS (DoH)

Não basta trocar o IP do DNS. Se a consulta continuar em texto plano, o provedor ainda pode interceptar, redirecionar ou até bloquear. Por isso é fundamental usar DNS criptografado:

DoT (porta 853): Encapsula as consultas DNS em TLS. A maioria dos roteadores e sistemas operacionais modernos suporta nativamente. No Android, é o "DNS Privado" nas configurações de rede.

DoH (porta 443): Encapsula as consultas DNS dentro de HTTPS. Mais difícil de bloquear pelo provedor, porque se mistura com tráfego web normal.

No Linux, configure com systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=45.90.28.0#SEUPROFILE.dns.nextdns.io
DNSOverTLS=yes
DNSSEC=yes

Ou use o dnscrypt-proxy para DoH com ODoH (Oblivious DoH), que adiciona mais uma camada separando quem faz a consulta de quem resolve.

https://esli.blog.br/dnscrypt-dns-stamps-e-dns-criptografado-o-guia-que-faltava

3. No celular: RethinkDNS e InviZible Pro

RethinkDNS (Android): Funciona como firewall + DNS resolver. Permite configurar DoH/DoT com NextDNS, ControlD ou qualquer endpoint customizado. Bloqueia conexões por app, mostra logs em tempo real e não precisa de root. É open-source.

InviZible Pro (Android): Combina DNSCrypt + Tor + I2P + firewall. Permite rotear DNS via DNSCrypt ou Tor, enquanto o tráfego normal segue por VPN ou direto. Também open-source, disponível no F-Droid.

Se o seu Android suporta "DNS Privado" (Android 9+), configure diretamente com o hostname DoT do NextDNS, ControlD ou AdGuard. Mas o RethinkDNS oferece muito mais controle.

4. Tenha seu próprio roteador em modo bridge

O roteador que o provedor te entrega é território dele. Firmware proprietário, configurações limitadas, atualizações que ele faz (ou não faz) quando quer, e potencialmente com backdoors. A solução:

1. Mude o equipamento do seu provedor para modo bridge (bridge mode). Isso faz com que ele funcione apenas como modem, delegando toda a parte de roteamento e firewall para o seu equipamento.

2. Conecte o seu roteador na porta WAN do modem em bridge.

3. Configure no seu roteador: DNS criptografado (DoT/DoH), firewall, VPN no nível de rede e WiFi com suas próprias regras.

Se o provedor não aceitar bridge, configure o equipamento dele com DMZ apontando para o IP do seu roteador. Não é o ideal, mas remove boa parte do controle.

Roteadores recomendados para quem quer controle total: qualquer hardware que suporte OpenWrt, DDWRT, pfSense ou OPNsense. Se for algo mais acessível (ou portátil), um GL.iNet com OpenWrt pré-instalado já resolve muito.

5. VPN: sempre

Uma VPN criptografa todo o tráfego entre seu dispositivo e o servidor da VPN. Para o provedor, tudo que ele vê é uma conexão criptografada para um IP. Ele não sabe qual site você acessa, o que você baixa, nada.

O privacyguides.org recomenda três provedores: Mullvad, IVPN e ProtonVPN. Não vou repetir aqui o que já escrevi em https://esli.blog.br/qual-melhor-vpn mas o resumo é: se a VPN pede seu email para cadastro, já começou errado.

TorVPN / Tor: Para anonimato real, o Tor continua sendo a referência. Não é rápido, não é prático para tudo, mas quando você precisa que ninguém saiba o que você está fazendo (nem o provedor de VPN), é o caminho.

VPN no roteador: Configure a VPN diretamente no seu roteador (OpenWrt, pfSense, OPNsense ou GL.iNet suportam nativamente). Com isso, todos os dispositivos da rede passam pela VPN automaticamente. Smart TV, Alexa, dispositivos IoT... tudo protegido sem precisar de configuração individual.

# Exemplo: WireGuard no OpenWrt via CLI
opkg update && opkg install wireguard-tools luci-proto-wireguard
# Configure a interface e importe o .conf do seu provedor VPN

6. Navegador: configure os bloqueadores

Navegadores como Brave, Tor Browser e Mullvad Browser vêm com proteções de privacidade ativadas por padrão. Mas é possível ir além:

No Brave:

• Shields no modo agressivo

• Filtros personalizados em brave://settings/shields/filters

• Scriptlets customizados (modo desenvolvedor) para remover elementos indesejados

• DNS privado configurado nas settings do browser

Já escrevi sobre isso: https://esli.blog.br/funcoes-avancadas-no-brave-browser e mantenho meus filtros aqui: https://github.com/Esl1h/Brave-Filters-and-Scriptlets

No Tor Browser: Use como está. Não instale extensões, não altere o user agent, não maximize a janela. O Tor funciona melhor quanto menos você mexe nele.

No Mullvad Browser: Fork do Firefox mantido pela Mullvad e pelo Tor Project. Focado em anti-fingerprinting. Se você não quer usar o Tor, mas quer o máximo de privacidade sem ser Brave, essa é a opção.

Acompanhe os resultados de privacidade dos navegadores em https://privacytests.org/

7. Outras medidas

DNSSEC: Valida que a resposta DNS veio de um servidor legítimo. Protege contra envenenamento de cache. Ative no seu resolver.

ECH (Encrypted Client Hello): A evolução do ESNI. Criptografa o SNI no TLS handshake, impedindo que o provedor saiba qual domínio você está acessando mesmo em conexões HTTPS. O Brave e Firefox já suportam.

OONI Probe: Ferramenta open-source que testa se o seu provedor está censurando, bloqueando ou manipulando o tráfego. Rode periodicamente.

DNS Leak Test: Acesse https://dnsleaktest.com ou https://www.whatsmydns.net para verificar se seu DNS configurado é realmente o que está sendo usado. Se aparecer o DNS do provedor, algo está errado.

Blokada / NetGuard (Android): Se não quiser usar RethinkDNS, são alternativas para firewall e bloqueio de trackers no celular sem root.

Pi-hole / AdGuard Home (Self-hosted): Se preferir manter o controle total do DNS dentro da sua rede, sem depender de serviços externos, instale um Pi-hole ou AdGuard Home no seu servidor local (um Raspberry Pi resolve). Configure como DNS upstream o NextDNS ou Quad9 com DoT.

Resumo: a pilha de proteção

Do mais básico ao mais avançado, em ordem de implementação:

1. Troque o DNS para NextDNS, ControlD ou Quad9

2. Ative DoT/DoH em todos os dispositivos

3. Instale RethinkDNS ou InviZible no celular

4. Use Brave, Tor ou Mullvad Browser com bloqueadores configurados

5. Compre seu próprio roteador e peça bridge no do provedor

6. Configure VPN no roteador e nos dispositivos

7. Ative ECH no navegador

8. Rode OONI Probe e DNS Leak Test periodicamente

9. Self-host DNS com Pi-hole ou AdGuard Home se quiser ir além

Nenhuma dessas medidas isoladamente resolve o problema. Mas combinadas, elas transformam a visão que o provedor tem de você: de um livro aberto para uma caixa preta.

Além da rede: criptografia, autenticação e dados em repouso

Este artigo foca na proteção do tráfego contra o provedor, mas não existe segurança de rede sem segurança local. De nada adianta criptografar o DNS e usar VPN se seus dados estão em plaintext no disco, seu backup na nuvem não tem criptografia client-side e seu login depende apenas de uma senha que você reusa em 15 serviços.

Resumidamente (porque cada um desses tópicos merece artigo próprio, e já escrevi sobre vários deles):

Disco criptografado: LUKS no Linux, FileVault no macOS, BitLocker no Windows. Se o dispositivo for roubado, perdido ou apreendido, os dados ficam inacessíveis sem a chave. No Linux, encripte o disco na instalação e monte /var/log, /var/tmp e /tmp como tmpfs para não deixar rastros em disco. Swap também deve ser criptografada.

Backups e nuvem: Nunca suba arquivos para cloud storage sem criptografia client-side. O provedor de nuvem (Google, Dropbox, OneDrive) tem acesso ao conteúdo, assim como qualquer governo que solicite via mandado. Use Cryptomator para nuvem (criptografia por arquivo, transparente, funciona com qualquer provedor) ou Picocrypt para arquivos avulsos. Para containers maiores ou hidden volumes, VeraCrypt. Para quem respira terminal, Tomb (wrapper LUKS com key file separado e steganografia opcional).

2FA/MFA e chave física: Habilite autenticação de dois fatores em tudo. SMS não é 2FA seguro (SIM swap existe). Use TOTP via Aegis (Android, open-source) ou diretamente via Yubikey com o Yubico Authenticator. A Yubikey é uma chave física que suporta FIDO2, U2F, OpenPGP, PIV e TOTP. Funciona para login no sistema (via PAM no Linux), SSH (ed25519-sk), GPG e praticamente qualquer serviço que suporte WebAuthn. Se você não tem uma, considere seriamente comprar. Se tem, configure ela em tudo.

Gerenciador de senhas: Senhas únicas, complexas e armazenadas em um gerenciador com criptografia E2EE. ProtonPass, Bitwarden ou KeePassXC. Nunca reutilize senhas entre serviços.

Já escrevi em detalhes sobre tudo isso:

• Criptografia para iniciantes: https://esli.blog.br/criptografia-para-iniciantes

• Ferramentas de criptografia (VeraCrypt, Cryptomator, Picocrypt, Kryptor, Tomb): https://esli.blog.br/ferramentas-para-criptografia

• Como escolher a ferramenta certa: https://esli.blog.br/como-escolher-ferramentas-de-criptografia

• Certificados, OpenSSL, GPG e OpenPGP: https://esli.blog.br/certificados-e-openssl

• Yubikey (série completa):

  • Introdução ao 2FA: https://esli.blog.br/yubikey-introducao

  • Instalação no Linux: https://esli.blog.br/yubikey-linux-instalacao

  • 2FA no console, sudo e SSH: https://esli.blog.br/yubikey-console-sudo-ssh

  • SSH com ed25519-sk: https://esli.blog.br/yubikey-ssh-ed25519-ecdsa

  • Chaves GPG na Yubikey: https://esli.blog.br/yubikey-chaves-gpg

• Privacidade e Segurança (guia completo): https://esli.blog.br/privacidade-e-seguranca-2025

A proteção de rede que este artigo descreve é uma camada. Criptografia de dados em repouso é outra. Autenticação forte é outra. Nenhuma substitui a outra. Todas se complementam.

Conclusão

A internet é um serviço pelo qual você paga. Mas o provedor não se comporta como um simples "teletransportador" de pacotes. Ele inspeciona, registra, vende, compartilha e, quando pressionado por governos, entrega sem questionar.

Confiar no provedor com seus dados é como confiar no carteiro para não ler suas cartas. Só que o carteiro tem um scanner, uma impressora e um contrato com empresas de marketing.

A boa notícia é que as ferramentas existem e estão acessíveis. A maioria é gratuita, open-source e documentada. O custo real é o tempo de configurar. E se você chegou até aqui, provavelmente já tem esse tempo.

Use-o.

Referências e leitura complementar:

• https://privacyguides.org

• https://privacytests.org

• https://ssd.eff.org

• https://esli.blog.br/privacidade-e-seguranca-2025

• https://esli.blog.br/qual-melhor-vpn

• https://esli.blog.br/qual-melhor-navegador

• https://esli.blog.br/criptografia-para-iniciantes

TL;DR: Brave Browser + Anti Paywall + NextDNS + VPN + SponsorBlock + SmartTubeNext

The amount of ads on the internet today isn't just annoying, it's a mental health hazard. Every click, every scroll, every video is an obstacle course of banners, pop-ups, autoplaying videos, and sponsored content fighting for your attention like desperate street vendors. Blocking ads isn't just a matter of convenience anymore, it's an act of self-defense. And more than that, it's a statement: this monetization model is broken, intrusive, and unsustainable. The more people block ads, the louder the message gets: the internet needs to find a better way to fund itself without turning every screen into a billboard. Here's how to take back control across all your devices.

Brave Browser

Desktop and Smartphone: switch to Brave.
If you don't care about tokens and other built-in features… just disable them. Turn off the VPN button, remove Brave Rewards, and anything else you don't like or that made you dismiss Brave in the past.

Chrome is unbearable - it killed extensions (Manifest V3) and keeps doubling down on tracking. Brave runs on Chromium (Chromium ≠ Google Chrome).

With Brave, you can go deeper into ad blocking through filter lists and Scriptlets. But out of the box, Brave Shield already strips away almost everything.

Here are some filters and scriptlets I use to remove specific items on certain sites: https://github.com/Esl1h/Brave-Filters-and-Scriptlets

Check https://privacytests.org/ for privacy data on Brave, in case you still have doubts.

I'm currently keeping an eye on Orion Browser (Kagi) and Ladybird. My second choice is Mullvad Browser (a Firefox fork). But to match what Brave offers out of the box, you'd need to pile on extensions and spend a good while tweaking settings.

Shields (Brave)

Anti-paywall

Here I go into more detail about anti-paywall: https://esli.blog.br/pulando-o-muro-do-paywall

https://burles.co is an extension that blocks the paywall script from running (create to work with Brazilian sites + Tampermonkey).

It can be installed or run via Tampermonkey (install the Tampermonkey extension, enable developer mode, then open the burlesco.js URL and click install).

Another way to block paywalls is through Brave: click on Shields, switch to advanced mode, and block scripts. However, this will block all scripts, not just the ones responsible for the paywall.

NextDNS

Use NextDNS as your DNS. Even if you already run a Pi-Hole in your home lab, add NextDNS on top of it.

The free tier is limited to 300,000 requests per month, more than enough for regular use. With 4 or 5 devices at home (router + laptops + phones), you'll hardly this queries per month especially with caching enabled. The paid plan costs around €20/year, not that expensive, really.

Link: https://nextdns.io/?from=yes2mwwr

The blocking options, lists, and settings are quite extensive.

And once again, just like Brave Browser, besides removing ads, it also improves your security.

Set up NextDNS on all your devices. Configure it as Private DNS in Brave's settings.

Add NextDNS as Private DNS in your smartphone's advanced settings.

Set it up on your router: this effectively enables ad blocking on devices like Alexa, Smart TVs, and others.

If your phone doesn't allow changing the DNS, consider a different brand next time. But as long as it's configured on the router, you'll still get the blocking benefits when connected to your local network/Wi-Fi.

YouTube

VPN

Some countries don't have YouTube monetization, meaning content creators don't earn ad revenue from views in those regions.

By connecting a VPN on your TV or other device to one of these non-monetized countries, you may see no ads at all. Of course, things can get messy — Google might still push ads regardless.

I usually connect through Turkmenistan and Albania — no YouTube ads. Though sometimes YouTube starts showing ads as if I were in France.

Here's a list of countries without monetization: https://isthischannelmonetized.com/data/youtube-monetized-countries/

That said, I've seen some content creators apply geoblocking on their videos.

Using a VPN can block YouTube ads on your smartphone, but the best approach is to use Brave Browser and ditch the app entirely.

Blocking YouTube ads on Smart TVs

My TV is also routed through NextDNS (at the router level), which already blocks Amazon ads on FireStick/FireTV as well as ads on Android TV and Google TV.

On Google TV (updated Android TV), I installed AdGuard, but didn't get the results I wanted. NextDNS on the network plus SmartTubeNext are the best combo to remove YouTube ads on TV and strip out the other ads that show up in the TV's OS or inside other apps.

SmartTubeNext

For FireTV, Android, and Google TV: https://smarttubenext.com/

Install SmartTubeNext. On FireStick, enable developer mode (go to My Fire TV, click the FireStick info several times). Download the Downloader app (there's no way to download it through the default Silk browser on FireStick), then open the SmartTubeNext website inside Downloader, download it, and install.

https://smarttubenext.com/firestick/

It blocks all ads including sponsored segments within videos.

The player and display settings are highly customizable.

If you're not using an Amazon FireTV Stick, use this link for Android TV: https://smarttubenext.com/android-tv-box/

SponsorBlock

The secret behind SmartTubeNext and other YouTube frontends — whether on Smart TVs or any other device — is SponsorBlock: https://sponsor.ajay.app/

It's available as a component across many apps that block YouTube ads on Android, Android TV, Google TV, as a Tampermonkey userscript, in players like MPV, Kodi, Chromecast, Roku, Apple TV, iOS, desktop systems (Windows, Linux, and macOS), and finally as a browser extension. Full list here: https://github.com/ajayyy/SponsorBlock/wiki/3rd-Party-Ports

With SponsorBlock — on any app, any device, any operating system — it will automatically skip video segments containing sponsored content, intro animations, end cards and credits, subscribe/like/comment prompts, paid promotions, and in-video ads.

A solução? Uma zsh function que detecta o package manager e faz tudo com um único comando: sysup.

Mas antes de chegar nela, vale entender como o Zsh organiza esse tipo de extensão.

A estrutura ~/.zsh/

O Zsh permite organizar customizações em diretórios dedicados. Uma convenção comum (e que uso nos meus dotfiles):

~/.zsh/
├── functions/     # Funções carregadas sob demanda (autoload)
├── completions/   # Scripts de completion customizados (_comando)

functions/

Cada arquivo é uma função. O nome do arquivo = nome da função. Sem extensão, sem shebang. O Zsh carrega o conteúdo do arquivo como corpo da função quando ela é chamada pela primeira vez — isso é o autoload.

completions/

Segue a mesma lógica, mas para funções de completion (_nome). Se você escreve um CLI próprio e quer tab-completion, é aqui que o script de completion fica.

As 4 linhas no ~/.zshrc

fpath=(~/.zsh/functions $fpath)
autoload -Uz ~/.zsh/functions/*(N:t)
autoload -Uz compinit && compinit
autoload -Uz promptinit && promptinit

Linha 1: fpath=(~/.zsh/functions $fpath)

Adiciona ~/.zsh/functions/ ao fpath (function path) — o equivalente do $PATH, mas para funções do Zsh. O Zsh só encontra funções via autoload se elas estiverem em algum diretório listado no $fpath. Ao prepend (~/.zsh/functions antes de $fpath), suas funções têm prioridade sobre as do sistema.

Se tiver um diretório completions/, adicionaria da mesma forma:

fpath=(~/.zsh/completions ~/.zsh/functions $fpath)

Linha 2: autoload -Uz ~/.zsh/functions/*(N:t)

Registra todas as funções do diretório para autoload.

Dissecando:

O :t é essencial. Sem ele, o autoload receberia /home/user/.zsh/functions/sysup em vez de apenas sysup.

A função não é carregada em memória nesse momento. O Zsh apenas registra que, quando sysup for chamado, deve buscar e carregar o arquivo correspondente. Lazy loading puro.

Linha 3: autoload -Uz compinit && compinit

Carrega e inicializa o sistema de completion do Zsh. O compinit escaneia o $fpath procurando arquivos _* (prefixo underscore) e os registra como funções de completion. Sem isso, nenhum tab-completion customizado funciona.

Linha 4: autoload -Uz promptinit && promptinit

Carrega o sistema de temas de prompt. Permite usar prompt -l para listar temas disponíveis e prompt <tema> para aplicar. Útil se você usa temas de prompt distribuídos via $fpath, embora quem usa Starship ou p10k (meu caso) talvez nunca toque nisso.

O Sysup

Código completo: dotfiles/.zsh/functions/sysup

# Description: Dynamic package manager detection and global system update
# Usage: sysup

_sysup_log() {
  print -P "%F{blue}==>%f %B$1%b"
}

# 1. Universal Package Managers (Sandboxed)
if command -v flatpak &>/dev/null; then
  _sysup_log "Updating Flatpaks..."
  flatpak update -y
fi

if command -v snap &>/dev/null; then
  _sysup_log "Refreshing Snaps..."
  sudo snap refresh
fi

# 2. Native System Package Managers
if command -v dnf &>/dev/null; then
  _sysup_log "Running DNF Update..."
  sudo dnf update -y
elif command -v yay &>/dev/null; then
  _sysup_log "Running Yay (AUR/Pacman)..."
  yay -Syu --noconfirm
elif command -v pacman &>/dev/null; then
  _sysup_log "Running Pacman..."
  sudo pacman -Syu --noconfirm
elif command -v apt &>/dev/null; then
  _sysup_log "Running APT..."
  sudo apt update && sudo apt upgrade -y
elif command -v yum &>/dev/null; then
  _sysup_log "Running YUM..."
  sudo yum update -y
elif command -v zypper &>/dev/null; then
  _sysup_log "Running Zypper..."
  sudo zypper patch
fi

_sysup_log "System update completed."

Lógica

O script faz detecção dinâmica de package manager via command -v e executa o update apropriado.

Divide em duas categorias:

1. Package managers universais (sandboxed) — sempre executados se presentes:

if command -v flatpak &>/dev/null; then
  _sysup_log "Updating Flatpaks..."
  flatpak update -y
fi
if command -v snap &>/dev/null; then
  _sysup_log "Refreshing Snaps..."
  sudo snap refresh
fi

Flatpak e Snap coexistem com o gerenciador nativo, então ambos rodam independentemente (blocos if paralelos, não elif).

2. Package manager nativo — mutuamente exclusivo:

if command -v dnf &>/dev/null; then
  sudo dnf update -y
elif command -v yay &>/dev/null; then
  yay -Syu --noconfirm
elif command -v pacman &>/dev/null; then
  sudo pacman -Syu --noconfirm
elif command -v apt &>/dev/null; then
  sudo apt update && sudo apt upgrade -y
elif command -v yum &>/dev/null; then
  sudo yum update -y
elif command -v zypper &>/dev/null; then
  sudo zypper patch
fi

A cadeia elif garante que apenas um gerenciador nativo execute. A ordem importa:

• yay antes de pacman: se yay está instalado, é preferível porque já cobre AUR + repositórios oficiais

• dnf antes de yum: em distros modernas baseadas em Red Hat, dnf é o padrão

• apt cobre Debian/Ubuntu

Detecção com command -v

O command -v é preferível a which porque:

• É um builtin do shell (não depende de binário externo)

• Retorna 0/1 de forma confiável

• which tem comportamentos inconsistentes entre distros

O redirecionamento &>/dev/null suprime stdout e stderr — queremos apenas o exit code.

Usando…

Só chamar o sysup

Só… Simples, rápido, fácil… sem reinventar a roda, sem precisar de milhares de validações, variáveis e etc. Pois conheço meu ambiente.

Uma função, qualquer máquina. Os mesmos dotfiles sincronizados via Git em todas as máquinas, e cada uma executa o caminho correto automaticamente.

O código está disponível no repositório dotfiles — com o resto da minha configuração de Zsh.

LLMs de última geração já conseguem concluir grandes subtarefas ou projetos de médio porte sozinhos, com pouca assistência humana, caso recebam um conjunto razoável de orientações sobre o resultado esperado. O grau de sucesso varia conforme o tipo de problema — quanto mais isolado e representável textualmente, melhor (programação de sistemas é particularmente adequada) — e depende da capacidade do programador de criar uma representação mental clara do problema para comunicá-la ao modelo.

Mas, em termos gerais, escrever código manualmente para a maioria dos projetos já não faz sentido prático, a não ser por diversão.

A economia é irrelevante para a tendência

Não importa se as empresas de IA não conseguirão recuperar seus investimentos e o mercado de ações entrar em colapso. Não importa se algum CEO de unicórnio está dizendo algo desanimador ou absurdo. A tecnologia já escapou da garrafa. A longo prazo, o que importa é que a capacidade existe e continuará evoluindo — independentemente de quem sobreviva comercialmente.

Não há como retroceder... Mesmo que a tal "Bolha da IA" exploda, os modelos, os datasets, projetos open-source e repositórios continuarão existindo, nada impedirá ninguém de baixar um modelo (específico para sua necessidade) e rodar em sua máquina pessoal, home-server, VPS ou conta em algum cloud provider.

Democratização e centralização

Essa tecnologia é importante demais para ficar nas mãos de poucas empresas. Por enquanto, existe uma democratização suficiente: modelos abertos — especialmente os produzidos na China — continuam competindo com modelos de fronteira de laboratórios fechados. O fato de OpenAI, Anthropic e Google estarem tão próximos em resultados há anos sugere não haver “mágica” proprietária suficiente para impedir que outros alcancem o mesmo nível.

O conselho prático

Não importa o que você acredite sobre o que deveria ser o “certo” — você não pode controlar a situação recusando o que está acontecendo. Ignorar a IA não vai ajudar você nem sua carreira.

Teste essas ferramentas com seriedade. Semanas de trabalho real, não um teste de cinco minutos onde você apenas reforça suas próprias crenças. Encontre uma maneira de se multiplicar. Se não funcionar, tente novamente a cada poucos meses — a evolução é rápida.

E sim, talvez você tenha trabalhado muito para aprender a programar, e agora máquinas fazem boa parte do trabalho por você. Mas pense no que realmente te motivava quando ficava até de madrugada codando: era construir. E agora você pode construir mais e melhor, se encontrar uma forma eficaz de usar IA.

A diversão continua lá, intocada.

Pare de chamar tudo de “Vibe Coding”

Existe uma confusão proposital — ou preguiçosa — em chamar qualquer uso de IA para gerar código de “vibe coding”. Vibe coding é quando alguém descreve o que quer em termos vagos, aceita o que o LLM cuspir, e no máximo reporta que algo não funcionou. O vibe coder não entende o código, não direciona a arquitetura, não intervém no design. E tudo bem — isso tem seu lugar e democratiza a criação de software para quem não é programador.

Mas quando um programador experiente usa IA como ferramenta de produção — com visão clara do que precisa ser feito, direcionando o design, revisando a saída, intervindo na implementação quando necessário e aplicando o resultado em ambiente controlado — isso não é “vibe coding”.

Segundo o Antirez, isso é programação automática: o software segue a visão do produtor, e o código gerado é dele. Precisamos de outro termo porque a diferença não é cosmética, é qualitativa. Os resultados de um mesmo LLM variam drasticamente dependendo de quem está no comando — da intuição, do direcionamento contínuo e da ideia de software que o humano carrega.

Chamar ambos os processos pelo mesmo nome apaga essa distinção e, de quebra, desvaloriza o trabalho de quem sabe o que está fazendo.

Os dados de pré-treinamento foram produzidos por humanos. O código aberto que alimentou esses modelos é nosso presente coletivo — e o que fazemos com essa capacidade amplificada é produção nossa. Programação agora é automática. Visão, ainda não.

LLMs nos ajudarão a escrever software melhor, mais rápido, e permitirão que equipes pequenas compitam com empresas maiores — da mesma forma que o software de código aberto fez nos anos 90. O código aberto democratizou o acesso à infraestrutura. A IA está democratizando a capacidade de construir sobre ela.

Referências:

Automatic programming - https://antirez.com/news/159

Don't fall into the anti-AI hype - https://antirez.com/news/158

Para quem trabalha com SRE/DevOps, o apelo é óbvio: automação de tarefas repetitivas, geração de scripts de migração, troubleshooting de configurações Terraform, análise de logs, criação de runbooks. A possibilidade de rodar tudo localmente — sem enviar código proprietário ou dados sensíveis para APIs externas — é o que separa essas ferramentas das alternativas SaaS. Compliance, air-gapped environments, dados de clientes: tudo isso importa quando você é responsável pela infraestrutura.

Este artigo lista as principais ferramentas open source disponíveis, organizadas por categoria. O foco é praticidade: o que cada uma faz, onde roda, e por que você deveria (ou não) considerar.

Plataformas de Inferência Local (LLM Runners)

Antes de rodar qualquer agente, você precisa de um runtime para executar os modelos. Estas são as fundações:

Ollama — https://ollama.ai
Runtime minimalista para execução de LLMs locais via CLI. Um ollama run llama3 e você tem um modelo rodando. API compatível com OpenAI, o que significa que qualquer ferramenta que fale com a API da OpenAI pode apontar para seu Ollama local. Suporta tool calling nativo, essencial para agentes. Para SRE, é a forma mais rápida de ter um LLM disponível para scripts, pipelines ou integração com outras ferramentas. Deploy via binário ou container Docker.

LocalAI — https://localai.io
Se Ollama é o canivete suíço, LocalAI é a caixa de ferramentas completa. Drop-in replacement para a API OpenAI, mas vai além: suporta geração de imagens, áudio, transcrição (Whisper), text-to-speech. O módulo LocalAGI adiciona capacidade de agentes autônomos; LocalRecall oferece busca semântica. Funciona em CPU — não exige GPU. Ideal para ambientes on-premise onde você quer uma stack AI completa sem depender de cloud.

LM Studio — https://lmstudio.ai
Interface gráfica para download e execução de modelos do Hugging Face. Servidor OpenAI-compatible embutido. Closed-source mas gratuito para uso pessoal. Útil para testar modelos antes de colocar em produção, ou para membros da equipe que preferem GUI. Otimizado para Apple Silicon e NVIDIA.

Jan — https://jan.ai
Alternativa 100% open-source ao ChatGPT para execução offline. Desktop app com download de modelos integrado, API local compatível com OpenAI (porta 1337 por padrão). Zero telemetria, dados armazenados localmente. Para quem precisa de uma interface amigável mas não quer abrir mão do controle.

GPT4All — https://gpt4all.io
Focado em rodar LLMs quantizados em hardware consumer-grade. Suporta 100+ modelos, interface desktop multiplataforma. A proposta é democratização: rodar AI em qualquer máquina, sem requisitos de hardware exóticos.

AnythingLLM — https://anythingllm.com
Workspace para RAG (Retrieval-Augmented Generation) e chat com documentos. Conecta com múltiplos providers (Ollama, OpenAI, Azure), vector stores integrados, AI agents com tool calling. Deploy via Docker ou desktop app. Para SRE, é interessante para criar bases de conhecimento pesquisáveis sobre runbooks, documentação de infra, post-mortems.

Agentes de Código para Terminal e IDEs

Para quem vive no terminal, estas ferramentas integram AI diretamente no fluxo de trabalho CLI:

Aider — https://aider.chat | https://github.com/Aider-AI/aider
Pair programming no terminal. O Aider mapeia seu codebase completo, entende a estrutura do projeto, e faz edições cirúrgicas. Commits automáticos com mensagens descritivas. Suporta 30+ linguagens e qualquer LLM (Claude, GPT-4, modelos locais via Ollama). Top scores no SWE-Bench, o benchmark mais respeitado para coding agents. Para SRE: ideal para refatorar scripts Terraform, atualizar Ansible playbooks, ou gerar testes para módulos de infraestrutura. O fluxo é simples: aider arquivo.tf, descreve o que quer, e o Aider aplica as mudanças diretamente.

Open Interpreter — https://openinterpreter.com | https://github.com/openinterpreter/open-interpreter
Interface natural language para seu computador. Diferente de outros agentes que só editam código, o Open Interpreter executa: roda scripts, manipula arquivos, interage com APIs, instala pacotes. Você descreve o que quer em linguagem natural; ele traduz para comandos e executa. Suporta modelos locais via Ollama/LM Studio. Para DevOps, é útil para tarefas ad-hoc: "analise os logs do nginx das últimas 24h e me diga quais IPs geraram mais 5xx" ou "crie um script que faça backup incremental desses diretórios para S3".

OpenCode — https://opencode.ai | https://github.com/sst/opencode
CLI com TUI (Terminal User Interface) construída em Go. 60k+ stars, usado por 650k+ devs/mês. Suporta múltiplos providers (OpenAI, Anthropic, Gemini, Bedrock, Groq, Azure, modelos locais). Session management persistente com SQLite, integração LSP para code intelligence. Diferencial: integração com GitHub Actions — você pode invocar o OpenCode em PRs e issues via comentários. Plan mode para revisar mudanças antes de aplicar. Disponível também como desktop app.

Goose (Block) — https://block.github.io/goose | https://github.com/block/goose
Framework de agentes da Block (a empresa por trás do Square e Cash App). Escrito em Rust, executa 100% local. Vai além de código: instala dependências, executa comandos, testa, debugga, interage com APIs externas. Suporte completo a MCP (Model Context Protocol) — o padrão da Anthropic para extensibilidade de ferramentas. Desktop app e CLI. Agnóstico ao modelo. A Block reportou que engenheiros internos economizam ~20% do tempo em tarefas de manutenção usando o Goose. O fato de ser open-source (Apache 2.0) e ter backing de uma empresa do porte da Block dá confiança para uso enterprise.

Plandex — https://plandex.ai | https://github.com/plandex-ai/plandex
Agente para projetos grandes. Suporta 2M tokens de contexto efetivo, diff review em sandbox isolado (mudanças ficam separadas do projeto até você aprovar), commits controlados. Combina modelos de múltiplos providers. Terminal-based workflow robusto para quem trabalha com codebases extensos. Nota: a versão cloud foi descontinuada em outubro/2025, mas funciona self-hosted com Docker ou servidor próprio.

Cline — https://cline.bot | https://github.com/cline/cline
O agente open-source mais popular para VSCode, com 4M+ de downloads. Funciona em dois modos: Plan (planeja as mudanças) e Act (executa). Human-in-the-loop obrigatório — cada mudança requer aprovação, o que é bom para ambientes onde você não quer surpresas. Executa comandos no terminal integrado, browser automation para testes, criação/edição de arquivos. Extensível via MCP: você pode criar ferramentas customizadas ("add a tool that fetches Jira tickets" e o Cline cria e instala o MCP server). Suporta qualquer provider: OpenRouter, Anthropic, OpenAI, Gemini, Bedrock, Ollama, LM Studio.

Roo Code — https://roocode.com | https://github.com/RooCodeInc/Roo-Code
Fork do Cline com foco em multi-agent workflows. A ideia é ter um "time" de agentes especializados: Architect (planeja estrutura), Code (implementa), Debug (investiga erros), Ask (responde perguntas). Você pode criar Custom modes ilimitados: QA Engineer, Product Manager, Security Auditor — cada um com prompts e ferramentas específicas. Suporte a VSCode e JetBrains. O Roo Cloud permite delegar trabalho para agentes rodando remotamente, acionáveis via Slack ou GitHub. Para equipes de platform engineering, a possibilidade de ter agentes especializados em diferentes aspectos (segurança, performance, compliance) é interessante.

Kilo Code — https://kilo.ai | https://github.com/Kilo-Org
Lançado em março/2025, já acumulou 250k+ instalações e 10k+ stars. Diferencial: suporta 400+ modelos sem necessidade de configurar API keys (provider integrado opcional). Orchestrator mode decompõe tarefas complexas em subtasks executados por agentes especializados. Memory Bank mantém contexto persistente entre sessões. Suporta VSCode, JetBrains, Cursor, Windsurf e CLI standalone.

Continue — https://continue.dev | https://github.com/continuedev/continue
Plataforma para criar assistentes AI customizáveis. 26k+ stars. Três modos: Chat (conversa sobre código), Plan (cria plano de implementação), Agent (executa mudanças). CLI com TUI e modo headless para CI/CD. Configuração via .continue/rules/ permite definir padrões de equipe que o AI segue. Integração MCP com GitHub, Sentry, Snyk, Linear — o agente pode buscar contexto de issues, alertas de segurança, erros de produção. Para DevOps, a possibilidade de rodar em modo headless dentro de pipelines CI/CD abre cenários interessantes: code review automatizado, geração de changelog, atualização de documentação.

Qodo Gen (anteriormente Codium) — https://www.qodo.ai
Plataforma "quality-first" com 751k instalações no VSCode. Foco em geração de código, testes unitários e documentação com ênfase em code correctness. Menos autônomo que outros — a proposta é assistência com garantia de qualidade, não automação total. Para times que precisam de cobertura de testes mas não têm tempo de escrever, é uma opção pragmática.

Plataformas Low-Code / No-Code para Agentes

Para quem prefere construir workflows visualmente ou precisa de algo mais acessível para membros não-técnicos da equipe:

n8n — https://n8n.io | https://github.com/n8n-io/n8n
Plataforma de automação visual com 400+ integrações e suporte nativo a AI agents via LangChain. Self-hosted, fair-code license. Combina workflows tradicionais (webhooks, APIs, bancos de dados) com capacidades de LLM e RAG. Para SRE, é útil para criar automações que combinam AI com sistemas existentes: "quando um alerta do PagerDuty chegar, busque logs relacionados, gere um resumo, e poste no canal do Slack". A curva de aprendizado é menor que escrever tudo em código.

Flowise — https://flowiseai.com | https://github.com/FlowiseAI/Flowise
Builder visual drag-and-drop para aplicações LLM, baseado em LangChain. Suporta RAG, chatbots, agents com tool calling. Deploy via Docker, API REST exposta automaticamente. Interface amigável para prototipagem rápida. Útil para criar POCs de assistentes internos antes de investir em desenvolvimento custom.

Langflow — https://langflow.org | https://github.com/langflow-ai/langflow
Plataforma low-code para AI agents e MCP servers. Editor visual Python-based. Self-hosted only (MIT license). Mais técnico que Flowise, com maior flexibilidade para customização.

Dify — https://dify.ai | https://github.com/langgenius/dify
Plataforma all-in-one com 114k+ stars. Visual workflow builder, RAG pipelines, agent capabilities, observability integrada. Suporta deploy local ou cloud, múltiplos LLM providers. Para times que querem uma solução completa sem montar stack from scratch.

Frameworks de Agentes Multi-Purpose

Para quem quer construir sistemas de agentes customizados ou precisa de mais controle:

AutoGPT — https://agpt.co | https://github.com/Significant-Gravitas/AutoGPT
Um dos primeiros frameworks de agentes autônomos, com 177k+ stars. Plataforma low-code para criação de agentes goal-driven. Interface visual drag-and-drop, execução contínua em cloud (ou self-hosted), suporte a múltiplas ferramentas. A proposta é definir um objetivo e deixar o agente decompor em subtasks e executar autonomamente. Comunidade ativa, mas requer cuidado com autonomia excessiva em ambientes de produção.

CrewAI — https://crewai.com | https://github.com/crewAIInc/crewAI
Framework Python para sistemas multi-agente com abstração de "crews" (equipes). Cada agente tem role/goal/backstory específicos e colaboram em workflows estruturados. CrewAI Studio oferece interface visual. Ideal para simular equipes: um agente pesquisa, outro analisa, outro implementa. Para DevOps, pode ser usado para criar pipelines de análise onde diferentes agentes cuidam de aspectos específicos (segurança, performance, compliance).

LangChain / LangGraph — https://langchain.com | https://github.com/langchain-ai/langchain
Framework modular para construção de aplicações LLM. LangGraph adiciona orchestration baseada em grafos com estado persistente, branching e error recovery. Fundação para muitas das ferramentas listadas aqui. Mais baixo nível — você constrói os agentes em vez de usar prontos.

AutoGen (Microsoft) — https://microsoft.github.io/autogen | https://github.com/microsoft/autogen
Framework event-driven para sistemas multi-agente com conversação estruturada. Suporta workflows determinísticos e dinâmicos, extensível via MCP servers. Foco em colaboração entre agentes especializados. Backing da Microsoft dá credibilidade para uso enterprise.

MetaGPT — https://github.com/geekan/MetaGPT
Simula estrutura de empresa de software com agentes assumindo roles: PM, Architect, Engineer, QA. Gera documentação, código e testes de forma coordenada. Interessante para prototipagem de features completas.

Ferramentas Especializadas

PrivateGPT — https://privategpt.io | https://github.com/zylon-ai/private-gpt
API production-ready para RAG 100% privado. Ingestion de documentos, chat contextual, tudo offline. Baseado em LlamaIndex, API compatível com OpenAI. Para ambientes com dados sensíveis onde nada pode sair da rede. Casos de uso: chat com documentação interna, análise de logs confidenciais, base de conhecimento para runbooks.

Huginn — https://github.com/huginn/huginn
Plataforma self-hosted para criação de agentes que monitoram web, coletam dados e executam ações baseadas em triggers. Inspirado no IFTTT mas totalmente controlável. Mais voltado para automação de data pipelines e monitoramento do que coding, mas útil no toolkit de SRE.

OpenHands (anteriormente OpenDevin) — https://github.com/All-Hands-AI/OpenHands
Agente autônomo de engenharia de software. Opera em nível de repositório, faz changes multi-file, executa testes em sandbox, debugging iterativo. Mais autônomo que a maioria — a proposta é delegar features inteiras.

Comparativo Resumido

Conclusão

O ecossistema de AI coding agents open source amadureceu significativamente. Não estamos mais falando de demos interessantes ou projetos de fim de semana — são ferramentas com milhões de usuários, backing de empresas como Block e Microsoft, e comunidades ativas de contribuidores.

Para SRE/DevOps, o valor está em três frentes:

1. Automação de tarefas repetitivas: geração de scripts, atualização de configurações, migração de código. O tempo que você gastaria escrevendo um script de migração de Terraform pode ser reduzido drasticamente.

2. Troubleshooting assistido: análise de logs, correlação de eventos, sugestão de fixes. Quando são 3h da manhã e você está olhando para um stack trace incompreensível, ter um assistente que entende o contexto do seu codebase ajuda.

3. Documentação e conhecimento: RAG sobre runbooks, post-mortems, documentação de arquitetura. A maioria das equipes tem conhecimento tribal que nunca foi documentado adequadamente. Ferramentas como PrivateGPT ou AnythingLLM permitem criar bases pesquisáveis sem expor dados sensíveis.

A execução local é o diferencial crítico. Em ambientes enterprise, enviar código para APIs externas frequentemente não é opção. A combinação de Ollama (ou LocalAI) com qualquer dos agentes listados permite operação 100% on-premise, air-gapped se necessário.

Minha recomendação para quem está começando:

• Para terminal: comece com Aider. É maduro, bem documentado, e o fluxo é intuitivo.

• Para IDE: Cline é o mais estabelecido. Roo Code se você quer experimentar multi-agent.

• Para automação visual: n8n se você já trabalha com workflows; Flowise se o foco é RAG.

• Para rodar modelos locais: Ollama. Simples, funciona, comunidade grande.

O MCP (Model Context Protocol) está se tornando o padrão de fato para extensibilidade. Se você for investir tempo aprendendo uma tecnologia, MCP é onde eu colocaria fichas. A maioria das ferramentas novas já suporta, e a tendência é consolidação em torno desse protocolo.

Por fim: essas ferramentas são tão boas quanto o modelo que você usa e o contexto que você fornece. Um agente com um modelo fraco ou sem acesso ao contexto relevante vai gerar lixo. A engenharia de prompts e a curadoria do que o agente pode acessar continuam sendo responsabilidade sua.

O futuro é agentic. A questão não é se você vai usar essas ferramentas, mas quando — e se vai ser com controle sobre seus dados ou entregue para um SaaS.