I am running Postfix and Dovecot on my mail server. I am required now to have SSL/TLS on my mail server. I did check and found out that I have a SSL certificate with Verisign issued to my mail servers FQDN. Now my question is when reading the Dovecot Wiki, I noticed it said that it is not common to use SSL but rather TLS on most mail servers. Even though SSL will work, which should I use on my server? We already have a purchased SSL certificate but does that really matter? Should I simply just revoke that certificate & use TLS instead?
So when I read this link:
http://wiki.dovecot.org/SSL/DovecotConfiguration
Is it talking about a actual SSL certificate or TLS?
Thanks for any clarification!
- Carlos
On 6/26/2009 2:53 PM, Carlos Williams wrote:
http://wiki.dovecot.org/SSL/DovecotConfiguration
Is it talking about a actual SSL certificate or TLS?
Thanks for any clarification!
There's no such thing as a 'TLC Certificate'... TLS uses standard SSL certs, so just use your current one no worries... :)
--
Best regards,
Charles
Carlos Williams пишет:
Is it talking about a actual SSL certificate or TLS?
You should read this: http://en.wikipedia.org/wiki/Transport_Layer_Security
Your certificate is ok and will work with SSL&TLS. SSL just binds to special port(like 993 in IMAP by default).
-- Best regards, Proskurin Kirill
On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:
SSL just binds to special port(like 993 in IMAP by default).
No, SSL is a protocol, just like TLS. It doesn't bind to any ports. http://wiki.dovecot.org/SSL
Timo Sirainen wrote:
On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:
SSL just binds to special port(like 993 in IMAP by default).
No, SSL is a protocol, just like TLS. It doesn't bind to any ports. http://wiki.dovecot.org/SSL
To illustrate, both SSL and TLS as implemented in Dovecot utilize "SSL certificates."
A typical "TLS" session will work as follows:
1 The client connects to the IMAP service on port 143, unencrypted. 2 The server announces that it speaks TLS. 3 The client says "Ok, let's talk encrypted." 4 Magic occurs, and the session becomes encrypted. This step is where your "SSL" certificate is used. 5 The rest of the session is encrypted.
/Usually/, when people refer to SSL as opposed to TLS, they mean IMAPS or POPS. These differ in that there's no "Hey, I speak TLS" step. It is assumed that the conversation will begin according to some secure protocol, kind of like when you connect to a web server on port 443.
1 The client connects to IMAPS on port 993, and performs the secure handshake. Your "SSL" certificate is used in here somewhere. 2 Once the handshake has completed, the rest of the session is secure.
When implementing IMAPS/POPS you will usually use a different port, because if you tried to talk plaintext to the server, it would appear to be speaking gibberish (whatever secure protocol is being used).
With TLS enabled on a normal IMAP port, the switch from plaintext to encrypted is optional. Although, it's usually a good idea to force TLS, too.
Much of the confusion comes from the fact that you can use either protocol, TLSv1 or SSLv3 after the "Hey I speak TLS" step. Likewise, you can use TLSv1 with IMAPS or POPS, though it's use will be implied and there will be no "Hey, I speak TLS" step. There's really no agreement amongst mail clients as to the meaning of "Use SSL" and "Use TLS."
You may find it easiest to concentrate on the one distinction: does the session begin encrypted, or does it switch from plaintext to encrypted at some point? Once you've answered that, either of the SSLv3 or TLSv1 protocols can be used, and they will both use your "SSL" certificate.
Ultimately, you may wind up using both, depending on your user base. Many versions of Outlook are screwy with regard to one or both of these methods.
On Fri, Jun 26, 2009 at 5:46 PM, Michael Orlitzkymichael@orlitzky.com wrote:
A typical "TLS" session will work as follows:
1 The client connects to the IMAP service on port 143, unencrypted. 2 The server announces that it speaks TLS. 3 The client says "Ok, let's talk encrypted." 4 Magic occurs, and the session becomes encrypted. This step is where your "SSL" certificate is used. 5 The rest of the session is encrypted.
Thats a great and informative breakdown. I guess I just don't see a benefit of using either over another. It would appear that using SSL where the session is assumed before established to be encrypted rather than switching to encrypted just saves time. They both appear to do the same thing. Obviously from what I read, TLS is newer than SSL but sometimes thats not always a good thing. I just don't know in this case. Do you recommend I do one over the other? I don't really have a requirement here at all yet so that being said, I would rather someone who has better understand of this tell me what they would do for a simple Postfix / Dovecot install on a Linux server.
Any recommendations?
Carlos Williams wrote:
On Fri, Jun 26, 2009 at 5:46 PM, Michael Orlitzkymichael@orlitzky.com wrote:
A typical "TLS" session will work as follows:
1 The client connects to the IMAP service on port 143, unencrypted. 2 The server announces that it speaks TLS. 3 The client says "Ok, let's talk encrypted." 4 Magic occurs, and the session becomes encrypted. This step is where your "SSL" certificate is used. 5 The rest of the session is encrypted.
Thats a great and informative breakdown. I guess I just don't see a benefit of using either over another. It would appear that using SSL where the session is assumed before established to be encrypted rather than switching to encrypted just saves time. They both appear to do the same thing. Obviously from what I read, TLS is newer than SSL but sometimes thats not always a good thing. I just don't know in this case. Do you recommend I do one over the other? I don't really have a requirement here at all yet so that being said, I would rather someone who has better understand of this tell me what they would do for a simple Postfix / Dovecot install on a Linux server.
The benefit of using TLS via STARTTLS (Hey, I speak TLS...) is that you can offer both encrypted and plaintext IMAP on the same port. Since you don't want to offer plaintext IMAP, you're correct that there isn't much difference between the two.
Your users will most likely determine which method(s) you can use. Start out with one, and then add the other if anyone has trouble. Both are perfectly secure as long as you don't allow plaintext authentication (disable_plaintext_auth = yes) [1].
IMAPS on port 993 has better client support in my experience, but occasionally, port 993 will be blocked e.g. at universities where the admins have never heard of it.
Postfix is a different story. You have to support plaintext SMTP if you want to receive mail. Encryption on port 25 is therefore, at best, optional. This makes TLS via STARTTLS the obvious choice.
Do your users submit mail to port 25 (SMTP), or 587 (submission)? If the latter, then the Postfix configuration is particularly simple. The configuration below will set a default where TLS is optional for all incoming messages. Then, in master.cf, that default is overwritten to force TLS on port 587.
main.cf
smtpd_tls_security_level = may smtpd_tls_cert_file = <your cert> smtpd_tls_key_file = <your key>
master.cf
submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
[1] Caveat: When you set disable_plaintext_auth = yes, and a client connects on port 143, Dovecot basically says "DON'T SEND YOUR PASSWORD IN PLAIN TEXT BECAUSE IT WON'T WORK." There is at least one client -- I don't remember which -- that ignores this and sends the password *in plain text* anyway. Someone on this list can probably identify the client. If any of your users insist on using it, stick with IMAPS on port 993.
Carlos Williams a écrit :
On Fri, Jun 26, 2009 at 5:46 PM, Michael Orlitzkymichael@orlitzky.com wrote:
A typical "TLS" session will work as follows:
1 The client connects to the IMAP service on port 143, unencrypted. 2 The server announces that it speaks TLS. 3 The client says "Ok, let's talk encrypted." 4 Magic occurs, and the session becomes encrypted. This step is where your "SSL" certificate is used. 5 The rest of the session is encrypted.
Thats a great and informative breakdown. I guess I just don't see a benefit of using either over another. It would appear that using SSL where the session is assumed before established to be encrypted rather than switching to encrypted just saves time. They both appear to do the same thing. Obviously from what I read, TLS is newer than SSL but sometimes thats not always a good thing. I just don't know in this case. Do you recommend I do one over the other? I don't really have a requirement here at all yet so that being said, I would rather someone who has better understand of this tell me what they would do for a simple Postfix / Dovecot install on a Linux server.
Any recommendations?
ok I will explain how I see things about TLS and SSL and how I configured our mail server and our network in the university. (because of the diffiiculty of the langage these is translate by google with some adjustement) My view is a simplistic and paranoid: there is a local network where are the colleagues and the gentiles, and there are outdoor, internet, populated by villains, thieves, spies who do everything for you not steal only passwords but also your correspondence. When colleagues leave the local network to go outside with their laptops. if they want to check their mail, we must tell them : configure your mail client (thunderbird) to use TLS. In reality, these colleagues do not configure their client to use TLS, despite our advice, because on port imap (143) they can read mail in plain text without TLS. why do they bother to go to a panel that they did not understand, to check boxes mysterious while it works very well like that. As against them if you delete the imap port (143) even with TLS and leave only the SSL port (993). Members are required to configure the client to use SSL. and you can safely send out the encrypted connection is required. This is the protocol: the server announces its capability but can not force the use of TLS which is an initiative of the client.
So for our server configuration, I enabled port 143 (with TLS) and 993, port 143 is only accessible from the local network, and is filtered by a firewall for internet connections (iptable or ACL iptable cisco do this very well). In reality, it is obviously more complicated because we have vlan and vpn.
jean-noël
On Sat, 2009-06-27 at 20:06 +0200, Jean-Noel Chardron wrote:
This is the protocol: the server announces its capability but can not force the use of TLS which is an initiative of the client.
Server can't force clients to do STARTTLS, but it can prevent clients from being able to log in without it. This is what Dovecot does by default, with disable_plaintext_auth=yes. If it's enabled and STARTTLS isn't used and client tries to log in, Dovecot says:
1 login foo bar
- BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed. 1 NO [CLIENTBUG] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
Timo Sirainen a écrit :
On Sat, 2009-06-27 at 20:06 +0200, Jean-Noel Chardron wrote:
This is the protocol: the server announces its capability but can not force the use of TLS which is an initiative of the client.
Server can't force clients to do STARTTLS, but it can prevent clients from being able to log in without it. This is what Dovecot does by default, with disable_plaintext_auth=yes. If it's enabled and STARTTLS isn't used and client tries to log in, Dovecot says:
1 login foo bar
- BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed. 1 NO [CLIENTBUG] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
very interesting, I didn't think about it. This may indeed be the case. and thus forcing the users to make the choice of TLS in a hostile environment. however then this rule will also apply to an environment of "friendly" on the local network. This is not the goal for sedentary among us, unless the default configuration of clients was not "plain text" but "do TLS if possible".
Michael Orlitzky schrieb:
Timo Sirainen wrote:
On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:
SSL just binds to special port(like 993 in IMAP by default).
No, SSL is a protocol, just like TLS. It doesn't bind to any ports. http://wiki.dovecot.org/SSL
To illustrate, both SSL and TLS as implemented in Dovecot utilize "SSL certificates."
A typical "TLS" session will work as follows:
1 The client connects to the IMAP service on port 143, unencrypted. 2 The server announces that it speaks TLS. 3 The client says "Ok, let's talk encrypted." 4 Magic occurs, and the session becomes encrypted. This step is where your "SSL" certificate is used. 5 The rest of the session is encrypted.
/Usually/, when people refer to SSL as opposed to TLS, they mean IMAPS or POPS. These differ in that there's no "Hey, I speak TLS" step. It is assumed that the conversation will begin according to some secure protocol, kind of like when you connect to a web server on port 443.
1 The client connects to IMAPS on port 993, and performs the secure handshake. Your "SSL" certificate is used in here somewhere. 2 Once the handshake has completed, the rest of the session is secure.
When implementing IMAPS/POPS you will usually use a different port, because if you tried to talk plaintext to the server, it would appear to be speaking gibberish (whatever secure protocol is being used).
With TLS enabled on a normal IMAP port, the switch from plaintext to encrypted is optional. Although, it's usually a good idea to force TLS, too.
Much of the confusion comes from the fact that you can use either protocol, TLSv1 or SSLv3 after the "Hey I speak TLS" step. Likewise, you can use TLSv1 with IMAPS or POPS, though it's use will be implied and there will be no "Hey, I speak TLS" step. There's really no agreement amongst mail clients as to the meaning of "Use SSL" and "Use TLS."
You may find it easiest to concentrate on the one distinction: does the session begin encrypted, or does it switch from plaintext to encrypted at some point? Once you've answered that, either of the SSLv3 or TLSv1 protocols can be used, and they will both use your "SSL" certificate.
Ultimately, you may wind up using both, depending on your user base. Many versions of Outlook are screwy with regard to one or both of these methods.
From Outllok Version 2007 u can choose between SSL / TLS in Settings of the mailaccount. In Outlook 2003 we experienced the only choosable SSL can also work with TLS. BUT, we found out, Outlook 2000 & 2002 cant work with any of our "forced" TLS Mailservers. Also Microsofts ENTOURAGE or whatever named Client cant work with TLS and some "Mail" Clients from OS X, but latest do. hope that helps
marko
*Marko Weber* | Administration
*SALON DIGITAL* Media GmbH Rothenbaumchaussee 19a 20148 Hamburg
T. (040) 429 48 68 - 23 F. (040) 429 48 68 - 20
marko.weber@salondigital.de mailto:marko.weber@salondigital.de www.salondigital.de http://www.salondigital.de
-- Geschäftsführung: Stephan Michalik, Ekkehart Opitz Registergericht: Amtsgericht Hamburg, NR: HRB 78111
NOTE: This communication is confidential and is intended for the use of the individual or entity to which it is directed. It may contain information that is privileged and exempt from disclosure under applicable law. If you are not the intended recipient please notify us immediately. You should not copy it or disclose its contents to any other person.
Thanks everyone who contributed to this message. I am going to use TLS on my Postfix / Dovecot server and just hope for the best. Now if I use TLS, is this configured in my Postfix config files or Dovecot config files? When TLS occurs and my SSL certificate is used, I am assuming that I need to add the SSL certificate somewhere in my /etc/dovecot.conf, correct?
Secondly, as it stands right now. When someone tries to use encryption
- Dovecot uses a generic certificate and I don't know why...
I checked my Dovecot config file and I really don't understand where and why users who are trying to read the certificate for my server are seeing the following? Can anyone look at the attachment and tell me where it's reading this from?
I checked my dovecot.conf and don't see anything that leads to a generic self signed SSL certificate:
[root@mail ~]# dovecot -n # 1.0.7: /etc/dovecot.conf protocols: imap imaps login_dir: /var/run/dovecot/login login_executable: /usr/libexec/dovecot/imap-login mail_location: maildir:~/Maildir auth default: passdb: driver: pam userdb: driver: passwd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 29 Jun 2009, Carlos Williams wrote:
When TLS occurs and my SSL certificate is used, I am assuming that I need to add the SSL certificate somewhere in my /etc/dovecot.conf, correct?
Yes
Secondly, as it stands right now. When someone tries to use encryption
- Dovecot uses a generic certificate and I don't know why...
Maybe because the installation process installed one for you or OpenSSL picks one. Dovecot has defaults, hence, maybe your system provides them.
Do you have a file: /etc/ssl/certs/dovecot.pem ?
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSkm8rXWSIuGy1ktrAQJUQwf/RnqfhFN+ttb6tR/b33UEw2g70WynUl4G XmwMfaN0OTHKFjrnSzUufpWVKFqQQG8wUk44lbZ0BPxWpqwfJOKK2wZtq0EqGjba R2ORSBiSWLubLOlkfQjsewhL9PSmoCj1CJX0Vaaw7KvTmJmL5cwxZF/K7e8+EKmT 1UnKrGzWWIzQ1C1Bcliu7ztV7cjpjy4ucQt6xbaZNZ/qZFDoGItLU1OByzyDUCPX uVopEJVsG7PzfX+wEIg2cb4HiOVvm37ipVjELDPwCvKq1G5NG8xYlnDYd1nD+z++ 52HNkzEUWv1fHdeBRgYjpdq13vtQxKIXR9pkpvR3FDGXPEHP4mJjXQ== =MrAD -----END PGP SIGNATURE-----
participants (8)
-
Carlos Williams
-
Charles Marcus
-
Jean-Noel Chardron
-
Marko Weber | Salondigital.de
-
Michael Orlitzky
-
Proskurin Kirill
-
Steffen Kaiser
-
Timo Sirainen