-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSkopIXWSIuGy1ktrAQI/ygf+L+QQkZKaGW+p5yaHFlpHJfzKmI+8jnXv W0+sJ+bYLO3VkMhzV9jWuiXXq8FbF7BY0RNVQv91wUdsD2DFgucv5IFLV7vi9WsF vd46bAQ4OdUpqbYm5bFMwG37btxM7iz/bO3E7IFyVLn4RLtlLcgtuD1+FhWnnJQX p5NqRpkbFHRNZrdjI3f8/NpM1aiTfCLmUaAxJ3cM8EMkP/LvrcrFd9il3eYGfjKy Won1twuVEn5mkMeNz4l38dFRa/tdggJSXzdoBJUfdl+9as9HBQ8YjxLk/rzZC9xx nEWGQlGFhfvoivtWYlYBviYf3NtbrZ0vsbJeSzTv2m9RSPimlb7DCg== =skk/ -----END PGP SIGNATURE-----

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

Carlos Williams ha scritto:

On Thu, Jul 9, 2009 at 10:58 AM, Federico Nicolelli<federico.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

On Thu, Jul 9, 2009 at 11:15 AM, Charles Marcus<CMarcus@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, 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...

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!

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 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...

--

Best regards,

Charles

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?

--

Best regards,

Charles

-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSlcG+nWSIuGy1ktrAQLEjAf+KWEAwqv54sx7BLEH0umkPDJUOr/mHqmT 3ghFkY63NgyMq6WKsIlgCMkyv6P9x0eU8MyZ6mYHeH8E42afib3F4yUmSNgfisKe iIlUWc6cvvt+jzZXXf1+Cmd1RhSMQ5Q93WxbMPlbqxgLEOCh3FY69GyYRc/zNqQm EdgU2TkN7UA6qJ0zXfa10W1QbbNp4EWQ6oKFse6KrVae+JY96+yPT34JZV+wwklL xDiVgymcYI+H18a2WMwanvR13w0oCUNLLQDS5p2dxQX79S19gLaSP6e1vMZF222t 0SyXdSGd9jdl6tS5yFim1m9AXwCwxRs62aEZ2H/BoNb1hw0yFW63Lg== =fVTA -----END PGP SIGNATURE-----

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

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

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

-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSlsfCXWSIuGy1ktrAQIRYgf+I6NZ3fd87Tbxa6uNttZLAC1YZ9boBHAb VrhByijsyCpNgHzby2HbIqgLKhYAjqQFPIw1//8SwHnN/9fEMNkzduweCWse0Ypx tyINCdd9ReDRJKRQR/Wf+k+HTE8MQqyyMUCh+tnEcvV7/4eKY2tsJlSQg0SMkV96 hAY+jKY+y4/pPb+CbpDSvkYuiG0SjZ4e5jk+Ug2TjBYB5WNuEm9/rPOHuJcuaHbc zCDrOJSKmDW9GoZ8B7UOJDILmiquxYVE4aSfS2NfXUQ2fjGgvhdhYPGrTplHCRpD uPzcB+MsYKvBWnzvLPqkBgSwg80FOfz90SpsKNO3uRBxfMO7cCNHeg== =cNfb -----END PGP SIGNATURE-----

On Thu, Jul 9, 2009 at 10:51 AM, Carlos Williams<carloswill@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?