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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Providers' Commitment for Privacy: Version 1.0
1. Preamble
2. Description of the security levels
1. Short overview of level 1
2. Short overview of level 2
3. Short overview of level 3
3. Modules
1. What to do in case of fire?
2. Mail
3. Webmail
4. Certificates and keys for encrypted stream-based services
5. Filesystems and Storage
6. Logs
7. Users
8. Evaluation of policy compliance
Preamble
This document contains many social and technical issues, that should lead to a more secure handling of private user data.
In light of the increased surveillance and repression measures established by many governments in the first decade of this millennium, it is now even more necessary to improve users' understanding and awareness of privacy matters, as well as the privacy levels offered by tech collectives and groups.
With this draft, we are trying to create more transparency for our users. This document states what users can expect from the tech collectives and groups that signed it, in terms of the use of encryption, logging of ip's and data storage.
Another reason to write this document is to encourage a privacy/security awareness amongst us. This draft can be used to put pressure on sysadmins, collectives and groups to do the right thing. In order to reduce the work involved, the signing tech collectives and groups share knowledge and write down standards that can be implemented by other tech collectives and groups.
This being said, beware:
1. The fact that a tech collective or group signed this document is not a guarantee in itself; as a user you should have a trust relationship with the tech collective or group based on personal relations, not on signatures. Your data can only be as secure as the human beings who maintain the server it is stored on.
2. There is no such thing as a perfectly secure server! Human mistakes and software bugs can disclose your data, reveal your identity, send you to jail and kill your kitten.
3. Nothing that your preferred tech collective or group does will be enough to protect you from intense directed scrutiny from a powerful organization. If you suspect you are the target of special surveillance, you need to take your own privacy into your own hands.
Description of the security levels
The computer is to the information industry roughly what the central power station is to the electrical industry. -- Peter Drucker
There is no such thing as service that is both perfectly secure and one that fully protects the end-user's privacy. The policy defined below thus is designed to enumerate different levels of security and privacy. Each tech collective should try to reach the highest possible level. Even at the highest defined level, the ideal setup may be somewhere beyond what is proposed in this document. In many cases it will be impossible to fulfill some points due to various problems: technical, social, resources, etc. The levels defined are intended to make it easier for users of services to understand, and as a result, make better decisions about the security and privacy of their data. They also should serve as guidelines for sysadmins who need an overview of the various aspects involved in these important issues and some of the goals that they should strive to attain.
The policy defines three levels of security and privacy. The first level (level 1) contains basic requirements for services, its defined as less secure and providing less privacy assurances than “level 2”. Fulfilling the requirements of the highest level (level 3) will be the most challenging to implement for the technical collectives and will, in most cases, protect users’ data better. The following descriptions of the levels are meant to give a short overview of the key differences between each. Please refer to the specific list of requirements for more details. Yet beware, the higher the level, the harder it is to achieve or verify for the user.
Short overview of level 1
* Connections to all services are encrypted by default. If a non-encrypted alternative connection is offered, then this must be marked visibly to warn users.
* Mail sent through the service can possibly include user identifiable information (e.g. the IP address of the originating host).
* Only data that is not already publicly accessible has to be stored encrypted (e.g. user private data)
* It is possible that user identifiable logs are stored without encryption.
* Compliance with the policy is reviewed by the administrators at least once in a year.
Short overview of level 2
* Connections between users and the services they use are always encrypted.
* Mails contain no user identifiable information.
* No user identifiable information are stored in logs.
* The operating system of the service and its configuration are only stored encrypted.
* Compliance with the policy is reviewed by the administrators at least once within six months.
Short overview of level 3
* All services are also available as hidden Tor services.
* No logs are stored.
* Compliance with the policy is reviewed by the administrators at least once within three months.
Modules
Obviously, every security/privacy level requires that you keep your software up to date to the current knowledge of security issues.
What to do in case of fire?
Level 1
* Make sure to have means of communication to users when the server goes down. This can be an alternative communication channel (e.g. external mail, phone, ...) or an off-site status web page.
Mail
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.
* The connections between the user and the server are always encrypted.
* Use StartTLS to exchange mails with other servers whenever available.
* The server must have its own SSL certificate signed by one of a given set of certificate authorities. See best practices documents for details.
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.
Level 3
* Mail is also available as an enclaved hidden Tor service.
Webmail
Level 1
* The connections between the server and the user are always encrypted.
* If the user's IP address appears in the email headers, this fact is visibly marked as insecure.
Level 2
* All sessions must be stored as cookies. Session IDs cannot be in the URL.
* The user's IP address does not appear in any email headers.
Level 3
* Due to the fact that client-side scripting, such as Javascript, can reveal the user's IP address (this is why users of Tor typically disable it), Webmail is functional without it.
* The session ID algorithm and cookies do not use or store the user's IP address, neither in plain text or some garbled form. Sessions are not restricted to IP addresses (since this would prevent access with anonymity tools such as Tor).
* Webmail is also available as an enclaved hidden Tor service.
Certificates and keys for encrypted stream-based services
Level 1
* 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 2
* Private keys are only stored encrypted.
Level 3
* Private keys are only stored encrypted and off-site.
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.
Level 2
* Swap is stored encrypted.
* The operating system and its configuration is stored encrypted with a strong passphrase. See best practices documents for details.
Level 3
* Swap is encrypted with a random key on boot.
Logs
Level 1
* Logs are stored encrypted or only in memory.
Level 2
* Logs are anonymized and contain no information that can identify user activities.
Level 3
* No logs of any kind are stored.
Users
Level 1
* Users are advised about good passwords and polices. See best practices documents for details.
Level 2
* Users are forced to use strong passwords, as measured by a generally accepted password strength algorithm. See best practices documents for details.
* Shell accounts for users are only in vservers, separate boxes, or similar sandboxes. No end user have a login on a server that provides sensitive services. See best practices documents for details.
Level 3
* Shell accounts are isolated from other users: each user's shell account exists in a chrooted environment that has no visibility into other user's environments (files, processes, etc.).
Evaluation of policy compliance
Level 1
* Yearly periodic self-evaluation: checking at least every twelve months that requirements supposed to be achieved actually are.
Level 2
* Semi-yearly self-evaluation: checking at least every six months that requirements supposed to be achieved actually are.
Level 3
* Quarterly self-evaluation: checking at least every three months that requirements supposed to be achieved actually are.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJO+m5gAAoJEIvA5znQZFhDrFEQALgM/fg4rc+Jw78/c0kjFT3P
IA2kOqWRdKQDA0fxr+S5fzpMOhTYxQjWCOGQq+l6VtPr5nBOXvYhX/r7Wg8VJde6
GZqZIaBPPZGq6cNa7p5lhN4NKmARu9x5JYVE3PCEGQALvellgNAbrIuMcYp6UIJZ
fFVPJrYiMBpVDpF1mauv4UK4UBRKPo+DzFHZverbFvnBZ4CE5QUSTEa0LHFyrTxX
E5vwIX6m6EEVBzdUtHZD9WOM6mOiGgRT6LOHy2NPy+YERvGUUQyb2PqTzxgnBzWB
Cqfh6Ki0f9ZVlt5ctr83EUmd5h3DwfZH1rKaCRKZ0tw/wsP1aA6BkHhhH4VP1uov
5UTjpRmVbs9evqy+aiO+BRCXdJK0/eZv4wWaK/j4D3aDaZ4Vhotw8i/+A+xB5GF0
tjrGGO+7XfaQYTtz1aeTMMmrfJBTYO0Bzs8jH1kY41NYy36lMaxGGgf0wNS+IuP/
n1oaf8VD4MBxPjR1lEIXBtUq/OYSWr69UsKniFmsTXqx4U35geVQugpKT+ILfeHX
NHeF4Tnsz3siIy4FpMLOcCYbihf+LAJm8/HyukODEdrb7dkjlyT9ivE7rH2GA+uc
eb1NIfBveYHu2o+WbENHKqXFNVO+p6kw3vfR4Le98pGVhrOPMiFfmfe9SrhRq8Yb
wn3EbWa/UcVhXGnUQgoV
=HQyf
-----END PGP SIGNATURE-----
|