Jump to content
  • Entenda o DNS sobre HTTPS

       (2 reviews)

    AndreAlves
     Share

    Um pouco depois das revelaçōes de Edward Snowden sobre monitoração generalizada da internet por entidades governamentais, a IETF (Internet Engineering Taskforce - uma comunidade de gente interessada na engenharia da internet) criou um grupo de trabalho para rever a privacidade do DNS e o nomeou "DPRIVE" - abreviação para DNS Privacy.

    Pensar em jeitos de tornar as resoluçōes deste protocolo tão fundamental menos manipuláveis e mais secretas sem perder muita velocidade é o abacaxi que foi dado a esse grupo, que tem trabalhado bastante e gerado alguns frutos.

    Mais recentemente um deles ficou mais conhecido entre nós quando a Cloudflare lançou um serviço de DNS focado em privacidade e rapidez e anunciou suporte a uma das propostas do IETF para DNS seguro-privado-rápido , o DOH (DNS over HTTPS), que dá nome à este artigo.

    A sacada do DOH é possibilitar queries (consultas) DNS criptografadas (tchau entidades governamentais tentando espionar ?) que são difíceis de diferenciar de outros tráfegos criptofragados (tchau provedores tentando fazer bandwith throttling ou traffic shaping).

    Mas afinal, como isto funciona?

    Basicamente as queries DNS se tornam um request HTTP do tipo POST ou GET para uma URL definida pelo serviço de DNS. Essas requests são trafegadas dentro de uma sessão TLS e formatadas como JSONs codificados em base64. No JSON temos os campos definindo o tipo do registro a ser consultado (A, CNAME, AAA, etc).

    Para visualizar aqui vai um exemplo de solicitação de uma query para resolver o nome www.exemplo.com usando o método POST, tirado direto do rascunho da RFC:

    :method = POST
    :scheme = https
    :authority = dnsserver.example.net
    :path = /dns-query
    accept = application/dns-udpwireformat
    content-type = application/dns-udpwireformat
    content-length = 33

    E o conteúdo de 33 bytes da query:

       00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
       07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
       01

    Não é lindo? Sim é. Mas se você quiser usar por enquanto terá que se aventurar. Um dos poucos (único?) navegadores que suporta este recurso é o Firefox em sua versão Nightly (sai um novo release toda noite!). Para configurar, os passos são:

    1. Digite about:config na barra de endereços e pressione [ENTER].
    2. Altere o valor dos seguintes parâmetros de acordo:
    netowrk.trr.bootstrapAddress:   1.1.1.1
    network.trr.uri:                https://mozilla.cloudflare-dns.com/dns-query
    network.trr.mode:               2 (usa DOH primariamente, mas faz fallback pro DNS atual)

    Outros projetos utilizando DOH estão surgindo no Github. O DNS-over-HTTPS proxy, por exemplo, cria um proxy de modo que as consultas DNS sejam redirecionadas para o serviço do Google que suporta DOH.

    O mais legal é que a preocupação com privacidade e liberdade individual continuará a resultar em mais projetos como este para salvar nossa internet de quem se acha dono dela. ?

    Se você ficou interessado, dá uma pesquisada nos outros candidatos a DNS seguro:

    • DNS over TLS (RFC 7858)
    • DNS over DTLS (RFC 8094)
    • DNS over QUIC (ID-draft)
    • DNS over DNSCrypt (independente)
    • DNS over TOR (independente)

    • Agradecer 1
    • Curtir 4
     Share


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.


    guioday83

       6 of 6 members found this review helpful 6 / 6 members

    Muito bom... Toda ajuda quanto à privacidade é bem vinda. Mas que tal utilizar um serviço de DNS que te ofereça segurança, sem esquecer de sua privacidade?

    Agora o #CleanDNS também é compatível com DNS-over-HTTPS, além de oferecer sua própria DNS-over-VPN (OpenVPN). 

    ?

    cleandns.jpg.36fb243a645856aad26eb6cbeb836ae9.jpg

    • Curtir 2
    Link to review
    Share on other sites


  • Similar Content

    • By Jordan Bonagura
      Este artigo objetiva demonstrar, de maneira simplificada, diferentes abordagens para interceptação e captura de dados de tráfego de rede originários de um dispositivo iPhone, da Apple. Na verdade o iPhone não é o único dispositivo sujeito a estas abordagens, assim como as estratégias aqui apresentadas não são as únicas capazes de realizar tais interceptações, então é possível usar este conteúdo para muitas outras aplicações, mas vou focar no iPhone por agora. 🙂
      A maneira mais simples de capturar o tráfego de rede de um iPhone é utilizando um servidor proxy. Na primeira parte deste artigo, adotaremos o Burp Suite para exemplificar este funcionamento. Após a coleta dos dados, analisaremos os pacotes de uma aplicação específica e a suas conexões com serviços web.
      Caso o objetivo seja uma análise mais detalhada do tráfego de uma aplicação que utilize outras tipos de comunicação que não somente requisições web, podemos diversificar a estratégia e utilizar uma interface de rede virtual (RVI), conforme demonstraremos na segunda parte deste artigo.
      Parte 1 - Utilizando um servidor proxy - Burp Suite
      Quando mencionamos a utilização de um servidor proxy, estamos basicamente nos referindo a interceptar e analisar solicitações relacionadas ao protocolo HTTP (HyperText Transfer Protocol), seja este com a camada de segurança TLS (Transport Layer Security) ou não.
      Algumas das aplicações que temos em nossos smartphones ainda utilizam somente o protocolo HTTP, o que significa dizer que os dados trafegam na forma de texto puro, ou seja, sem qualquer criptografia, fazendo com que informações sensíveis fiquem totalmente expostas a qualquer atacante que adotar técnicas de interceptação.
      Para configuração de nosso proxy o primeiro passo é abrirmos o Burp Suite. Por padrão, a interface em que ele escuta é a local (127.0.0.1) na porta 8080, conforme podemos verificar na imagem abaixo:

      Figura 1 - Interface padrão de escuta do Burp Suite
      No Burp Suite, toda captura está por padrão relacionada a máquina local, porém para executarmos nossa estratégia de interceptação dos dados que chegarão ao nosso servidor por meio do iPhone, precisaremos adicionar o IP interno da máquina local no campo Specific address:

      Figura 2 - Mudando a interface de escuta do Burp Suite
      Veja que neste caso adotamos o endereço IP 192.168.1.102 e a porta 8081.
      Uma vez o Burp Suite configurado, vamos ao iPhone:

      Figura 3 - Habilitando o uso de um servidor proxy no iPhone
      Perceba que o endereço IP associado ao iPhone não tem relação alguma com o servidor proxy, porém é óbvio que terão que estar na mesma rede para que o tráfego possa ser capturado. 😉

      Figura 4 - Configurações de proxy no iPhone
      Assim que finalizamos a configuração do iPhone para utilizar o Burp Suite como o nosso servidor proxy, já podemos ver alguns pacotes. Isso ocorre pois diversas aplicações ficam rodando em background, normalmente atualizações, updates de e-mails, entre outros.
      Abaixo temos um exemplo de pacote interceptado com o método POST do HTTP em conexão com o office365.com para atualização de e-mail. Reparem que o DeviceType já é identificado como sendo um iPhone.

      Figura 5 - Tráfego recebido pelo Burp Suite
      Para demonstração foi utilizado um aplicativo real da área da saúde, mais precisamente de uma empresa de assistência médica. Por questões éticas, ocultei os dados.
      Podemos analisar que quando abrimos o aplicativo em nosso smartphone, já são executadas chamadas à API num servidor para troca de informações e com isto já visualizamos os pacotes conforme imagem abaixo:

      Figura 6 - Chamadas à API capturadas pelo Burp Suite
      Apesar de ser uma aplicação de necessidade de alto nível de sigilo de informações, os dados são trafegados em texto puro, ou seja, sem nenhuma criptografia envolvida. 😞
      Conforme podemos verificar na imagem abaixo, não estamos ainda falando de credenciais de acesso, mas de todo modo são dados sensíveis, como por exemplo o número de beneficiário e telefone.

      Figura 7 - Dados sensíveis exibidos no Burp Suite
       
      Infelizmente, nesta aplicação não só os dados sensíveis anteriormente destacados são trafegados em texto plano, mas as credenciais de acesso (usuário e senha) também. Veja:
       
      Figura 8 - Credenciais em texto plano capturadas pelo Burp Suite
      Isso significa dizer que se um atacante estiver na conectado na mesma rede que nós, por exemplo uma rede wifi aberta (sem criptografia) de aeroporto, cafeteria e afins, e estivesse rodando um analisador de tráfego como este, poderia ter acesso à nossas credenciais como nome de usuário e senha. 😬
      Parte 2 - Utilizando uma interface de rede virtual (RVI) - Wireshark
      Uma outra abordagem que pode ser as vezes mais interessante é poder analisar todo o tráfego de rede que ocorre entre o dispositivo iPhone e os servidores das aplicações, agora não mais focado somente em aplicações e requisições web (HTTP), mas sim em diferentes protocolos, como por exemplo o bom e velho MSN para fins de aprendizagem, onde é possível analisar os pacotes MSNP trafegando pela rede, bem como conexões com outros dispositivos mais simples que utilizam o protocolo SNMP, por exemplo. Não há limites. 🙂
      Iniciamos com a conexão do nosso iPhone via USB ao computador que rodará o Wireshark para a coleta dos dados. Na sequência, realizaremos a criação da RVI (Remote Virtual Interface) onde necessitaremos passar como parâmetro o UUID (Universal Unique Identifiers) do iPhone. Vale lembrar que é possível obter o UUID com qualquer sistema operacional, já para criar a RVI executei o teste somente em macOS. Deixo para você verificar se é possível fazê-lo em outros sistemas, caso queira.
      Pelo próprio Finder do macOS é possível descobrir o UUID do aparelho, basta clicar no nome do dispositivo conectado e surgirá a informação conforme imagem abaixo:

      Figura 9 - UUID exibido no Finder
      Tendo o UUID do aparelho e estando este conectado, se faz necessário ativar a interface virtual (RVI), através do seguinte comando:

      Figura 10 - Criando uma RVI no shell do macOS
      Após recebermos a mensagem de sucesso como acima, estamos com a interface ativada e então poderemos seguir para a abertura do analisador de tráfego de rede Wireshark e selecionar a interface rvi0.

      Figura 11 - Escolha da interface para captura no Wireshark (no macOS)
      Nesta abordagem, e até para fins de comparação com a anterior, adotamos o mesmo aplicativo da área da saúde e aplicamos um filtro básico ip.src == 192.168.1.23 para facilitar a visualização somente de pacotes que têm o IP de origem do iPhone.
      É possível visualizarmos protocolos de diferentes camadas do modelo OSI. Neste exemplo, temos protocolos da camada de transporte (TCP) como também da camada de aplicação (HTTP) como pode ser visto na imagem abaixo:

      Figura 12 - Pacotes capturados pelo Wireshark
      Analisando somente os pacotes HTTP, é possível analisar as mesmas informações que visualizamos anteriormente no Burp Suite.
      Portanto, se abrirmos o conteúdo de nosso pacote selecionado, teremos também todas as informações de credenciais anteriormente demonstradas, conforme imagem abaixo:
       
      Figura 13 - Credenciais em texto plano capturadas pelo Wireshark
      Conclusão
      Pudemos verificar que existem diferentes abordagens em relação a captura de tráfego de dados de um iPhone. Na primeira parte, demonstramos a técnica com a adoção de um servidor proxy (Burp Suite), onde foi possível analisar os pacotes relacionados a requisições web. Esta técnica é de mais fácil implementação, porém muitas vezes limitada, pois como discutimos anteriormente trabalha basicamente com protocolos HTTP/HTTPS.
      Já na segunda parte, demonstramos uma análise de maior amplitude onde foi possível verificar que protocolos de diferentes camadas também podem ser analisados, portanto, a depender do objetivo almejado e/ou da forma de comunicação da aplicação, esta abordagem pode ser mais adequada.
      Vale lembrar que ambas as técnicas são complementares, portanto, dependendo do objetivo final de análise da aplicação, ambas podem ser combinadas.
      O caminho das pedras para a configuração do ambiente de captura está aí, agora é contigo em seguir para a análise aprofundada de suas aplicações. 🤗
      Stay Safe!
    • By Bruna Chieco
      O Google está trabalhando para adicionar um modo Apenas HTTPS (HTTPS-Only) ao navegador Chrome para proteger o tráfego dos usuários de espionagem, atualizando todas as conexões para HTTPS. Segundo o Bleeping Computer, o novo recurso está sendo testado nas versões de pré-visualização do Chrome 93 Canary para Mac, Windows, Linux, Chrome OS e Android.
      Embora nenhum anúncio oficial tenha sido feito ainda, o modo HTTPS-Only provavelmente será lançado em 31 de agosto, diz o site. O Google já atualizou o Chrome para o padrão HTTPS em todos os URLs digitados na barra de endereço se o usuário não especificar nenhum protocolo.
      Para testar o recurso experimental, é preciso habilitar a sinalização "Configuração do modo somente HTTPS" acessando chrome://flags/#https-only-mode-setting. Uma vez ativada a opção "Sempre usar conexões seguras" às configurações de segurança do navegador, o Chrome vai atualizar automaticamente toda a navegação para HTTPS e exibir alertas antes de carregar sites que não o suportam.
      Ao atualizar todas as conexões de sites para HTTPS, o Google Chrome protegerá os usuários de ataques man-in-the-middle que tentam espionar dados trocados com servidores da Internet por meio do protocolo HTTP não criptografado. O HTTPS também garante que os invasores que tentam interceptar o tráfego da Web não alterem os dados trocados com sites da Internet sem serem detectados.
    • By Bruna Chieco
      O pesquisador de segurança Konstantin Darutkin descobriu uma vulnerabilidade que permite que sites rastreiem usuários em vários navegadores de desktop diferentes, incluindo Apple Safari, Google Chrome, Microsoft Edge, Mozilla Firefox e Tor. 
      Ele publicou no FingerprintJS uma explicação sobre como a exploração funciona nos navegadores, destacando que a vulnerabilidade permite que os sites identifiquem usuários de forma confiável em diferentes navegadores de desktop e vinculem suas identidades. 
      A falha utiliza informações sobre aplicativos instalados no computador do usuário para atribuir a ele um identificador exclusivo permanente. Para gerar um identificador de dispositivo de navegador cruzado de 32 bits, um site pode testar uma lista de 32 aplicativos populares e verificar se cada um está instalado ou não. Em média, o processo de identificação leva alguns segundos e funciona em sistemas operacionais de desktop Windows, Mac e Linux.
      Esse identificador funciona mesmo se o usuário trocar de navegador, usar o modo de navegação anônima ou usar uma VPN. O navegador Tor, por exemplo, conhecido por oferecer proteção de privacidade, é afetado pela vulnerabilidade. Além disso, a vulnerabilidade permite o envio de anúncios direcionados e traça o perfil do usuário sem o seu consentimento.
      Na publicação, o pesquisador faz uma análise técnica detalhada de como a vulnerabilidade funciona, comparando ainda cada navegador.  Ele informa também que relatórios de bug foram enviados a todos os navegadores afetados, incluindo uma demonstração ao vivo e disponibilização de um repositório de código-fonte público no GitHub. "Acreditamos que vulnerabilidades como esta devem ser discutidas abertamente para ajudar os navegadores a corrigi-las o mais rápido possível", destaca. 
    • By Bruna Chieco
      O Google anunciou nesta quinta-feira, 6 de maio, uma nova seção de segurança no Google Play que tem o objetivo de ajudar as pessoas a entender os dados que um aplicativo coleta ou compartilha, se esses dados estão protegidos, e detalhes adicionais que afetam a privacidade e a segurança.
      "Trabalhamos em estreita colaboração com os desenvolvedores para manter o Google Play um espaço seguro e confiável para bilhões de pessoas aproveitarem os aplicativos Android mais recentes", diz Suzanne Frey, VP de produtos, segurança e privacidade Android, em publicação no Droid News.
      Segundo Suzanne, os desenvolvedores de apps querem maneiras simples de comunicar a segurança do aplicativo, que sejam fáceis de entender e ajudem os usuários a fazer escolhas informadas sobre como seus dados são tratados. Ela afirma que os desenvolvedores também desejam fornecer contexto adicional para explicar o uso de dados e como as práticas de segurança podem afetar a experiência do aplicativo. 
      Para isso, além dos dados que um aplicativo coleta ou compartilha, o Google introduziu na seção de segurança informações se:
      O aplicativo tem práticas de segurança, como criptografia de dados; O aplicativo segue a política do Google para famílias; O aplicativo precisa desses dados para funcionar ou os usuários têm a opção de compartilhá-los; A seção de segurança do aplicativo é verificada por um terceiro independente; O aplicativo permite que os usuários solicitem a exclusão de dados, se decidirem desinstalá-lo. O Google pedirá ainda que os desenvolvedores que compartilhem:
      Que tipo de dados são coletados e armazenados. Entre eles, opções potenciais são localização aproximada ou precisa, contatos, informações pessoais (por exemplo, nome, endereço de e-mail), fotos e vídeos, arquivos de áudio e arquivos de armazenamento; Como os dados são usados (por exemplo, para funcionalidade e personalização do aplicativo). Semelhante aos detalhes do aplicativo, como capturas de tela e descrições, os desenvolvedores são responsáveis pelas informações divulgadas em sua seção. O Google Play apresentará uma política que exige que eles forneçam informações precisas, e caso um desenvolvedor tenha deturpado os dados que forneceu, violando a política, o Google pedirá a correção do problema. Os aplicativos que não forem compatíveis estarão sujeitos à aplicação de políticas, diz Suzanne.
      Todos os aplicativos do Google Play, incluindo os próprios aplicativos do Google, serão obrigados a compartilhar essas informações e fornecer uma política de privacidade. "Estamos empenhados em garantir que os desenvolvedores tenham muito tempo para se preparar", destaca Suzanne, informando que a partir do segundo trimestre de 2022, os novos envios e atualizações de aplicativos já devem incluir essas informações.
    • By Bruna Chieco
      A rede social baseada em áudio ClubHouse supostamente está passando por problemas de segurança. Segundo o ThreatPost, pesquisadores afirmam que as conversas que ocorrem no aplicativo estão sendo gravadas.
      Aparentemente um usuário foi capaz de violar feeds de áudio de salas do ClubHouse e transmiti-los em um site. Outro usuário também supostamente escreveu um código que permite que qualquer pessoa ouça as conversas do ClubHouse sem o convite necessário para entrar na rede social. Outros códigos maliciosos projetados para violar o ClubHouse também foram bloqueados, dizem as informações.
      O ThreatPost destaca que os problemas de segurança do ClubHouse estão na plataforma de engajamento de voz e vídeo em tempo real fornecida pela startup Agora, com sede em Xangai. O tráfego do app é direcionado ao servidor da empresa na China, incluindo metadados pessoais, sem criptografia, de acordo com o Stanford Internet Observatory (SIO), que foi o primeiro a alertar sobre a privacidade do ClubHouse e as proteções de segurança da rede social.
      Assim, os usuários do ClubHouse devem estar cientes de que seus dados provavelmente estão expostos. 😒
×
×
  • Create New...