Por que usar HTTPS no protocolo DP-3T?
Estou tendo uma discussão sobre a transparência do protocolo HTTPS em um aplicativo de detecção COVID-19 específico. Os oponentes afirmam que usar HTTPS está ofuscando o aplicativo, que o aplicativo deve se comportar de forma transparente e enviar todo o tráfego por HTTP para que possam ver o que estão enviando, porque os dados são "anônimos" de qualquer maneira.
Após alguma investigação descobri que esta parte segue estritamente o protocolo DP-3T , que afirma que "O aplicativo abre uma conexão TLS criptografada para o servidor e envia o código de autorização [...]". Sei com certeza que eles não leram todo o protocolo (nem eu, apenas algumas partes), mas mesmo com isso em mente, eles continuam dizendo que não há razão para não começar a usar HTTP simples removendo HTTPS. Eles vão além e afirmam que, se constar do protocolo, é porque foi mal projetado.
Então, quais seriam os motivos para usar HTTPS em um protocolo anônimo como o DP-3T?
Respostas
As conexões TLS têm três propriedades distintas e importantes:
- privacidade, ou seja, proteção contra espionagem
- autenticação, para garantir que as partes que estão se comunicando são realmente quem fingem ser
- integridade, o que significa que os dados não podem ser modificados durante a transmissão
Parece que seus oponentes argumentam apenas contra o primeiro, mas os outros dois são essenciais para a maioria das aplicações. Para DP-3T em particular, a falta de autenticação significaria que um invasor poderia interceptar uma transmissão e descartá-la enquanto o aplicativo pensaria que o código foi transmitido com sucesso.
E de forma mais geral, o TLS hoje em dia é barato e fácil de configurar. Você precisaria de um bom motivo para não usá-lo, em vez de um para usá-lo. Na verdade, pelo menos para iOS, é explicitamente exigido que um aplicativo use segurança de transporte e as exceções devem ser justificadas.
Junto com os cibercriminosos dispostos a fazer escuta telefônica em redes sem fio, as complicadas redes de hoje geralmente carregam um grande número de middleboxes de vigilância diferentes para diferentes propósitos . Esses dispositivos não apenas espionam, mas às vezes podem modificar os dados transmitidos de maneiras arbitrárias, intencionalmente ou não.
Por exemplo, um equipamento DPI instalado por um ISP pode ser configurado para substituir o anúncio do site da Web pelos anúncios do ISP. Se configurado de forma incorreta, esse equipamento também substituiria partes não relacionadas do código Javascript ou XML nos fluxos de dados transmitidos por aplicativos móveis ou sites.
isso é apenas um exemplo.
Portanto, o modelo de ameaça contemporâneo para sites e aplicativos móveis assume apenas HTTPS criptografado como transporte. HTTPS é bastante fácil de configurar hoje em dia, ele vem de graça e elimina um grande número de ameaças opacas e complexas e bugs potenciais que é mais fácil e muito mais confiável - do ponto de vista operacional - configurá-lo do que não configurá-lo.
Os oponentes afirmam que usar HTTPS está ofuscando o aplicativo, que o aplicativo deve se comportar de forma transparente e enviar todo o tráfego por HTTP para que possam ver o que estão enviando, porque os dados são "anônimos" de qualquer maneira.
Vou supor que o "eles" em negrito se refere ao usuário final, e não aos desenvolvedores (porque se ele se refere aos desenvolvedores, então este é um problema direto de não usar técnicas de depuração adequadas, como registro do lado do servidor )
De forma realista, quantos de seus usuários finais executarão o Wireshark ou um software semelhante? Daqueles que são tecnicamente proficientes o suficiente para executar o Wireshark, quantos vão seriamente considerar o tráfego HTTPS suspeito? É possivelmente o segundo protocolo mais popular (camada 7) do mundo (depois de SMTP, eu tenderia a imaginar) e, como você disse, o protocolo DP-3T exige explicitamente seu uso. Qualquer um que ache isso suspeito provavelmente não sabe o suficiente sobre tecnologia de rede para usar o Wireshark em primeiro lugar. Em minha opinião, o uso de HTTP não seguro é mais provável de provocar suspeitas do que o uso de HTTPS.
Por outro lado, é bem possível ocultar dados em fluxos de rede não criptografados usando qualquer número de diferentes formas de esteganografia (neste caso, ocultando alguns dados nos IDs efêmeros supostamente "aleatórios" que são usados por DP-3T, e / ou na chave secreta quando é carregado para um relatório de infecção; ambos são blobs opacos de dados binários sem nenhuma estrutura significativa para o usuário examinar). Portanto, o fato de o usuário final técnico ser capaz de monitorar o tráfego do seu aplicativo não ajuda muito com a confiança.
Em qualquer caso, podemos ver claramente que:
- Isso não convence os usuários não técnicos de nada.
- É improvável que seja eficaz para convencer usuários técnicos de que seu aplicativo é seguro e pode convencê-los de que seu aplicativo não é seguro ou, pelo menos, mal projetado.
- Conforme descrito em várias outras respostas, o TLS faz outras coisas além da confidencialidade e isso pode comprometer a segurança da sua implementação de outras maneiras.
Além dos excelentes pontos apresentados nas outras respostas, criptografar apenas dados em que a privacidade é preocupante informa aos adversários que esses são dados em que a privacidade é preocupante e permite que eles concentrem seus esforços na descriptografia desses dados.
Em outras palavras, mesmo que a privacidade seja sua única preocupação, você deve criptografar tudo para que os adversários não saibam onde procurar. Isso significa usar HTTPS, em vez de HTTP, onde aplicável.
Aqui está uma referência que encontrei. Mesmo que se trate de protocolos diferentes, a ideia básica é a mesma. Autodefesa por e-mail :
Quanto mais você criptografar suas mensagens, melhor. Se você criptografar e-mails apenas ocasionalmente, cada mensagem criptografada pode levantar uma bandeira vermelha para os sistemas de vigilância. Se todo ou a maior parte do seu e-mail estiver criptografado, as pessoas que fazem vigilância não saberão por onde começar.