1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
# Appendix: Best practices references
Translations: [[Castellano|best practices_es]] [[português|best practices_pt]]
*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.
* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt)
# 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.
* Server Side: [Configure Postfix to use X.509 certificate](http://koti.kapsi.fi/ptk/postfix/postfix-tls-cacert.shtml) retrieved on Apr 3 2013
* Client side: Kindly ask your provider for documentation :)
### 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:
a. 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](https://en.wikipedia.org/wiki/X.509#Security) for more details.
b. 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.
c. 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.
d. 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](http://monkeysphere.info/)
## Level 2
### The server doesn't add the IP address of a user sending a mail through its service anywhere in the email.
* [IPs in headers]( https://we.riseup.net/debian/mail#postfix )
### 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).
* [Postfix TLS README](http://www.postfix.org/TLS_README.html )
## Level 3
### Mail is also available as a hidden Tor service.
* [Torproject: Tor Hidden Service documentation](https://www.torproject.org/docs/tor-hidden-service.html.en) → adapt to the needs of a mailserver.
* Client: [torbirdy](https://trac.torproject.org/projects/tor/wiki/torbirdy) is a useful Thunderbird extension to make use of such a hidden 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:
* [How to set up an encrypted filesystem in several easy steps?](http://www.debian-administration.org/articles/469)
* [Setting up an encrypted Debian system](http://madduck.net/docs/cryptdisk/)
## 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](http://riseuplabs.org/privacy/postfix/) 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](http://riseuplabs.org/privacy/postfix/)
* 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](http://metatron.sh/kmw/Transformers/PostfixCacertVerifyHowto) or [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) starttls with other compliant servers’, certs verified against cacert/... *level 1*
* [StartTLS-exim](http://aland.burngreave.net/archives/2009/12/30/index.html#e2009-12-30T16_26_49.txt) 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:
<code>SSLCipherSuite TLSv1:!MD5:!EXP:!LOW:!NULL:!MEDIUM:!ADH:!DSS</code>
## 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](http://riseuplabs.org/privacy/apache/)
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*
|
