Security on ¬ just serendipity 🍀

OpenPGP

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 09 May 2014 13:49:00 -0300

♠ Em meu último post incluí uma porção de referências introdutórias ao tema, que são suficientes para que você comece a utilizar o GNUPG. Agora eu mesmo já comecei a utilizá-lo publicamente. Em suma, as duas principais razões para se ter uma chave pública são:

Autenticação: assinar (=validar) arquivos; isto é, se eu distribuir (digamos) um software para você, e eu assiná-lo com a minha chave privada, você poderá utilizar a minha chave pública para conferir se aquele arquivo foi realmente assinado por mim. Caso alguém (um man in the middle) pegue o meu arquivo original e o falsifique, fazendo-o se passar por mim, você poderá detectar que o arquivo é falso, pois a minha chave pública invalidará a assinatura desse software. Em outras palavras: a minha chave privada (que só eu tenho) é utilizada para assinar arquivos ou documentos; e a minha chave pública (disponível para todos) é utilizada como um validador da minha assinatura digital/eletrônica. Legal, né? Quer ver um exemplo? * Aqui*, meu primeiro e-mail validado com a minha chave.
Criptografia: se você quiser me enviar uma mensagem criptografada, basta você utilizar a minha chave pública para criptografá-la. Desse modo, somente eu (dono da minha chave privada) serei capaz de descriptografá-la. Da mesma maneira, se você me enviar a sua chave pública, eu poderei enviar uma mensagem criptografada para você (e somente você, com a sua chave privada, poderá descriptografá-la).

Essas razões não parecem importantes o suficiente para você? Veja bem, estamos entrando cada vez mais numa era (se é que já não entramos nela) predominantemente digital. Proteger a autenticidade e a privacidade do que postamos na rede é algo que vai adquirir cada vez mais importância. Naturalmente, ninguém vai assinar um post no facebook ou no twitter, isso é exagero (Será mesmo? Talvez daqui a uns anos não seja mais).

Mas eu acredito que toda corporação decente deveria incentivar os seus funcionários a enviar mensagens assinadas com suas chaves pessoais. Mais do que isso, toda corporação deveria ter um modelo de Web of Trust com todas as chaves de seus funcionários. Não se trata de paranoia ou de super proteger informações as quais não valem tanto esforço de serem super protegidas, mas é um passo básico na direção da privacidade moderna! O OpenPGP foi criado em 1991 (referência), agora estamos em 2014, será que isso é demais?

Vou lançar um desafio: me envie uma mensagem criptografada com a minha chave pública! Se quiser, envie nessa mensagem também a sua própria chave pública, assim eu posso te responder (também) de modo criptografado. Os links do meu post anterior são suficientes para você aprender como fazer isso. Eu espero que você se surpreenda com isso, muita gente boa troca mensagens assim.

Se eu receber pelo menos um e-mail, vou considerar escrever mais coisas a respeito de OpenPGP.

Além disso, espero criar as minhas próprias carteiras digitais {bitcoin, litecoin, dogecoin} em breve. Naturalmente, seguidas de posts de divulgação sobre elas!

Happy GPG’ing!

Update: confundir PGP e GPG é algo bastante comum. Acho que já aprendi a diferença, ao menos não cometi nenhum erro nesse post sobre isso (no post anterior eu cometi…). O nome bonito da coisa é OpenPGP; gpg é o comando (no linux) que a gente usa para gerenciar as chaves. GPG vem de “GNU Privacy Guard”).

— § —

Reply via email

#legacy #security

OpenPGP

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 26 Apr 2014 16:21:00 -0300

♠ Resolvi tomar mais um passo em direção à minha privacidade e segurança, passo esse que deveria ter tomado faz bastante tempo. Não é um passo secreto; se fosse, então esse post não existiria, naturalmente. Estou falando de PGP.

Esse post serve para mostrar que isso existe (afinal, nem todos estão cientes sobre isso) e para deixar uma coleção de links que podem ser úteis para quem quiser ler mais sobre isso ou, até mesmo, entrar nesse mundo.

Gostaria de ressaltar que esse assunto não é algo que eu considero trivial, nem que possa ser aprendido em um único dia. Existem vários conceitos de segurança e de criptografia envolvidos nisso. No entanto, acho que isso faz alguém que se importe com TI em geral aumentar a sua maturidade em relação a segurança.

You should keep your private master key very, very safe. However, keeping all your keys extremely safe is inconvenient: every time you need to sign a new package upload, you need to copy the packages onto suitable portable media, go into your sub-basement, prove to the armed guards that you’re you by using several methods of biometric and other identification, go through a deadly maze, feed the guard dogs the right kind of meat, and then finally open the safe, get out the signing laptop, and sign the packages. Then do the reverse to get back up to your Internet connection for uploading the packages.

(retirado da wiki do debian)

Links #

OBS.: ainda não utilizo a minha chave de maneira pública. Em breve.

— § —

Reply via email

#legacy #privacy #security

Bloqueando {websites,ads,malware} no Linux

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 02 Mar 2014 20:52:27 -0300

♠ “For the sake of the productivity”, notas pessoais sobre o bloqueio de websites.

1 - A forma nua e crua: /etc/hosts #

Um arquivo /etc/hosts típico é da forma:

$ cat /etc/hosts
#
# /etc/hosts: static lookup table for host names
#
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost

Para bloquear um novo site, basta redirecioná-lo localmente para localhost (=127.0.0.1). Por exemplo, para bloquear o Facebook, adicione a esse arquivo as linhas:

127.0.0.1 facebook.com
127.0.0.1 www.facebook.com

1.1 Servidor local “nulo” para localhost #

Mas essa maneira por si só é muito sem graça então, além de redirecionar para localhost, vamos fazer com que o usuário receba uma página “vazia”/“nula” ao tentar acessar esses websites. Mas isso é bastante simples, basta instalar um servidor local como o kwakd ou o pixelserv.

2 - Um pouco mais de estrutura, por favor #

O programa hostsblock é excelente para isso. Veja a página oficial. Como um bônus, você ainda bloqueia malware e ads (na verdade, esse é o objetivo primário dele), isso no sistema inteiro, não apenas no navegador – por exemplo, se você quiser instalar um Adblock, geralmente tem que instalar individualmente para todos os seus navegadores. Estou utilizando-o recentemente, e o achei bastante bom. Ele é bastante elegante (do ponto de vista de simplicidade de código) e extremamente funcional. Ao ser combinado com o dnsmasq, ele fica mais elegante ainda. Ao ser combinado com o cron, você tem uma lista de domínios a ser bloqueados que é atualizada periodicamente.

Se você quiser combiná-lo com o Network Manager e tiver problemas com isso, esse post talvez seja útil. Se você achou todos esses projetos relevantes, considere votá-los no AUR para que eles ganhem mais relevância.

Se você usa o Chromium #

OBS.: Se você utiliza o Chromium ou o Google Chrome, vai descobrir que ele é esperto e tenta contornar os websites que ele não consegue acessar. Depois de bastante pesquisa, descobri a razão para isso:

O problema é que ele fazia DNS prefetching para agilizar o carregamento de algumas páginas (ainda não estou 100% certo disso, mas tudo indica que esse era o problema). Foi difícil descobrir isso principalmente porque a maioria das discussões sobre o assunto se aplica apenas a versões antigas do Chromium (sabe, daquela época que ainda tinham dois botões, em vez de um só).

Happy blocking!

— § —

Reply via email

#dev #legacy #privacy #security