O desktop remoto é seguro? Um modelo de ameaças honesto

"Is remote desktop secure" tem respostas diferentes dependendo de qual desktop remoto estamos falando. O RDP nativo do Windows exposto à internet pública é uma das superfícies de ataque mais exploradas na TI corporativa; aparece na seção de ransomware do DBIR da Verizon todo ano. Um cliente moderno baseado em relé como Tenvo, AnyDesk ou TeamViewer, que nunca expõe uma porta ouvindo para a internet, tem uma postura de segurança fundamentalmente diferente. Este artigo percorre o modelo de ameaças honestamente: o que é realmente protegido, o que não é, e o que você deve verificar antes de instalar qualquer ferramenta de desktop remoto.

Resumo: A criptografia do transporte (AES-256-GCM) e a troca de chaves (X25519 + ED25519 para assinaturas) já são requisitos básicos; a maioria das ferramentas reputadas os adota. A variação interessante está em o que o relé pode ver, como o acesso não assistido é tratado, se 2FA é exigido e se o código-fonte pode ser auditado. Vá para o checklist de 5 itens no final se você quer só as ações.

O modelo de ameaças: contra o que você está realmente se defendendo?

Três classes de adversário importam para desktop remoto:

• Atacante de rede (passivo ou ativo MITM). Alguém na mesma Wi‑Fi, alguém rodando um nó de saída VPN malicioso, um ator estatal fazendo interceptação TLS em larga escala. Querem ler ou modificar o tráfego entre cliente e host.
• Atacante de credenciais. Alguém tentando logar no acesso não assistido com a senha. Força bruta, credential stuffing, busca em bancos de dados vazados.
• Atacante do fornecedor/relé. A própria empresa do desktop remoto, ou alguém que a comprometeu. Por definição estão no meio; o que eles conseguem realmente ver?

Uma quarta classe, comprometimento do endpoint (malware em qualquer das máquinas), derrota toda ferramenta de desktop remoto já feita. Se seu PC local estiver comprometido, nenhum protocolo de criptografia salva você. Não cobriremos isso aqui porque está fora do escopo do protocolo em si.

Criptografia do transporte: AES-256-GCM

Tenvo criptografa a conexão com TLS e um certificado por dispositivo. O algoritmo mais discutido nesse contexto é o AES-256-GCM, um modo de cifragem autenticado que protege confidencialidade (sem escuta) e integridade (sem adulteração). GCM é o mesmo modo de cifra que o TLS 1.3 usa, o mesmo que seu banco usa, o mesmo que o Signal Protocol usa na camada simétrica. Não há ataques práticos conhecidos contra AES-256-GCM até 2026.

A chave de sessão tem 256 bits, é derivada por sessão e nunca é reutilizada. Mesmo que uma chave fosse recuperada depois dos fatos, apenas aquela sessão seria comprometida; sessões passadas e futuras são independentes.

Troca de chaves: X25519 + ED25519

Como os dois clientes concordam em uma chave de sessão sem que o relé a aprenda? X25519, um Diffie‑Hellman de curva elíptica sobre Curve25519. Cada lado gera um par de chaves efêmero, troca chaves públicas através do relé e calcula independentemente o mesmo segredo compartilhado usando sua chave privada e a chave pública do outro lado. O relé vê apenas os valores públicos, inúteis sem uma das chaves privadas.

Para prevenir um man‑in‑the‑middle ativo (um relé malicioso ou comprometido trocando as chaves públicas no meio do caminho), a identidade pública do host é assinada com ED25519. Na primeira vez que você conecta a um host, Tenvo mostra a impressão digital da chave do host; esse é o modelo trust‑on‑first‑use (TOFU), o mesmo do SSH. Em conexões subsequentes, o cliente verifica se a impressão digital bate; se um relé tentasse MITM, a impressão mudaria e o cliente recusaria a conexão.

X25519 + ED25519 é o mesmo conjunto de primitivos usado por WireGuard, Signal, age e SSH moderno. É amplamente auditado e considerado a melhor prática atual.

O que o relé realmente vê

Essa é a questão que separa as ferramentas de desktop remoto de forma significativa. Alguns produtos terminam o TLS no relé e recriptografam para o cliente — isso significa que o fornecedor tecnicamente pode descriptografar sua sessão. Pergunte qual modelo se aplica à ferramenta que você está avaliando, inclusive esta: Tenvo é end‑to‑end em uma conexão peer‑to‑peer direta, e termina o TLS no relé quando uma conexão direta não pode ser estabelecida.

Dois apontamentos sobre a tabela. Primeiro, "o fornecedor afirma que o relé vê apenas o texto cifrado" é algo que temos que aceitar na fé em produtos proprietários; sem acesso ao código‑fonte você não pode verificar isso. Segundo, o VNC clássico sobre a internet aberta é a pior opção nesta lista: muitas variantes de VNC são distribuídas sem criptografia de transporte por padrão, e credenciais são enviadas num challenge‑response que está quebrado há anos. Não rode VNC puro pela internet.

Autenticação: senhas vs 2FA

Para acesso não assistido (onde você configura uma senha no host para poder conectar depois sem alguém aceitar o prompt), a senha é toda a defesa. Dois modos de falha:

1. Senha fraca: Um PIN de 4 dígitos é quebrável por força bruta em segundos. Uma senha alfanumérica de 6 caracteres é quebrável em horas dado acesso de rede. Use 12+ caracteres gerados por um gerenciador de senhas. Tenvo exige mínimo de 6 caracteres e avisa sobre senhas comuns; recomendamos 16+ para qualquer host não assistido acessível pela internet.
2. Sem segundo fator: Se a senha vazar, ela representa toda a autenticação. Habilite 2FA se sua ferramenta suportar; Tenvo suporta TOTP para tiers pagos. AnyDesk e TeamViewer têm ofertas semelhantes.

Para sessões interativas de suporte (onde alguém te lê um código de uso único), a ameaça é muito menor porque a sessão é limitada no tempo e o código expira. O ataque clássico aqui é engenharia social, convencendo vítimas a ler o código para golpistas — os golpes de "suporte técnico" usam exatamente esse vetor, e nenhuma quantidade de criptografia corrige isso.

Risco do acesso não assistido

O acesso não assistido é o recurso mais útil e o de maior risco. Por definição, você está deixando uma credencial no host que, se vazada, permite que qualquer pessoa faça login remotamente sem prompt. Práticas recomendadas:

• Use uma senha única por host. Não reutilize a senha entre máquinas.
• Habilite 2FA onde suportado.
• Defina um tempo limite de inatividade para que sessões não assistidas ociosas se desconectem. O padrão do Tenvo é 4 horas.
• Use a lista de permissão de acesso, limite conexões de entrada a IDs de dispositivo específicos que você controla. Tenvo suporta isso nas configurações de segurança.
• Monitore o log de conexões periodicamente. Conexões inesperadas são um sinal vermelho.

Por que expor RDP nativo à internet é particularmente ruim

O RDP em si não é inseguro; a Microsoft endureceu significativamente o protocolo, e versões recentes usam CredSSP protegido por TLS. O problema é operacional. O RDP escuta numa porta bem conhecida (3389), geralmente é autenticado apenas por uma senha do Windows e é alvo constante de varredura por força bruta. Uma vez que um atacante entra, ele tem uma sessão interativa do Windows logada — o ponto de apoio mais útil possível para implantação de ransomware. Por isso a CISA e o FBI citam especificamente RDP exposto como um dos top‑3 vetores iniciais de acesso para ransomware. Ferramentas como Tenvo, AnyDesk e TeamViewer evitam o problema inteiramente por nunca exporem um serviço ouvindo na internet pública.

O checklist de 5 itens para qualquer ferramenta de desktop remoto

Qualquer que seja a ferramenta que você escolher, verifique estes cinco itens antes de confiá‑la com algo importante:

1. Criptografia de transporte end‑to‑end com AES-256 ou ChaCha20-Poly1305. Qualquer coisa inferior (sem criptografia, RC4, VNC puro) é desqualificadora. Verifique a documentação, não a página de marketing.
2. Troca de chaves com segredo posterior (Diffie‑Hellman de algum tipo). X25519 é o padrão moderno. ECDH P‑256 é aceitável. Troca estática por RSA é um sinal de alerta.
3. Modelo de relé documentado: o fornecedor vê ciphertext ou plaintext? Leia o whitepaper de segurança. Se não souberem responder, saia fora.
4. Autenticação de dois fatores para acesso não assistido. Se sua ferramenta não oferecer 2FA, não habilite acesso não assistido em hosts acessíveis pela internet.
5. Código‑fonte ou auditoria de terceiros que você possa ler. Open source (como Tenvo/RustDesk sob AGPL-3.0) é a evidência mais forte. Se não houver, um relatório SOC 2 Type II ou um pentest publicado é aceitável.

Conclusão

"Is remote desktop secure" é a pergunta errada. A correta é: qual desktop remoto e implantado como. Uma ferramenta moderna baseada em relé com transporte AES-256-GCM, troca de chaves X25519, criptografia end‑to‑end além do relé e 2FA no acesso não assistido é, grosso modo, tão segura quanto qualquer outro protocolo da internet em que você confia diariamente. RDP exposto em uma porta encaminhada com senha fraca não é. Leia a arquitetura completa de segurança do Tenvo para detalhes ao nível de protocolo, ou baixe o cliente e audite você mesmo; o código‑fonte está no GitHub.

FAQ

A equipe Tenvo pode ler minhas sessões de desktop remoto?
Depende da rota. Uma conexão peer‑to‑peer direta é criptografada end‑to‑end e não podemos lê‑la. Quando uma conexão direta não pode ser estabelecida, a sessão é retransmitida e o TLS termina em nosso relé: não gravamos nem armazenamos o conteúdo das sessões, mas não vamos afirmar que é tecnicamente impossível para nós vê‑las. O cliente é open source, então você pode checar isso em vez de confiar apenas na nossa palavra.

Open source é realmente mais seguro que closed source?
Disponibilidade do código‑fonte é necessária mas não suficiente. AGPL-3.0 significa que um auditor independente pode verificar se o protocolo corresponde à documentação; ferramentas fechadas exigem confiar no fornecedor. Ambos podem ser seguros se bem implementados; apenas um é verificável.

Devo me preocupar com o modelo de impressão digital trust‑on‑first‑use?
Apenas se você estiver configurando a conexão por uma rede que não confia. Para setups paranoicos, verifique a impressão digital do host fora de banda (leia‑a por telefone, não por chat) na primeira conexão. Depois disso, o cliente fixa (pins) a impressão digital localmente.

Existem CVEs conhecidos em RustDesk / Tenvo?
O projeto RustDesk teve algumas questões divulgadas ao longo dos anos, majoritariamente nos componentes opcionais do servidor self‑hosted, corrigidas prontamente em cada caso. O cliente desktop em si não teve CVEs de alta severidade com execução remota de código até maio de 2026. Verifique a página de security advisories no GitHub para a lista atual.

Quais métodos de 2FA o Tenvo suporta?
TOTP via qualquer app autenticador padrão (Authy, 1Password, Google Authenticator) nas camadas Lite e Pro. Suporte a chave de hardware (WebAuthn) está no roadmap.