Q1. Pode nos contar brevemente a história de origem da Session e o que o motivou a construir uma rede de mensagens descentralizada?
A Session é a criação conjunta de centenas de colaboradores de todo o mundo—essa é a beleza do software de código aberto; qualquer pessoa pode escrever e contribuir com código para a base de código do Session. No entanto, cada produto tem uma história de fundação mais central. Para o Session, os fundadores originais queriam construir uma aplicação de prova de conceito sobre uma rede descentralizada recém-estabelecida. Pensamos que a melhor aplicação de prova de conceito era construir uma aplicação de mensagens que armazenasse e roteasse mensagens através desta rede descentralizada, porque uma vez que você tivesse um mensageiro básico, poderia generalizar este conceito para muitas outras aplicações que muitas vezes se resumem a passar mensagens de um dispositivo para outro. O Session foi lançado com um nome diferente e cresceu imediatamente. Ficou claro que a atenção deveria ser focada no Session, e o que originalmente foi projetado como uma prova de conceito cresceu para se tornar uma das maiores aplicações de mensagens privadas disponíveis hoje.
Q2. A recente diretiva de emergência da CISA identificou duas falhas críticas no TM SGNL. Da sua perspetiva, o que correu mal no design ou na implementação que permitiu que os atacantes recolhessem registos de chat e metadados?
Este é um caso clássico de problemas de design e implementação em cascata que, por si só, podem não ser exploráveis, mas quando combinados podem causar uma falha catastrófica na segurança de uma rede.
A primeira falha foi no design, a TeleMessage pegou o Signal, um aplicativo de mensagens seguras bem renomado, e adicionou o que equivalia a uma porta dos fundos intencional no aplicativo com o propósito de criar um registro de auditoria. A forma como esse registro de auditoria funcionava era enviando uma cópia de cada mensagem que um usuário enviava, antes de ser criptografada de ponta a ponta, para um único servidor central, que então armazenaria uma cópia de todas essas mensagens em estado não criptografado. Isso criou o pote de mel para atacantes de dados extremamente sensíveis, um tesouro de informações de segurança nacional irresistível para hackers.
A segunda falha foi uma má configuração de um serviço (Spring Boot Actuator) que funcionava no servidor de arquivos TM SGNL. Este é um problema de má configuração muito básico, onde uma URL normalmente usada pelos desenvolvedores para diagnosticar bugs foi deixada aberta para que qualquer pessoa a utilizasse sem autenticação. Isso permitiu que atacantes despejassem a memória do servidor, e nesse despejo, mensagens não criptografadas e informações de autenticação para usuários estavam visíveis em texto simples, o que permitiu que hackers recuperassem mensagens e informações de conta.
É importante notar que ambas as falhas precisavam coexistir para que um hack dessa escala ocorresse. Este é frequentemente o caso em violações de cibersegurança, onde os atacantes encontram uma única falha de design ou implementação e depois usam essa falha para encontrar outras vulnerabilidades a explorar.
Q3. Quão comum é que os clientes E2EE—mesmo os compatíveis com o Signal—introduzam tais fraquezas, e por que razão não são detetadas mais cedo?
Aplicações de mensagens de consumo comuns, como WhatsApp, Signal e Telegram, geralmente têm uma segurança muito melhor em torno de seus servidores do que os servidores do TeleMessage. No entanto, quando se trata de aplicações de mensagens desenvolvidas e modificadas explicitamente para criar um registro de auditoria de conversões, é mais comum ver esses tipos de configurações incorretas. Especialmente quando essas aplicações têm código fechado, os pesquisadores de segurança da comunidade não têm a mesma capacidade de analisar o código em busca de fraquezas, portanto, configurações incorretas comuns podem passar despercebidas por muito tempo ou ser mantidas em segredo por hackers em nível estatal para manter portas dos fundos nos sistemas que não são corrigidos.
Q4. Você argumentou que, enquanto um único fornecedor controla partes chave da pilha, há um risco inerente. Como a centralização do fornecedor se traduz em falhas de privacidade no mundo real?
A centralização do fornecedor geralmente é combinada com código fechado e servidores centralizados. Quando um serviço de mensagens armazena todas as mensagens dos usuários em uma única localização central, cria um alvo para atacantes; eles sabem que, ao invadir um único servidor, têm acesso a todas as mensagens enviadas pelo serviço. Quando combinado com código fechado que não pode ser revisado por pesquisadores de segurança de código aberto e auditores, o incentivo para os atacantes aumenta, e bugs que poderiam ter sido descobertos passam despercebidos por todos, exceto os atacantes mais sofisticados, que mantêm esses bugs privados para que possam persistir no seu acesso oculto, deixando todos os usuários do serviço comprometidos.
Q5. Poderia compartilhar um exemplo ( fora do TM SGNL) onde uma falha do lado do vendedor minou as garantias da criptografia de ponta a ponta?
O uso do Twilio pela Signal para verificação por SMS resultou em algumas contas de usuários da Signal sendo comprometidas quando o Twilio foi hackeado. Como a verificação por SMS é uma das maneiras pelas quais os usuários da Signal podem recuperar suas contas, quando o Twilio foi hackeado, os atacantes podiam enganar os servidores da Signal fazendo-os pensar que possuíam o número de telefone de um usuário da Signal e recuperar sua conta, usando esse acesso para enviar mensagens não autorizadas a partir das contas desses usuários da Signal.
Q6. Por que você acredita que a descentralização é a única maneira de mitigar totalmente o risco de fornecedor único?
A descentralização é a única forma de mitigar completamente o risco de um único fornecedor, pois remove o ponto único de falha inerente a qualquer sistema centralizado. Quando uma única entidade controla partes-chave da pilha - desde identidades de usuários até o roteamento e armazenamento de mensagens - ela se torna um alvo irresistível para atacantes, e suas falhas de design ou implementação podem ter consequências catastróficas, como visto com o TM SGNL.
Numa rede descentralizada, não há um servidor central a ser invadido, nenhuma empresa única a ser pressionada a inserir portas dos fundos, e nenhuma base de dados única a ser alvo de coleta de metadados. As identidades dos usuários são frequentemente chaves criptográficas, não identificadores do mundo real ligados a uma autoridade central. As mensagens são roteadas e armazenadas numa rede distribuída de nós independentes, o que significa que nenhum nó vê os endereços IP do remetente e do destinatário, e nenhuma entidade única pode coletar um registo abrangente das comunicações.
Esta distribuição de poder e dados torna o sistema inerentemente mais resiliente a ataques, censura e exploração de dados, porque não há um único ponto de estrangulamento a explorar. A segurança não depende da confiabilidade de uma única empresa, mas sim da integridade coletiva e do design criptográfico robusto da rede distribuída.
Q7. A Session utiliza uma rede de nós de serviço. Como esta arquitetura garante que nenhuma parte possa comprometer os dados dos utilizadores?
Ao contrário das aplicações de mensagens tradicionais, o Session não depende de um único servidor central que armazena todos os dados dos utilizadores. Em vez disso, as mensagens são encaminhadas através de uma rede distribuída de milhares de nós do Session, operados de forma independente pela comunidade. Isto elimina o efeito "honeypot" de uma única base de dados centralizada, tornando extremamente difícil para qualquer entidade única recolher mensagens e metadados criptografados de forma abrangente. Os nós do Session armazenam temporariamente mensagens para destinatários offline. No entanto, estas mensagens são criptografadas de ponta a ponta, o que significa que os próprios nós não podem ler o conteúdo. Além disso, as mensagens são armazenadas apenas por um tempo limitado (Time-To-Live) e podem ser eliminadas uma vez lidas, prevenindo a retenção a longo prazo na rede de nós.
Além disso, a Session utiliza uma técnica de roteamento em cebola modificada, semelhante ao Tor. Quando você envia uma mensagem, ela é criptografada em camadas, e cada camada é removida por nós da Session sucessivos. Crucialmente, nenhum nó único conhece os endereços IP do remetente e do destinatário. Isso significa que, mesmo que um nó fosse comprometido, não conseguiria vincular uma mensagem de volta à sua origem ou destino.
As contas de sessão são geradas criptograficamente sem exigir qualquer informação pessoal, como números de telefone ou endereços de e-mail. Isso significa que não há uma identidade do mundo real vinculada ao seu ID de Conta de Sessão, aumentando ainda mais a privacidade e tornando mais difícil comprometer a identidade de um usuário através de vazamentos de dados externos.
Esta abordagem em várias camadas, sem um ponto central de controle, armazenamento temporário, criptografia de ponta a ponta e roteamento anonimizado, garante que mesmo que um pequeno número de Nós de Sessão seja comprometido, a integridade e a privacidade geral da rede permanecerão intactas.
Q8. Dada a implementação do TM SGNL em agências federais, vê governos a moverem-se em direção a uma comunicação verdadeiramente descentralizada? Que barreiras existem para essa mudança?
Essa é uma questão difícil. As agências governamentais geralmente exigem que registros de auditoria sejam criados e armazenados de forma que sejam visíveis por um auditor, o que cria uma vulnerabilidade de segurança inerente. A criptografia de ponta a ponta é projetada para que apenas os participantes da conversa possam ver o conteúdo das comunicações. A exigência de auditoria introduz uma porta dos fundos intencional na criptografia de ponta a ponta, o que é difícil de implementar de maneira segura.
No entanto, existem maneiras de gerenciar isso melhor, por exemplo, o registro de auditoria deve sempre ser armazenado criptografado em repouso e deve haver proteções robustas em torno dos usuários que podem acessar esse registro de auditoria. Os governos devem usar ferramentas de código aberto que possam ser facilmente auditadas e pensar extremamente bem sobre como os registros de auditoria são armazenados e em quais servidores eles são armazenados.
Se a regulamentação fosse atualizada, poderia oferecer uma forma de as soluções descentralizadas serem melhor aproveitadas nas comunicações governamentais.
Q9. Como você persuadiria uma organização preocupada com a segurança a migrar de um cliente proprietário compatível com Signal para o Session?
Acho que o hack do TM SGNL oferece o incentivo mais claro até agora para os usuários se afastarem de soluções técnicas proprietárias em direção a ferramentas de código aberto como o Session, que oferecem recursos de segurança e privacidade muito aprimorados. Pode ser possível no futuro que organizações utilizem ferramentas de código aberto como o Session e desenvolvam suas próprias ferramentas de auditoria que se conectem a essas ferramentas. No entanto, tais soluções de auditoria devem ser elas mesmas de código aberto e auditáveis para garantir que não vejamos os mesmos problemas que o TM SGNL reaparecerem.
Q10. Olhando para o futuro, quais são as principais características ou melhorias no roadmap do Session para os próximos 12 a 18 meses? No final, qual é a sua visão a longo prazo para o Session e para a comunicação segura e privada em geral?
O foco atual do Session é alcançar mais usuários. O Session já tem mais de um milhão de usuários ativos mensais, mas queremos ver ainda mais usuários escolhendo soluções que incorporam forte privacidade e segurança no núcleo do design da aplicação. Os colaboradores do Session estão atualmente a trabalhar em um conjunto premium de funcionalidades para usuários avançados do Session, que permitem um financiamento sustentável para o ecossistema do Session. Isso inclui funcionalidades como grupos maiores, mais personalização de perfil e tamanhos de arquivo aumentados, todas funcionalidades que aumentam a utilidade do Session.
De forma mais ampla, vejo o Session como o único aplicativo que oferece tanto privacidade de conteúdo quanto de metadados em uma experiência altamente consumível e fácil de usar, e acho que, à medida que as violações de dados continuam a impactar os usuários, o Session verá um crescimento contínuo nos próximos 12-18 meses.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Reinventando a Mensagem Segura: uma Análise Profunda com o Co-Fundador da Session Kee Jefferys
Q1. Pode nos contar brevemente a história de origem da Session e o que o motivou a construir uma rede de mensagens descentralizada?
A Session é a criação conjunta de centenas de colaboradores de todo o mundo—essa é a beleza do software de código aberto; qualquer pessoa pode escrever e contribuir com código para a base de código do Session. No entanto, cada produto tem uma história de fundação mais central. Para o Session, os fundadores originais queriam construir uma aplicação de prova de conceito sobre uma rede descentralizada recém-estabelecida. Pensamos que a melhor aplicação de prova de conceito era construir uma aplicação de mensagens que armazenasse e roteasse mensagens através desta rede descentralizada, porque uma vez que você tivesse um mensageiro básico, poderia generalizar este conceito para muitas outras aplicações que muitas vezes se resumem a passar mensagens de um dispositivo para outro. O Session foi lançado com um nome diferente e cresceu imediatamente. Ficou claro que a atenção deveria ser focada no Session, e o que originalmente foi projetado como uma prova de conceito cresceu para se tornar uma das maiores aplicações de mensagens privadas disponíveis hoje.
Q2. A recente diretiva de emergência da CISA identificou duas falhas críticas no TM SGNL. Da sua perspetiva, o que correu mal no design ou na implementação que permitiu que os atacantes recolhessem registos de chat e metadados?
Este é um caso clássico de problemas de design e implementação em cascata que, por si só, podem não ser exploráveis, mas quando combinados podem causar uma falha catastrófica na segurança de uma rede.
A primeira falha foi no design, a TeleMessage pegou o Signal, um aplicativo de mensagens seguras bem renomado, e adicionou o que equivalia a uma porta dos fundos intencional no aplicativo com o propósito de criar um registro de auditoria. A forma como esse registro de auditoria funcionava era enviando uma cópia de cada mensagem que um usuário enviava, antes de ser criptografada de ponta a ponta, para um único servidor central, que então armazenaria uma cópia de todas essas mensagens em estado não criptografado. Isso criou o pote de mel para atacantes de dados extremamente sensíveis, um tesouro de informações de segurança nacional irresistível para hackers.
A segunda falha foi uma má configuração de um serviço (Spring Boot Actuator) que funcionava no servidor de arquivos TM SGNL. Este é um problema de má configuração muito básico, onde uma URL normalmente usada pelos desenvolvedores para diagnosticar bugs foi deixada aberta para que qualquer pessoa a utilizasse sem autenticação. Isso permitiu que atacantes despejassem a memória do servidor, e nesse despejo, mensagens não criptografadas e informações de autenticação para usuários estavam visíveis em texto simples, o que permitiu que hackers recuperassem mensagens e informações de conta.
É importante notar que ambas as falhas precisavam coexistir para que um hack dessa escala ocorresse. Este é frequentemente o caso em violações de cibersegurança, onde os atacantes encontram uma única falha de design ou implementação e depois usam essa falha para encontrar outras vulnerabilidades a explorar.
Q3. Quão comum é que os clientes E2EE—mesmo os compatíveis com o Signal—introduzam tais fraquezas, e por que razão não são detetadas mais cedo?
Aplicações de mensagens de consumo comuns, como WhatsApp, Signal e Telegram, geralmente têm uma segurança muito melhor em torno de seus servidores do que os servidores do TeleMessage. No entanto, quando se trata de aplicações de mensagens desenvolvidas e modificadas explicitamente para criar um registro de auditoria de conversões, é mais comum ver esses tipos de configurações incorretas. Especialmente quando essas aplicações têm código fechado, os pesquisadores de segurança da comunidade não têm a mesma capacidade de analisar o código em busca de fraquezas, portanto, configurações incorretas comuns podem passar despercebidas por muito tempo ou ser mantidas em segredo por hackers em nível estatal para manter portas dos fundos nos sistemas que não são corrigidos.
Q4. Você argumentou que, enquanto um único fornecedor controla partes chave da pilha, há um risco inerente. Como a centralização do fornecedor se traduz em falhas de privacidade no mundo real?
A centralização do fornecedor geralmente é combinada com código fechado e servidores centralizados. Quando um serviço de mensagens armazena todas as mensagens dos usuários em uma única localização central, cria um alvo para atacantes; eles sabem que, ao invadir um único servidor, têm acesso a todas as mensagens enviadas pelo serviço. Quando combinado com código fechado que não pode ser revisado por pesquisadores de segurança de código aberto e auditores, o incentivo para os atacantes aumenta, e bugs que poderiam ter sido descobertos passam despercebidos por todos, exceto os atacantes mais sofisticados, que mantêm esses bugs privados para que possam persistir no seu acesso oculto, deixando todos os usuários do serviço comprometidos.
Q5. Poderia compartilhar um exemplo ( fora do TM SGNL) onde uma falha do lado do vendedor minou as garantias da criptografia de ponta a ponta?
O uso do Twilio pela Signal para verificação por SMS resultou em algumas contas de usuários da Signal sendo comprometidas quando o Twilio foi hackeado. Como a verificação por SMS é uma das maneiras pelas quais os usuários da Signal podem recuperar suas contas, quando o Twilio foi hackeado, os atacantes podiam enganar os servidores da Signal fazendo-os pensar que possuíam o número de telefone de um usuário da Signal e recuperar sua conta, usando esse acesso para enviar mensagens não autorizadas a partir das contas desses usuários da Signal.
Q6. Por que você acredita que a descentralização é a única maneira de mitigar totalmente o risco de fornecedor único?
A descentralização é a única forma de mitigar completamente o risco de um único fornecedor, pois remove o ponto único de falha inerente a qualquer sistema centralizado. Quando uma única entidade controla partes-chave da pilha - desde identidades de usuários até o roteamento e armazenamento de mensagens - ela se torna um alvo irresistível para atacantes, e suas falhas de design ou implementação podem ter consequências catastróficas, como visto com o TM SGNL.
Numa rede descentralizada, não há um servidor central a ser invadido, nenhuma empresa única a ser pressionada a inserir portas dos fundos, e nenhuma base de dados única a ser alvo de coleta de metadados. As identidades dos usuários são frequentemente chaves criptográficas, não identificadores do mundo real ligados a uma autoridade central. As mensagens são roteadas e armazenadas numa rede distribuída de nós independentes, o que significa que nenhum nó vê os endereços IP do remetente e do destinatário, e nenhuma entidade única pode coletar um registo abrangente das comunicações.
Esta distribuição de poder e dados torna o sistema inerentemente mais resiliente a ataques, censura e exploração de dados, porque não há um único ponto de estrangulamento a explorar. A segurança não depende da confiabilidade de uma única empresa, mas sim da integridade coletiva e do design criptográfico robusto da rede distribuída.
Q7. A Session utiliza uma rede de nós de serviço. Como esta arquitetura garante que nenhuma parte possa comprometer os dados dos utilizadores?
Ao contrário das aplicações de mensagens tradicionais, o Session não depende de um único servidor central que armazena todos os dados dos utilizadores. Em vez disso, as mensagens são encaminhadas através de uma rede distribuída de milhares de nós do Session, operados de forma independente pela comunidade. Isto elimina o efeito "honeypot" de uma única base de dados centralizada, tornando extremamente difícil para qualquer entidade única recolher mensagens e metadados criptografados de forma abrangente. Os nós do Session armazenam temporariamente mensagens para destinatários offline. No entanto, estas mensagens são criptografadas de ponta a ponta, o que significa que os próprios nós não podem ler o conteúdo. Além disso, as mensagens são armazenadas apenas por um tempo limitado (Time-To-Live) e podem ser eliminadas uma vez lidas, prevenindo a retenção a longo prazo na rede de nós.
Além disso, a Session utiliza uma técnica de roteamento em cebola modificada, semelhante ao Tor. Quando você envia uma mensagem, ela é criptografada em camadas, e cada camada é removida por nós da Session sucessivos. Crucialmente, nenhum nó único conhece os endereços IP do remetente e do destinatário. Isso significa que, mesmo que um nó fosse comprometido, não conseguiria vincular uma mensagem de volta à sua origem ou destino.
As contas de sessão são geradas criptograficamente sem exigir qualquer informação pessoal, como números de telefone ou endereços de e-mail. Isso significa que não há uma identidade do mundo real vinculada ao seu ID de Conta de Sessão, aumentando ainda mais a privacidade e tornando mais difícil comprometer a identidade de um usuário através de vazamentos de dados externos.
Esta abordagem em várias camadas, sem um ponto central de controle, armazenamento temporário, criptografia de ponta a ponta e roteamento anonimizado, garante que mesmo que um pequeno número de Nós de Sessão seja comprometido, a integridade e a privacidade geral da rede permanecerão intactas.
Q8. Dada a implementação do TM SGNL em agências federais, vê governos a moverem-se em direção a uma comunicação verdadeiramente descentralizada? Que barreiras existem para essa mudança?
Essa é uma questão difícil. As agências governamentais geralmente exigem que registros de auditoria sejam criados e armazenados de forma que sejam visíveis por um auditor, o que cria uma vulnerabilidade de segurança inerente. A criptografia de ponta a ponta é projetada para que apenas os participantes da conversa possam ver o conteúdo das comunicações. A exigência de auditoria introduz uma porta dos fundos intencional na criptografia de ponta a ponta, o que é difícil de implementar de maneira segura.
No entanto, existem maneiras de gerenciar isso melhor, por exemplo, o registro de auditoria deve sempre ser armazenado criptografado em repouso e deve haver proteções robustas em torno dos usuários que podem acessar esse registro de auditoria. Os governos devem usar ferramentas de código aberto que possam ser facilmente auditadas e pensar extremamente bem sobre como os registros de auditoria são armazenados e em quais servidores eles são armazenados.
Se a regulamentação fosse atualizada, poderia oferecer uma forma de as soluções descentralizadas serem melhor aproveitadas nas comunicações governamentais.
Q9. Como você persuadiria uma organização preocupada com a segurança a migrar de um cliente proprietário compatível com Signal para o Session?
Acho que o hack do TM SGNL oferece o incentivo mais claro até agora para os usuários se afastarem de soluções técnicas proprietárias em direção a ferramentas de código aberto como o Session, que oferecem recursos de segurança e privacidade muito aprimorados. Pode ser possível no futuro que organizações utilizem ferramentas de código aberto como o Session e desenvolvam suas próprias ferramentas de auditoria que se conectem a essas ferramentas. No entanto, tais soluções de auditoria devem ser elas mesmas de código aberto e auditáveis para garantir que não vejamos os mesmos problemas que o TM SGNL reaparecerem.
Q10. Olhando para o futuro, quais são as principais características ou melhorias no roadmap do Session para os próximos 12 a 18 meses? No final, qual é a sua visão a longo prazo para o Session e para a comunicação segura e privada em geral?
O foco atual do Session é alcançar mais usuários. O Session já tem mais de um milhão de usuários ativos mensais, mas queremos ver ainda mais usuários escolhendo soluções que incorporam forte privacidade e segurança no núcleo do design da aplicação. Os colaboradores do Session estão atualmente a trabalhar em um conjunto premium de funcionalidades para usuários avançados do Session, que permitem um financiamento sustentável para o ecossistema do Session. Isso inclui funcionalidades como grupos maiores, mais personalização de perfil e tamanhos de arquivo aumentados, todas funcionalidades que aumentam a utilidade do Session.
De forma mais ampla, vejo o Session como o único aplicativo que oferece tanto privacidade de conteúdo quanto de metadados em uma experiência altamente consumível e fácil de usar, e acho que, à medida que as violações de dados continuam a impactar os usuários, o Session verá um crescimento contínuo nos próximos 12-18 meses.