Appendix: Best practices references

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

Translations: Castellano Português

This appendix contains the text of the policy with specific best practices added below relevant sections. It is a work in progress. Please help expand!

Obviously, every security/privacy level requires that you keep your software up to date to the current knowledge of security issues.

Mail with Exim

Level 1

Level 2

TLS is required with other level 2 compliant servers. Certificates are verified with fingerprint.

Mail with Postfix

Level 1

If the server adds the IP address of a user sending a mail through its service anywhere in the email, the user is informed about this.

Not a matter of server configuration: you should use your communication channels to pass this information to your existing users (e.g. newsletter, announcement mailing list). New users should be informed as part of the account signup process. You may additionally explain this on your website.

The connections between the user and the server are always encrypted.

Use (Start)TLS to exchange mails with other servers whenever available

  • This is called opportunistic encryption.

The server must have its own X.509 certificate signed by one of a given set of certificate authorities.

There are many problems with the X.509 ecosystem, partly explained here: http://lair.fifthhorseman.net/~dkg/tls-centralization/

Depending on how well your users understand X.509-certifcates, we recommend 4 different scenarios:

  1. Commercial Cert. Authority: usually costs money, but users do not get confused because their mail clients are shipped with commercial root certificates, so there will be no warning messages about untrusted certificate chains. Doesn't necessarily increase the connection security if the adversary can issue certificates because a certificate authority has gone rogue or is a state, for example. See the Security Section on wikipedia for more details.

  2. CaCert: Users still need to validate and install CaCert's root certificates because it's not included in any mail client. But they might already have done that step for other providers. There is also a Debian package which makes it easy for Debian/Ubuntu users to install it.

  3. Self Signed certificates/Own Authority: con: not included in the default mail user clients of your users. They have to install the (root-)certificates. If they don't use certificate pinning and have other commercial authorities still installed you win nothing but confusion. You risk to teach your users into bypassing security warning messages. If properly applied by your collective of crypto-ninjas, it can be more secure.

  4. Monkeysphere: You can use openPGP keys (certifications) to authenticate services. This is technically an excellent solution, albeit not really supported in popular software. If you have power users, we recommend trying it out. More information on Monkeysphere website

Level 2

The server doesn't add the IP address of a user sending a mail through its service anywhere in the email.

TLS is required with other level 2 compliant servers. Certificates are verified with fingerprint.

An equivalent solution is to implement an IPsec link between relevant collectives which makes it unnecessary to use TLS. 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).

Level 3

Mail is also available as a hidden Tor service.

Filesystems and Storage

Level 1

  • User data that is not publicly accessible is stored encrypted, using a strong passphrase. See best practices documents for details. This includes mails, databases, list archives, restricted websites and others.

In GNU/Linux, cryptsetup:

Level 2

Swap is stored encrypted.

For this you can use said cryptsetup too.

The operating system and its configuration is stored encrypted with a strong passphrase. See best practices documents for details.

Today you can use many OS installers that achieve this: Ubuntu alternative text installer?

Don't rely on hard drives that promote encryption on the disklayer, they are often not properly implemented or come with backdoors for example

Level 3

  • Swap is encrypted with a random key on boot.
  • Create an encrypted swap area http://www.microhowto.info/howto/create_an_encrypted_swap_area.html https://we.riseup.net/debian/encrypted-swap http://linux.die.net/man/5/crypttab -> section "swap"

Older best practices

Mail

  • IPs in headers the user's home IP address should not appear in any email headers. level 2
  • if it does appear, users must be informed about this level 1 perhaps use server IP instead of localhost for riseup hack
  • The connection between the server and the user is always encrypted. level 2
  • optional unencrypted communication between user and server are visibly marked as insecure level 1
  • StartTLS-postfix or StartTLS-exim starttls with other compliant servers’, certs verified against cacert/... level 1
  • StartTLS-exim tls is required with other compliant servers’, certs verified with fingerprint level 2

Certificates and keys for encrypted stream-based services

  • Private keys are only stored encrypted Level 2
  • Private keys are only stored encrypted and off-site Level 3
  • Stream-based communication uses only a well-established set of cryptographic parameters (ciphers, message digests, asymmetric encryption algorithms, etc). See best practices documents for details. Level 1

If you are using mod_ssl with apache and an RSA key for the server, somebody tentatively suggests: SSLCipherSuite TLSv1:!MD5:!EXP:!LOW:!NULL:!MEDIUM:!ADH:!DSS

Logging

  • Logs containing user identifiable information are stored encrypted or only in memory. Otherwise the users are informed about this. level 1
  • Logs contain no user identifiable information. level 3

Apache logs have no IP addresses: mod_removeip

Under Debian with Apache2:

  apt-get install libapache2-mod-removeip
  a2enmod removeip
  /etc/init.d/apache2 force-reload
  • Logs containing information about non-individual user activities are stored encrypted or only in memory. level 1
  • Logs contain no information about non-individual user activities. level 2
  • System logs (not related to user activities) is stored encrypted or only in memory. level 2

Comes with "Filesystem and Storage Level 2"

  • System logs (not related to user activities) are not stored. level 3