A
Anonymous
Guest
Abstract
This is the start of a How To on setting up a Home Mail Server that is meant to help to improve Citizens Privacy in e-mail communication. It will come in several chapters, each of which will occupy its own message on this thread.
Setting up your own mail server is quite involved, and you don't want to go into that if you are happy with the privacy declaration of your favourite mail hosting provider. If not, then your own home mail server could take out most of your e-mail communication (probably not all) from the radar of those many interested third parties.
Please don't expect the perfect privacy solution for all your communication needs. This does not exist by the way. A proper Home Mail Server installation will only help to prevent that your favorite Secret Service reads all your e-mails, they would have access only to some of them, and in the course of fine tuning your setup this portion could become less every day.
This How To is still a work in progress, and the chapters will be completed step-by-step by the end of this month.
This tread will start with an introduction to authentication mechanisms and password security, which is the foundation for the choices of software and configuration options made for the later chapters.
Table of Content
[POST=236392]Abstract[/POST]
1. Introduction
[POST=236393]2. Requirements[/POST]
[POST=236394]3. Installations[/POST]
[POST=236397]4. Configurations[/POST]
[POST=236401]5. Advanced Features[/POST]
The Topics below are not treated yet:
5.2 Blocking Spam
5.2.1 Before queue validation
5.2.2 Enabling Grey Listing
5.2.3 Statistical Spam Filter using CRM114 (eventually before queue)
5.3 Try encrypted direct delivery first, and use the SMTP relay only as fallback
6. Wish list for the Future
6.1 Digest-SHA3 authentication scheme for Web and Mail
6.2 Autonomous X.509 PKI
6.3 Direct End-to-end delivery + TLS
6.4 ...
1. Introduction
Many people believe that Plain authentication is secure once used together with TLS, and therefore they leave out the hassle of setting up an inherently more secure authentication mechanism.
The Dovecot documentation wiki discusses more security considerations and in this respect it is specially important to understand the relationship between the Authentication Mechanism and the Password Storage scheme, one of which must be for technical reasons Plain Text (or near to Plain Text in respect to the security quality).
So we may either have encrypted authentication with plain text (or weakly hashed) passwords in the password store, or we may have plain text authentication with strongly salted+hashed passwords in the password store on the server. The Dovecot conclusion seems to be to go with the latter, i.e. to have plain text authentication, however secured by TLS, and to stay with the benefit of a highly secured password store.
This is not necessarily a bad choice, specially if the server admin sees a certain danger that the password store can be accessed by an unauthorized 3rd party. In this case, it would be really good to have the passwords salted+hashed as strongly as possible, and as god will, let TLS secure the plain text authentication. Most probably this is the choice for small to medium companies where a considerable number of persons have access to the mail server, and who didn't set up a separate e.g. Kerberos password server. There are other points of views though:
First, I am talking about a home mail server, and if 3rd parties ever would get access to it and come even close to the password store, then the damage would be already that huge that access to the passwords would be one of my smallest concerns.
Second, even in a small company, I would setup separate servers for mail, file/web/others, and passwords.
Third, there are advanced technics of TLS interception. Companies tend to install DPI firewalls, showing a valid certificate to internal clients, so the firewall can decrypt the packets, filter on it, and encrypt it again for the transport to the final destination. So, accessing your home mail server from behind a DPI firewall potentially shows your password in clear to the company's admin(s).
Fourth, in principal said kind of DPI would work also on a larger scale, a potential MITM for example sitting in Cheltenham would only need to offer a somehow valid certificate to the client and could decrypt the traffic. Another consideration is that most TLS connections are still not providing Perfect Forward Secrecy (s. also SSL: Intercepted today, decrypted tomorrow). That means, government attackers may intercept the message, and obtain the private keys from the CA by the way of, for example a NSL accompanied with a gag order. With the private key, the whole traffic could be decrypted later on. In both cases any clear text passwords are revealed, and could be used for secret logins in order to get access to all the mails stored at that IMAP mail server for that user.
These considerations let me not to follow the suggestion of the Dovecot documentation. I choose to setup my mail server with the CRAM-MD5 authentication mechanism, staying with the drawback that the passwords in the store may only be weakly hashed by MD5.
I choose CRAM-MD5 because all of my clients (Mac OS X 10.8 and iOS 7) do support this for IMAP, POP3, and SMTP-Auth. Even, if MD5 is nowadays vulnerable to brute force attacks by its own, in the CRAM-MD5 scheme, it can be still considered safe against online attacks, i.e. cracking the scheme in the course of the connection. However, an offline dictionary or brute force attack to recover the password seems to be feasible after intercepting a successful CRAM-MD5 protocol exchange.
Yes, CRAM-MD5 and Digest-MD5 came to age, and I would love to see a Digest-SHA512 authentication mechanism, but it doesn't exit yet and we have to live with what we have. It is worth to note, that MD5 is not completely useless. The occasional brute force cracker would already have a hard time for passwords with more than 10 characters in length, and also super computers would take a reasonable amount of dedicated time for brute-forcing a 13 char password. Reasonable means, that it didn't finish until you rotated your password anyway, let's say once in a month. Dedicated means, that this computer wouldn't do anything else than trying to crack your password. The budget of the best equipped Secret Service would be rapidly exhausted, if they want to do this for millions of intercepted CRAM-MD5 sessions.
In addition to length (>11 chars), the usual advises for password strength keep-on being valid - use the full character set, i.e. alphanumerics, punctation, accented chars, etc. In this respect it helps a lot to switch from short Passwords to long Passphrases. Something like:
"≤Ach wie gut, daß niemand weiß, daß ich Rumpelstilzchen heiß.≥"
Again, it is advised to change this frequently.
Anyway, I forced my server to use TLS ciphers that provide Perfect Forward Secrecy. For this, I need to install OpenSSL from the ports. In addition, keeping NSLs accompanied with gag orders in mind, it is nowadays a better choice to only rely on your own certification authority, i.e., self sign your own certificates, and don't trust anybody.
This is the start of a How To on setting up a Home Mail Server that is meant to help to improve Citizens Privacy in e-mail communication. It will come in several chapters, each of which will occupy its own message on this thread.
Setting up your own mail server is quite involved, and you don't want to go into that if you are happy with the privacy declaration of your favourite mail hosting provider. If not, then your own home mail server could take out most of your e-mail communication (probably not all) from the radar of those many interested third parties.
Please don't expect the perfect privacy solution for all your communication needs. This does not exist by the way. A proper Home Mail Server installation will only help to prevent that your favorite Secret Service reads all your e-mails, they would have access only to some of them, and in the course of fine tuning your setup this portion could become less every day.
This How To is still a work in progress, and the chapters will be completed step-by-step by the end of this month.
This tread will start with an introduction to authentication mechanisms and password security, which is the foundation for the choices of software and configuration options made for the later chapters.
Table of Content
[POST=236392]Abstract[/POST]
1. Introduction
[POST=236393]2. Requirements[/POST]
2.1 The ISP must not block port 25
2.2 The Domain Name
2.3 Dynamic DNS Configuration
2.2 The Domain Name
2.3 Dynamic DNS Configuration
2.3.1 Checking Dynamic DNS
2.3.2 Creating a Dynamic DNS Request File and the Update Script
2.3.3 Utilizing the Update Script for Automatic Dynamic DNS Updating
2.3.2 Creating a Dynamic DNS Request File and the Update Script
2.3.3 Utilizing the Update Script for Automatic Dynamic DNS Updating
[POST=236394]3. Installations[/POST]
3.1 Installation of OpenSSL from the ports, and re-building of all ports depending on OpenSSL
3.2 Installation of Dovecot IMAP Server + Dovecot SASL
3.3 Installation of Cyrus SASL2
3.4 Postfix Mail Server
3.2 Installation of Dovecot IMAP Server + Dovecot SASL
3.3 Installation of Cyrus SASL2
3.4 Postfix Mail Server
[POST=236397]4. Configurations[/POST]
4.1 Creating a self-signed certificate chain
4.2 Configuration of Dovecot IMAP/POP3
4.5 Disable Sendmail and Start-Up Dovecot/Postfix
4.2 Configuration of Dovecot IMAP/POP3
4.2.1 The Virtual Users Store
[POST=236398]4.2.2 The Mail Directory[/POST]
4.2.3 The Dovecot Configuration File
4.3 Configuration of the Postfix Mail Transfer Agent[POST=236398]4.2.2 The Mail Directory[/POST]
4.2.3 The Dovecot Configuration File
4.3.1 Relay Host Configuration
4.3.2 Local Recipients and Mail Aliases
4.3.3 The Postfix Configuration Files
[POST=236399]4.4 Syslog Configuration[/POST]4.3.2 Local Recipients and Mail Aliases
4.3.3 The Postfix Configuration Files
4.5 Disable Sendmail and Start-Up Dovecot/Postfix
[POST=236401]5. Advanced Features[/POST]
5.1 Web Mail
5.1.1 Installations for Roundcube Web Mail
5.1.2 Configuration of Web Mail with Roundcube
[POST=236402]5.1.3 Roundcube with HTTP Digest Authentication[/POST]
[POST=236404]5.1.4 The Roundcube HTTP Digest Authentication Plugin[/POST]
5.1.2 Configuration of Web Mail with Roundcube
[POST=236402]5.1.3 Roundcube with HTTP Digest Authentication[/POST]
[POST=236404]5.1.4 The Roundcube HTTP Digest Authentication Plugin[/POST]
The Topics below are not treated yet:
5.2 Blocking Spam
5.2.1 Before queue validation
5.2.2 Enabling Grey Listing
5.2.3 Statistical Spam Filter using CRM114 (eventually before queue)
5.3 Try encrypted direct delivery first, and use the SMTP relay only as fallback
6. Wish list for the Future
6.1 Digest-SHA3 authentication scheme for Web and Mail
6.2 Autonomous X.509 PKI
6.3 Direct End-to-end delivery + TLS
6.4 ...
1. Introduction
Many people believe that Plain authentication is secure once used together with TLS, and therefore they leave out the hassle of setting up an inherently more secure authentication mechanism.
The Dovecot documentation wiki discusses more security considerations and in this respect it is specially important to understand the relationship between the Authentication Mechanism and the Password Storage scheme, one of which must be for technical reasons Plain Text (or near to Plain Text in respect to the security quality).
So we may either have encrypted authentication with plain text (or weakly hashed) passwords in the password store, or we may have plain text authentication with strongly salted+hashed passwords in the password store on the server. The Dovecot conclusion seems to be to go with the latter, i.e. to have plain text authentication, however secured by TLS, and to stay with the benefit of a highly secured password store.
This is not necessarily a bad choice, specially if the server admin sees a certain danger that the password store can be accessed by an unauthorized 3rd party. In this case, it would be really good to have the passwords salted+hashed as strongly as possible, and as god will, let TLS secure the plain text authentication. Most probably this is the choice for small to medium companies where a considerable number of persons have access to the mail server, and who didn't set up a separate e.g. Kerberos password server. There are other points of views though:
First, I am talking about a home mail server, and if 3rd parties ever would get access to it and come even close to the password store, then the damage would be already that huge that access to the passwords would be one of my smallest concerns.
Second, even in a small company, I would setup separate servers for mail, file/web/others, and passwords.
Third, there are advanced technics of TLS interception. Companies tend to install DPI firewalls, showing a valid certificate to internal clients, so the firewall can decrypt the packets, filter on it, and encrypt it again for the transport to the final destination. So, accessing your home mail server from behind a DPI firewall potentially shows your password in clear to the company's admin(s).
Fourth, in principal said kind of DPI would work also on a larger scale, a potential MITM for example sitting in Cheltenham would only need to offer a somehow valid certificate to the client and could decrypt the traffic. Another consideration is that most TLS connections are still not providing Perfect Forward Secrecy (s. also SSL: Intercepted today, decrypted tomorrow). That means, government attackers may intercept the message, and obtain the private keys from the CA by the way of, for example a NSL accompanied with a gag order. With the private key, the whole traffic could be decrypted later on. In both cases any clear text passwords are revealed, and could be used for secret logins in order to get access to all the mails stored at that IMAP mail server for that user.
These considerations let me not to follow the suggestion of the Dovecot documentation. I choose to setup my mail server with the CRAM-MD5 authentication mechanism, staying with the drawback that the passwords in the store may only be weakly hashed by MD5.
I choose CRAM-MD5 because all of my clients (Mac OS X 10.8 and iOS 7) do support this for IMAP, POP3, and SMTP-Auth. Even, if MD5 is nowadays vulnerable to brute force attacks by its own, in the CRAM-MD5 scheme, it can be still considered safe against online attacks, i.e. cracking the scheme in the course of the connection. However, an offline dictionary or brute force attack to recover the password seems to be feasible after intercepting a successful CRAM-MD5 protocol exchange.
Yes, CRAM-MD5 and Digest-MD5 came to age, and I would love to see a Digest-SHA512 authentication mechanism, but it doesn't exit yet and we have to live with what we have. It is worth to note, that MD5 is not completely useless. The occasional brute force cracker would already have a hard time for passwords with more than 10 characters in length, and also super computers would take a reasonable amount of dedicated time for brute-forcing a 13 char password. Reasonable means, that it didn't finish until you rotated your password anyway, let's say once in a month. Dedicated means, that this computer wouldn't do anything else than trying to crack your password. The budget of the best equipped Secret Service would be rapidly exhausted, if they want to do this for millions of intercepted CRAM-MD5 sessions.
In addition to length (>11 chars), the usual advises for password strength keep-on being valid - use the full character set, i.e. alphanumerics, punctation, accented chars, etc. In this respect it helps a lot to switch from short Passwords to long Passphrases. Something like:
"≤Ach wie gut, daß niemand weiß, daß ich Rumpelstilzchen heiß.≥"
Again, it is advised to change this frequently.
Anyway, I forced my server to use TLS ciphers that provide Perfect Forward Secrecy. For this, I need to install OpenSSL from the ports. In addition, keeping NSLs accompanied with gag orders in mind, it is nowadays a better choice to only rely on your own certification authority, i.e., self sign your own certificates, and don't trust anybody.