-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Jun 2009, Carlos Williams wrote:
No I do not. I don't even have a /etc/ssl/ direcory on my mail server
hmm, do you have openssl installed at all :) ? I had guessed that any openssl package comes with at least a bunch of CA certs.
Bye,
Steffen Kaiser
On Tue, Jun 30, 2009 at 10:30 AM, Steffen Kaiserskdovecot@smail.inf.fh-brs.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Jun 2009, Carlos Williams wrote:
No I do not. I don't even have a /etc/ssl/ direcory on my mail server
hmm, do you have openssl installed at all :) ? I had guessed that any openssl package comes with at least a bunch of CA certs.
So I have OpenSSL installed. I am creating the SSL certificate to use for my mail server via TLS. When I am on Verisign's website, they ask for "Server Platform" and normally I would select "Apache" but I don't have "Apache" installed on this machine. I just want to use this SSL certificate for TLS authentication and nothing more.
I must determine what option I need to select for "Server Platform" and then generate a CSR (Certificate Signing Request) on the Verisign website in order to get a public key.
Am I doing this all wrong or do I simply need to pick anything under "Server Platform"?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Jun 2009, Carlos Williams wrote:
So I have OpenSSL installed. I am creating the SSL certificate to use for my mail server via TLS. When I am on Verisign's website, they ask for "Server Platform" and normally I would select "Apache" but I don't have "Apache" installed on this machine. I just want to use this SSL certificate for TLS authentication and nothing more.
We do not use Verisign, so I don't know. However, OpenSSL uses PEM-format as does Apache. So I'd guess "Apache" is OK.
Maybe, you find infos regarding PEM format on Verisign pages.
Bye,
Steffen Kaiser
On Tue, Jun 30, 2009 at 11:02 AM, Steffen Kaiserskdovecot@smail.inf.fh-brs.de wrote:
We do not use Verisign, so I don't know. However, OpenSSL uses PEM-format as does Apache. So I'd guess "Apache" is OK.
Maybe, you find infos regarding PEM format on Verisign pages.
I am downloading my SSL certificate from Verisign.com right now. Verisign advised me that I need to download the x.509 since I am using a non-microsoft platform for my SSL certificates. I downloaded the certificate from the site and pasted it into a file /etc/ssl/mail.crt
I already had a mail.key file which is what I assume to be my private key I sent to Verisign which they used to create the public key I just pasted into mail.crt. Now I have mail.crt and mail.key files in my ssl/ directory. My next question is applying them so Dovecot can use them for TLS. When I edit me dovecot.conf file, I uncommented the following with the values you see below:
ssl_cert_file = /etc/ssl/mail.crt ssl_key_file = /etc/ssl/mail.key ssl_listen: 993 ssl_key_password: ******************* ssl_disable = no ssl_parameters_regenerate = 168
Now it works fine. I can open up my mail client (Mozilla Thunderbird) and configure it to use TLS. Now I see a little "pad lock" icon near my mail account to show it's using security settings.
My question now after it appears to be working, did I configure this properly for TLS? Users can still log into the IMAP server and get their mail via plain text or with the SSL certificate. Did I set the correct port for ssl_listen or is that for SSL only and not TLS?
Comments / Suggestions?
My question now after it appears to be working, did I configure this properly for TLS? Users can still log into the IMAP server and get their mail via plain text or with the SSL certificate. Did I set the correct port for ssl_listen or is that for SSL only and not TLS?
Comments / Suggestions?
If you want to have all protocols enabled add the following line in your dovecot.conf
protocols = pop3 pop3s imap imaps
this will enable "normal" pop3 and imap connections too.
Nicolelli Federico
On Thu, Jul 9, 2009 at 10:58 AM, Federico Nicolellifederico.nicolelli@iscsi.it wrote:
If you want to have all protocols enabled add the following line in your dovecot.conf
protocols = pop3 pop3s imap imaps
this will enable "normal" pop3 and imap connections too.
No we don't allow any kind of pop3 access. It's imap4 only. I just wanted to make sure I enabled the correct port for TLS usage and everything else looks good.
Carlos Williams ha scritto:
On Thu, Jul 9, 2009 at 10:58 AM, Federico Nicolellifederico.nicolelli@iscsi.it wrote:
If you want to have all protocols enabled add the following line in your dovecot.conf
protocols = pop3 pop3s imap imaps
this will enable "normal" pop3 and imap connections too.
No we don't allow any kind of pop3 access. It's imap4 only. I just wanted to make sure I enabled the correct port for TLS usage and everything else looks good.
Ok, so if you set "protocols = imap imaps" it will enable imap4 and imaps connections and you don't have to set "ssl_listen: 993" because it's the default port.
This is my ssl part of dovecot.conf:
protocols = imap imaps ssl_disable = no ssl_cert_file = /etc/dovecot/mail.mydomain.it.pem ssl_key_file = /etc/dovecot/mail.mydomain.it.key.pem ssl_ca_file = /etc/dovecot/cacert.pem ssl_verify_client_cert = no #verbose_ssl = yes
P.S i'm using dovecot 1.0.15
My question now after it appears to be working, did I configure this properly for TLS? Users can still log into the IMAP server and get their mail via plain text or with the SSL certificate. Did I set the correct port for ssl_listen or is that for SSL only and not TLS?
I never tried it, but it doesn't matter... you'll be using TLS, not SSL:
On 7/9/2009, Federico Nicolelli (federico.nicolelli@iscsi.it) wrote:
Ok, so if you set "protocols = imap imaps"
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
On Thu, Jul 9, 2009 at 11:15 AM, Charles MarcusCMarcus@media-brokers.com wrote:
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
What are you saying? Should I remove the imap protocol and just leave imaps?
protocols = imaps
On 7/9/2009 11:18 AM, Carlos Williams wrote:
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
What are you saying? Should I remove the imap protocol and just leave imaps?
protocols = imaps
I said that doing this really has only extremely minimal impact on system resources, and it is what I *personally* do...
Whether or not you choose to do so is completely up to you...
On 7/9/2009, Federico Nicolelli (federico.nicolelli@iscsi.it) wrote:
Ok, so if you set "protocols = imap imaps"
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
Me too, but in my company i unfortunately have to use also unencrypted session...
On 7/9/2009, Federico Nicolelli (federico.nicolelli@iscsi.it) wrote:
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
Me too, but in my company i unfortunately have to use also unencrypted session...
Yeah, don't you just love those phb's? ;)
Thanks for everyones help. Looks like I have a active and successful TLS connection between clients and the IMAP server. Now to move on to getting TLS and Postfix working...
I really appreciate everyones help!
On Jul 9, 2009, at 11:15 AM, Charles Marcus wrote:
On 7/9/2009, Federico Nicolelli (federico.nicolelli@iscsi.it) wrote:
Ok, so if you set "protocols = imap imaps"
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add
anything in the way of overhead on modern systems, and I just don't like the
idea of unencrypted sessions, even on on 'trusted' networks.
That's a wrong way to think about it. imaps is a legacy port that
should have died years ago. You can force encrypted sessions on imap
port just by setting disable_plaintext_auth=yes (or even more strongly
with ssl=required with v1.2+).
Timo Sirainen ha scritto:
On Jul 9, 2009, at 11:15 AM, Charles Marcus wrote:
On 7/9/2009, Federico Nicolelli (federico.nicolelli@iscsi.it) wrote:
Ok, so if you set "protocols = imap imaps"
Personally, I never enable unencrypted imap port...
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
That's a wrong way to think about it. imaps is a legacy port that should have died years ago. You can force encrypted sessions on imap port just by setting disable_plaintext_auth=yes (or even more strongly with ssl=required with v1.2+).
I guess that "disable_plaintext_auth=yes" means that you have to use encryption algorithm to protect your authentication (like md5, sha1 ecc...) but is not related with the traffic encryption.
On Thu, 2009-07-09 at 17:35 +0200, Federico Nicolelli wrote:
That's a wrong way to think about it. imaps is a legacy port that should have died years ago. You can force encrypted sessions on imap port just by setting disable_plaintext_auth=yes (or even more strongly with ssl=required with v1.2+).
I guess that "disable_plaintext_auth=yes" means that you have to use encryption algorithm to protect your authentication (like md5, sha1 ecc...) but is not related with the traffic encryption.
Well .. You're confusing password schemes and authentication mechanisms. http://wiki.dovecot.org/Authentication
On 7/9/2009, Timo Sirainen (tss@iki.fi) wrote:
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
That's a wrong way to think about it. imaps is a legacy port that should have died years ago. You can force encrypted sessions on imap port just by setting disable_plaintext_auth=yes (or even more strongly with ssl=required with v1.2+).
Hmmm... ok, I thought setting imaps was the easy way to both enable TLS and set dovecot to listen on port 993...
So, does disable_plaintext_auth=yes automatically change the imap listen port to 993, or would I then nees to also set 'ssl_listen: 993' (if so, wouldn't that seeting be more appropriately named tls_listen? ;)?
Thanks Timo - I do prefer to use settings that are not (or not someday going to be) deprecated...
Charles Marcus ha scritto:
On 7/9/2009, Timo Sirainen (tss@iki.fi) wrote:
Forcing encrypted port (imaps) for everyone really doesn't add anything in the way of overhead on modern systems, and I just don't like the idea of unencrypted sessions, even on on 'trusted' networks.
That's a wrong way to think about it. imaps is a legacy port that should have died years ago. You can force encrypted sessions on imap port just by setting disable_plaintext_auth=yes (or even more strongly with ssl=required with v1.2+).
Hmmm... ok, I thought setting imaps was the easy way to both enable TLS and set dovecot to listen on port 993...
So, does disable_plaintext_auth=yes automatically change the imap listen port to 993, or would I then nees to also set 'ssl_listen: 993' (if so, wouldn't that seeting be more appropriately named tls_listen? ;)?
No it will only disable plaintext authentications over a unsecure channel. so if you want to force SSL/TLS you should use ssl=required as Timo said.
Thanks Timo - I do prefer to use settings that are not (or not someday going to be) deprecated...
That's right ;-)
On 7/9/2009, Federico Nicolelli (federico.nicolelli@iscsi.it) wrote:
So, does disable_plaintext_auth=yes automatically change the imap listen port to 993, or would I then nees to also set 'ssl_listen: 993' (if so, wouldn't that seeting be more appropriately named tls_listen? ;) ?
No it will only disable plaintext authentications over a unsecure channel. so if you want to force SSL/TLS you should use ssl=required as Timo said.
Ok, still a little confused...
To do this 'right'...
protocols = imap disable_plaintext_auth = yes ssl = required
and just use the default standard imap port of 143?
On Thu, 2009-07-09 at 12:07 -0400, Charles Marcus wrote:
On 7/9/2009, Federico Nicolelli (federico.nicolelli@iscsi.it) wrote:
So, does disable_plaintext_auth=yes automatically change the imap listen port to 993, or would I then nees to also set 'ssl_listen: 993' (if so, wouldn't that seeting be more appropriately named tls_listen? ;) ?
No it will only disable plaintext authentications over a unsecure channel. so if you want to force SSL/TLS you should use ssl=required as Timo said.
Ok, still a little confused...
To do this 'right'...
protocols = imap disable_plaintext_auth = yes ssl = required
and just use the default standard imap port of 143?
Yeah. And sure you can keep imaps port open too.
If you have only auth { mechanisms = plain } enabled, disable_plaintext_auth=yes and ssl=required does basically the same thing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 9 Jul 2009, Timo Sirainen wrote:
That's a wrong way to think about it. imaps is a legacy port that should have died years ago. You can force encrypted sessions on imap port just by setting
Well, I do not see it like that, moreover because the STARTLS is not essentially better than IMAP-over-SSL. At least one should be able to submit the domain/host the client wants to connect to, in order to enable virtual IMAP/SMTP/... hosting.
So, STARTTLS is just overhead without gain, well, you need one port less.
Bye,
Steffen Kaiser
On 7/10/2009, Steffen Kaiser (skdovecot@smail.inf.fh-brs.de) wrote:
Well, I do not see it like that, moreover because the STARTLS is not essentially better than IMAP-over-SSL. At least one should be able to submit the domain/host the client wants to connect to, in order to enable virtual IMAP/SMTP/... hosting.
Hmmm... not sure what your comment re: virtual hosting has to do with STARTTLS vs IMAPS...
I checked though and it doesn't appear that port 993 for IMAPS is deprecated - at least not like 465 is deprecated for SMTPS...
... urd 465/tcp URL Rendesvous Directory for SSM igmpv3lite 465/udp IGMP over UDP for SSM ... imaps 993/tcp imap4 protocol over TLS/SSL imaps 993/udp imap4 protocol over TLS/SSL
Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 9 Jul 2009, Timo Sirainen wrote:
That's a wrong way to think about it. imaps is a legacy port that should have died years ago. You can force encrypted sessions on imap port just by setting
Well, I do not see it like that, moreover because the STARTLS is not essentially better than IMAP-over-SSL. At least one should be able to submit the domain/host the client wants to connect to, in order to enable virtual IMAP/SMTP/... hosting.
So, STARTTLS is just overhead without gain, well, you need one port less.
Actually, I'm coming in rather late, but I thought that was the whole point of TLS that you could decide what certificate to present AFTER you knew which client was connecting? This allows virtual hosting with a different SSL cert per host (current situation is rather difficult... I'm using a cert with multiple names on it, but this is hard to buy)
It's exciting to see TLS finally coming to http for example and we can do virtual hosting for machines without needing gazillions of ports (on the other hand sadly FF has broken the ability to easily use self signed certs, so just as the internet was about to encrypt everything rather than go plain text, FF goes and spoils all the fun... *sigh*
Ed W
On Jul 11, 2009, at 1:10 PM, Ed W wrote:
Actually, I'm coming in rather late, but I thought that was the
whole point of TLS that you could decide what certificate to present
AFTER you knew which client was connecting? This allows virtual
hosting with a different SSL cert per host (current situation is
rather difficult... I'm using a cert with multiple names on it, but
this is hard to buy)
You mean that there could be multiple hosts in same IP? That extension
has been talked about every once in a while, but nothing really ever
happens because people just think Outlook is never going to implement
it so there's no point in even trying.
Timo Sirainen wrote:
On Jul 11, 2009, at 1:10 PM, Ed W wrote:
Actually, I'm coming in rather late, but I thought that was the whole point of TLS that you could decide what certificate to present AFTER you knew which client was connecting? This allows virtual hosting with a different SSL cert per host (current situation is rather difficult... I'm using a cert with multiple names on it, but this is hard to buy)
You mean that there could be multiple hosts in same IP? That extension has been talked about every once in a while, but nothing really ever happens because people just think Outlook is never going to implement it so there's no point in even trying.
I meant that you could have one server (one IP) and when a customer connects they can connect to mail.theirdomain.com (CNAME or A to mail.ourserver.com) and not see warnings about the SSL cert not matching the address they are connecting to (ie the generic problem)
Right now it requires a cert containing every possible destination server name on the single cert. This works, but it's hard to buy such certs. TLS (in general) offers the *possibility* to figure out what domain the customer is trying to connect to and present the correct cert up front.
Sadly it still seems to break for email because you need the customer to AUTH before upgrading to SSL and this isn't usually what they do...
By an extension I assume you mean there is actually some standard proposed to solve that bit of the puzzle, I wasn't even aware that was on the cards?
Anyway, the question was why does TLS exist at all, I presented the
answer that we have the *possibility* to present one of several certs.
I think this is a fair justification for the concept to exist. However,
I agree that exploiting the potential of TLS is still not there
As an aside, I see several other software projects now enabling the compression option when establishing an SSL connection - any chance you could look at enabling the relevant lines of code in Dovecot? We had this conversation some months/years back and it appeared simple on the dovecot side, but there is of course only still minimal client support (but at least we can break the chicken-egg situation)
Cheers
Ed W
On Jul 12, 2009, at 2:21 PM, Ed W wrote:
I meant that you could have one server (one IP) and when a customer
connects they can connect to mail.theirdomain.com (CNAME or A to
mail.ourserver.com) and not see warnings about the SSL cert not
matching the address they are connecting to (ie the generic problem)Right now it requires a cert containing every possible destination
server name on the single cert. This works, but it's hard to buy
such certs. TLS (in general) offers the *possibility* to figure out
what domain the customer is trying to connect to and present the
correct cert up front.Sadly it still seems to break for email because you need the
customer to AUTH before upgrading to SSL and this isn't usually what
they do...By an extension I assume you mean there is actually some standard
proposed to solve that bit of the puzzle, I wasn't even aware that
was on the cards?
There's draft-hazewinkel-imap-vhost-00 from 6 years ago.
As an aside, I see several other software projects now enabling the
compression option when establishing an SSL connection - any chance
you could look at enabling the relevant lines of code in Dovecot?
We had this conversation some months/years back and it appeared
simple on the dovecot side, but there is of course only still
minimal client support (but at least we can break the chicken-egg
situation)
I remember it was a few weeks ago :)
Timo Sirainen wrote:
As an aside, I see several other software projects now enabling the compression option when establishing an SSL connection - any chance you could look at enabling the relevant lines of code in Dovecot? We had this conversation some months/years back and it appeared simple on the dovecot side, but there is of course only still minimal client support (but at least we can break the chicken-egg situation)
I remember it was a few weeks ago :)
Actually that ended up being mainly about the COMPRESS protocol
extension - that is interesting, but I personally doubt it offers much
extra over a simple outer layer protocol compression algorithm, eg
native SSL compression. (However, would settle for either/both...).
Some time back you suggested the SSL compression fix was a one liner on
the dovecot side though?
As an aside would it help to have some sample code for zlib? My problem is I don't know where to add it for the COMPRESS protocol implementation... Zlib itself is pretty straightforward though.
Cheers
Ed W
On Sun, 2009-07-12 at 19:41 +0100, Ed W wrote:
Actually that ended up being mainly about the COMPRESS protocol extension - that is interesting, but I personally doubt it offers much extra over a simple outer layer protocol compression algorithm, eg native SSL compression. (However, would settle for either/both...).
Some time back you suggested the SSL compression fix was a one liner on the dovecot side though?
After trying ages to figure this out, I finally found out that it already works for SSL, as long as OpenSSL is compiled with zlib support. You can verify this with gnutls-cli (but not openssl s_client):
gnutls-cli --priority NORMAL:+COMP-DEFLATE -p 993 --insecure localhost ..
- Compression: DEFLATE
Also interestingly enough I couldn't make compression work with gnutls-serv..
As an aside would it help to have some sample code for zlib?
Maybe some small sample code could be useful. Although I could also look at how GNUTLS does it.
My problem is I don't know where to add it for the COMPRESS protocol implementation... Zlib itself is pretty straightforward though.
If you (or someone) can implement deflate istream and inflate ostream code for Dovecot, I can do the rest.
BTW. For Dovecot v2.0 I'm also thinking about changing ssl-proxy code to be ssl-istream and ssl-ostream instead and then make a bit more generic login-proxy where you can give any i/ostreams. That'll also make implementing COMPRESS support easier..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 11 Jul 2009, Ed W wrote:
per host (current situation is rather difficult... I'm using a cert with multiple names on it, but this is hard to buy)
What expieriences do you have on client-side with those certs?
I tried a two-name cert three years ago, but had to withdraw it. Not a single client accepted the cert - if I remember correctly.
Bye,
Steffen Kaiser
Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 11 Jul 2009, Ed W wrote:
per host (current situation is rather difficult... I'm using a cert with multiple names on it, but this is hard to buy)
What expieriences do you have on client-side with those certs?
I tried a two-name cert three years ago, but had to withdraw it. Not a single client accepted the cert - if I remember correctly.
Erm, I use the godaddy certs multiple domain certs (cheap...) and I certainly use this ok in Apple mail and Thunderbird. I *thought* I had tried on Outlook/Outlook Express, but I might be mistaken?
I have seen people saying these certs work ok on the windows handheld
devices, so if windows stuff supports them then things are looking up!
My Nokia N97 isn't throwing up any complaints using starttls either.
Possibly we are talking cross purposes though - connect to mail.mailasail.com and examine the cert there and if you wish I can give you an account on there to try from various clients? (erk, better go check my cert hasn't expired now I told you to look...).
Good luck
Ed W
On Thu, Jul 9, 2009 at 10:51 AM, Carlos Williamscarloswill@gmail.com wrote:
When I edit me dovecot.conf file, I uncommented the following with the values you see below:
ssl_cert_file = /etc/ssl/mail.crt ssl_key_file = /etc/ssl/mail.key ssl_listen: 993 ssl_key_password: ******************* ssl_disable = no ssl_parameters_regenerate = 168
When I comment / remove the following parameters from dovecot.conf, nothing breaks with my Thunderbird client still configured for "TLS":
ssl_listen: 993 ssl_disable = no
Both above are now commented out and I restarted Dovecot and was wondering what does that mean? Nothing broke and I can still open a secure connection between my client and the IMAP server. Did I change any parameters with my TLS connection via Dovecot?
participants (6)
-
Carlos Williams
-
Charles Marcus
-
Ed W
-
Federico Nicolelli
-
Steffen Kaiser
-
Timo Sirainen