Best Practises

Oficina de Boas Praticas 3 Abril 2013

Traduções: Inglés Espanhol

WARNING: this document is heavily outdated! Please search for best practices on privacy friendly hosting elsewhere. This page is kept solely for historic purposes.

E-mail com Exim

Nvel 1

Nvel 2

tls requerido com servidores parceiros, certificado verificados com 'fingerprint'

E-mail com Postfix

Nvel 1

Se o servidor adiciona a direo IP de um usurio enviando um e-mail atravs de seu servio em qualquer parte do e-mail, o usurio informado sobre isso.

No um caso de configurao de servidor: voc deveria usar seus canais de comunicao para passar esta informao aos usurios (exemplo: newsletter, anncio da lista de e-mail). Novos usurios deveriam ser informados como parte do proceso de criao de conta. Voc deveria ter isto explicado no seu website.

As conexes entre o usurio e o servidor deveriam ser sempre encriptadas.

Use (Start)TLS para intercambiar e-mails com outros servidores disponveis em qualquer lugar.

O servidor deve ser seu prprio certificado X.509 assinado por um entre as autoridades de certificado asignadas.

H muitos problemas com o ecossistema X.509, parcialmente explicado aqui

Dependendo do quo seus usurio entendem certificados X.509, recomendamos 4 cenrios diferentes:

  1. Certificado Comercial: geralmente custa dinheiro, mas os usurios no se confundem pois os clientes de e-mail j vem com certificados comerciais, ento no haver estas mensagem de cuidado ou perigo relacionadas a certificados que no so confiveis. No aumenta a segurana da conexo, pois o adversrio pode expedir certificados pois uma autoridade de certificado pode ser dbia ou ser um estado, por exemplo. Olhe a esta pgina na Wikipedia https://pt.wikipedia.org/wiki/X.509 para mais detalhes.

  2. CaCert: Os usurios ainda necesitaro validar e instalar certificados CaCert de root pois ele ainda no estar incluido em nenhum cliente de e-mail. Mas eles j podem ter feito este passo para outros provedores. Tambm h um pacote Debian que faz isso mais fcil de instalar para usurios Debian/Ubuntu.

  3. Certificados self-signed (auto-assinados): no esto includos em clientes de e-mail padro. Eles devem instalar certificados root. Se eles no usarem "pinning" de certificado, mas tiverem outro certificado comercial ainda instalado, voc no ganhar nada alm de confuso. Voc se arrisca a ensiar seus usurios em trespassar mensagems de alarme de segurana. Se corretamente aplicado pelo seu coletivo de crypto-ninjas, isto pode ser mais seguro.

  4. Monkeysphere: Vocpode usar chaves openPGP (certificados) para autenticar servios. Isto tecnicamente uma soluo excelente, ainda que no realmente reconhecido por softwares populares. Se voc tiver conhecimento, recomendamos que tente. Mais informao em http://monkeysphere.info/

Nvel 2

O servidor no adiciona a IP do usurio enviando um e-mail atravs deste servio em nenhum lugar deste e-mail.

TLS requerido com outros servidores que cumpram o level 2. Certificados so verificados com uma 'fingerprint'.

A soluo equivalente implementar um link de IPsec entre os coletivos relevantes, o que faz o uso de TLS desnecessrio.

De maneira a implementar isto, voc precisa saber

In order to implement this, you need to know the up-to-date fingerprints of the certificates of the groups that you plan to cooperate with in this way. There are many ways to do this, but it depends too much on social and technical context so we will not detail them here, only state that it is a requirement. Pinning those fingerprints and updating them when changed can be a hassle (unless an automated and secure protocol and implementation for this purpose becomes available).