Autonomous Servers Security Protocols (ASSP)
version 0.0.1 - See /Comments
We are autonomist and revolutionary tech collectives which work to provide freedom of communication to liberatory social movements.
These protocols are a set of common practices designed to ensure the privacy and security of our users.
General
- Keep your software up to date to the current knowledge of security issues
What to do in case of fire?
- Make sure to have means of communication to users when the server goes down
- IPs in headers: the user's home IP address should not appear in any email headers.
- if it does appear, users must be informed about this
- ? use server IP instead of localhost for riseup hack
- The connection between the server and the user has to be encrypted by default.
- optional unencrypted communication between user and server must be noted as insecure
- StartTLS: starttls with verified certs when connecting with other ASSP providers.
Webmail
- Secure connections: The server has to offer encrypted connections between the server and the user as default
- Optional unencrypted connections must be noted as insecure
- Session cookies: all sessions must be stored as cookies. Session IDs cannot be in the URL.
Hosting
- Secure connections: all authentification to the server must be encrypted. Where possible the entire data stream should be encrypted.
Certificates and SSL
- Private Keys: the private keys of certificates must be stored offsite or on encrypted partitions.
Strong Crypto: here is a list of acceptable ciphers: <To be determined>. for example: SSLCipherSuite HIGH:-SSLv2:-RSA
- Certificate authority: our server certificates come from one of these certificate authorities and we validate other servers certificates against these authorities:
- cacert.org
- ??????
Filesystems and Storage
- Swap: swap must be encrypted, using either dmcrypt or loopaes.
- System data:
- (optional) User data: all user data stored on encrypted partitions (or otherwise encrypted). This includes email, databases, list archives, etc.
Logging
- Logs with user identifiable information must be stored encrypted.
- (optional) No identifiable user information in logs. When turned on temporarily in order to detect attacks or abuse, logs should be held in memory or on encrypted partitions.
Users
- Educate users about good passwords and policies. Never send them in clear text, never use them for multiple services.
- Force users to use good passwords where possible.
- Shell Sandbox: shell accounts for users only in vservers, separate boxes, or similar sandboxes. No end user should should have a login on a server that provides sensitive services.